View Issue Details

IDProjectCategoryView StatusLast Update
0002714SOGo Connectorwith SOGopublic2014-04-29 18:18
Reportermbi Assigned Toludovic  
Status closedResolutionfixed 
Platform[Client] MicrosoftOSWindowsOS Version7
Product Version24.0.4 
Fixed in Version24.0.5 
Summary0002714: Read-Only Shared Address Boooks - updates fail if user updates local copy

This is serious.

If a User using Thunderbird (24.4) and SOGo Connector+Integrator has Read-Only permissions to a shared Address Book, and changes something for one of the contacts, SOGo constantly tries to update the Shared Address Book (clicking the Synchronize button says it has uploaded the change every time, but the change is NOT uploaded).

That in and of itself is not really serious (though the Sync should DELETE the local change and resync to the server version).

The serious part of this bug is, once that user has tried to update one of t he contacts in that Shared Address Book, that Contact will NO LONGER UPDATE AT ALL.

Changes made to the main Shared Address Book no longer propogate to that users local copy.

This does not affect other users who have access to the Shared Address Book (thankfully), but I guarantee this will cause lots of problems, because Users WILL try to edit these Address Books.

Steps To Reproduce
  1. Share an Address Book, giving a Group read-only access (Share Permissions 'This person can read the cards of this addressbook.'), and another group Full Control.

  2. Confirm the Address Book syncs properly in Thunderbird for the Read-Only user when changes are made to the Shared Address Book by someone who has full control - ie, changes propagate down to the users.

  3. Edit one of the Contacts in the shared Address Book in Thunderbird from a user that has Read-Only access, then Sync the Address Book - note that SOGo says that 1 change was uploaded.

  4. Note that if you click Sync additional times, it keeps saying this change was updated successfully over and over, even though it wasn't

  5. Make a change to the same Contact (even a different field than the user tried to update) by someone who has Full Control, and observe that those changes are NO LONGER PROPAGATED to the user who tried to edit this contact.

  6. Changes to other Contacts are still propagated to this user, and changes to the problem contact continue to Sync normally for OTHER users, unless/until they try to change one, in which case it breaks.

  7. Unsubscribing and resubscribing the Address Book fixes the problem - until they try it again.

TagsNo tags attached.




2014-04-14 12:50

administrator   ~0006891

  1. should be improved, but there's no ACL verification on the client side (ie. Thunderbird) for address books - only server-side enforcements.


2014-04-14 13:13

reporter   ~0006892

Hi Ludo,

Not sure I understand.

This is a serious bug.

I guarantee we will have LOTS of bug reports coming my way with Address Book Syncing failing because people try to update Contacts in these Address Books.

Are you saying you don't consider this a bug?



2014-04-14 13:14

administrator   ~0006893

No, 5 is a bug, the rest is "normal''.



2014-04-14 13:18

reporter   ~0006894

Ok, but what about 3?

SOGo should not claim that the Contact was updated when it wasn't, and it certainly shouldn't say it over and over again every time the user starts Thunderbird and/or clicks the Sync button.

It should say it failed, and why (user doesn't have the requisite permission to update it).



2014-04-14 13:30

administrator   ~0006895

Yes about 3.



2014-04-14 13:46

reporter   ~0006896

Ok, thanks... :)

Should I open a separate bug for each of these two bugs then? Or is this one good enough?

Also - do you think it will be easy enough to fix?

Thanks again...



2014-04-14 13:51

administrator   ~0006897

This bug is ok.

We'll look at it this week and advise.



2014-04-16 14:12

reporter   ~0006902

Just wanted to add that I've noted the issue of read-only Thunderbird clients being able to edit their local copy of a book in 0001939.

I agree it would be nice if there was a way to stop read-only users from making changes, even local ones, if possible.



2014-04-16 14:25

reporter   ~0006903

Sorry, but just to be clear...

This is not just a 'it would be nice' issue.

This is a serious bug that:

a) BREAKS the Shared Contacts Address Book, if only for the Contact(s) that was/were edited locally by the user,

b) Results in continuous and false 'Successful Sync' notifications for the local change that was made, and

c) can only be resolved by un/re-subscribing the Address Book

I really wouldn't be quite as concerned about preventing a user from being able to do this, if the next sync would simply undo the change, instead of what it does now - simply stops syncing that contact, but continually saying it is successfully syncing the users change.

Then it would be a 'it would be nice if the user was prevented from doing this in the first place and was actually notified by the system that they didn't have permission to edit those contacts'.

Ludovic: Why is cwright listed in his comment as 'reporter'? I reported this bug.



2014-04-17 05:43

reporter   ~0006912

mbi, that's access level, not your relation to this bug



2014-04-17 09:13

reporter   ~0006914

ok, thanks...



2014-04-17 09:19

reporter   ~0006916

ludo... above you said:

"there's no ACL verification on the client side (ie. Thunderbird) for address books - only server-side enforcements."

But, in these Shared SOGo Address Books, there is a 'Read Only' checkbox in the bottom left that is greyed out and unchecked, except that in the global 'directory', it is CHECKED (but still greyed out).

What is this attribute for, why is it greyed out, and why is it checked for the 'directory'?

Also - what would happen if I try to edit a contact in the 'directory' list? Would it break that one as well? I don't want to test this at this point, but I'm wondering what would happen if a regular user tried this.



2014-04-22 11:48

reporter   ~0006939

I wonder if the situation can be improved by showing a proper sync error.
If we get a 403 forbidden, maybe try a PROPFIND/current-user-privilege-set, and if that lacks a write privilege, show that in a notification.



2014-04-22 13:32

reporter   ~0006941

Ludo? Any chance for a reply to my questions above?




2014-04-28 11:17

reporter   ~0006964

Any movement on this?

It is becoming more and more of a problem.

I just had to un/re-sub both of our shared Address Books for 5 users (testing the pushed updates for the latest extension versions), because they keep adding new contacts to our Company Address Book even when they shouldn't be able to do this.



2014-04-28 11:19

reporter   ~0006965


Adding Contacts to shared Address Books where user has read-only access also breaks the Address Book, but it breaks syncing for all contacts.

This makes this an even more serious bug than I thought.



2014-04-29 12:59

administrator   ~0006969

A patch to handle the 403 should be available today or tomorrow.



2014-04-29 13:24

reporter   ~0006971

Hi Ludo,

Thanks for this!

But, I'm not sure what you mean by 'to handle the 403'...

Will this resolve the sync problems? And if so, how? Ie, does it just wipe the local copy and do a resync?

Thanks again!



2014-04-29 14:47

administrator   ~0006974

The bug was introduced when we merged this pull request:

That line is wrong:

            if (!confirm) return else {

It causes an exception to be raised.

Now, even with 403 results, the sync process still work and updates are pulled.

We'll modify the code so that we inform the user the upload has failed for one card (and give card details, if possible), but we won't delete it so that if ACLs are changed or fixed on the subscribed address books, changes will be pushed accordingly.



2014-04-29 18:18

administrator   ~0006976

Issue History

Date Modified Username Field Change
2014-04-14 12:09 mbi New Issue
2014-04-14 12:50 ludovic Note Added: 0006891
2014-04-14 13:13 mbi Note Added: 0006892
2014-04-14 13:14 ludovic Note Added: 0006893
2014-04-14 13:18 mbi Note Added: 0006894
2014-04-14 13:30 ludovic Note Added: 0006895
2014-04-14 13:46 mbi Note Added: 0006896
2014-04-14 13:51 ludovic Note Added: 0006897
2014-04-16 14:12 cwright Note Added: 0006902
2014-04-16 14:25 mbi Note Added: 0006903
2014-04-17 05:43 altxt Note Added: 0006912
2014-04-17 09:13 mbi Note Added: 0006914
2014-04-17 09:19 mbi Note Added: 0006916
2014-04-22 11:48 altxt Note Added: 0006939
2014-04-22 13:32 mbi Note Added: 0006941
2014-04-28 11:17 mbi Note Added: 0006964
2014-04-28 11:19 mbi Note Added: 0006965
2014-04-29 12:59 ludovic Note Added: 0006969
2014-04-29 13:24 mbi Note Added: 0006971
2014-04-29 14:47 ludovic Note Added: 0006974
2014-04-29 18:18 ludovic Note Added: 0006976
2014-04-29 18:18 ludovic Status new => closed
2014-04-29 18:18 ludovic Assigned To => ludovic
2014-04-29 18:18 ludovic Resolution open => fixed
2014-04-29 18:18 ludovic Fixed in Version => 24.0.5