View Issue Details

IDProjectCategoryView StatusLast Update
0005203SOGoBackend Address Bookpublic2021-03-27 14:30
Reporterhelmut72 Assigned Tofrancis  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
OSDebianOS Version10 
Product Version5.0.1 
Fixed in Version5.1.0 
Summary0005203: macOS 11 (Big Sur) contacts app ignores default address book
Description

macOS 11 (Big Sur) contacts app ignores default address book "Persönliches Addressbuch". Renamed to "private" (= without Umlauts) also doesn't work.

A secondary manually created address book in SOGo's webinterface will be synced by macOS 11 (Big Sur) contacts app.

Steps To Reproduce

Connect macOS 11 (Big Sur) contacts app to SOGo address book with CardDAV

Additional Information

Happens at least with the latest 5 Beta versions of macOS 11 (Big Sur). Even 11.0.1 (still Beta) doesn't work. Processor architecture of SOGo server doesn't matter, problem exists on amd64 and aarch64.

TagsNo tags attached.

Activities

tomierna

tomierna

2020-11-02 16:30

reporter   ~0014915

I am experiencing this as well. I posted to the Users list in August.

Here is what I found:

I turned on these debug flags: GCSFolderDebugEnabled
GCSFolderStoreDebugEnabled
SOGoDebugRequests
SoDebugObjectTraversal
SoSecurityManagerDebugEnabled
LDAPDebugEnabled

Deleted the account from two machines (Big Sur and Catalina) and re-added them while watching the logs.

Parsing these logs is difficult for me because I have other machines hitting this server and the IP address is not logged on every line, so there appears to be some logging that interleaves messages from multiple sessions.

That said, what it looks like to me is that the Big Sur machine may not be properly passing credentials?

When I created the account on the Big Sur machine, I see a PROPFIND on the account, and then a traverse miss blamed on SoAuthRequiredException. Subsequent requests only ask for Contacts/global_addressbook.

On the Catalina machine when I recreate the account, the PROPFIND on the account and traverse doesn’t generate a miss error, and subsequent requests ask for Contacts/global_addressbook and Contacts/personal.

==

I have logged this via the Big Sur Feedback Assistant to Apple, but they closed it with "Resolution: Investigation complete - Unable to diagnose with current information."

war

war

2020-11-13 14:48

reporter   ~0014940

Same issue, Server 4.3.2

maku87

maku87

2020-11-16 14:01

reporter   ~0014947

same problem here :-(

helmut72

helmut72

2020-11-17 06:17

reporter   ~0014948

Because Big Sur is now released, it becomes a big issue. How can I edit my entry?

war

war

2020-11-17 08:38

reporter   ~0014949

I'm afraid, there is no way to edit the access string.
Access works fine on IOS 14.2 but not on 11.0.1.
This issue needs to be fixed by Apple (it was the only thing that changed)

tomierna

tomierna

2020-11-17 16:51

reporter   ~0014954

Because Apple has closed my ticket with "Resolution: Investigation complete - Unable to diagnose with current information." it leads me to believe that my logs were not detailed enough, and that there were not enough similar reports that they allocated any engineering time to fix it. I imagine the cross section of macOS users who connect to the CardDAV feed of a SOGo instance, and who also trialed the beta of Big Sur is a fairly small number.

Are there any SOGo devs who use MacOS devices and are also members of the Apple Developer Program, who might be able to log a bug with Apple and provide better logging info? Anyone else on this thread who can, please use the Feedback Assistant to file a ticket with Apple.

As the admin of a SOGo instance and the support person for many Apple devices within my small business, this puts me in a difficult position. My users can't update to the new OS, and I can't figure out a way to make Apple care that their application is broken.

helmut72

helmut72

2020-11-17 17:52

reporter   ~0014955

This issue needs to be fixed by Apple (it was the only thing that changed)

Yes, it looks like. But it depends. Need to be checked if the cause of this problem is related to the CardDAV RFC and if the RFC says 'may' or 'must'.

war

war

2020-11-18 08:44

reporter   ~0014958

I have filed a bug report with Apple yesterday (3 attempts because the logs were big).
Apple required their own system information and sysdiagnostic logs.

Not sure if that is sufficient

helmut72

helmut72

2020-11-30 21:39

reporter   ~0014979

Looks like Big Sur never do:
propfind /sogo/dav/user/contacts/personal

But:
propfind /sogo/dav/user/contacts/directory
... 3 times!

Who is responsible for a:
propfind /sogo/dav/user/contacts/personal

Client or Server?

helmut72

helmut72

2020-11-30 22:43

reporter   ~0014980

I have now SOGo debugging enabled. First stuff is identical, but this is different:

Catalina:
Nov 30 23:14:33 sogod [19]: 1.1.1.1 "PROPFIND /SOGo/dav/user/Contacts/directory/ HTTP/1.1" 207 500/782 0.016 1363
Nov 30 23:14:34 sogod [19]: |SOGo| starting method 'REPORT' on uri '/SOGo/dav/user/Contacts/personal/'
Nov 30 23:14:34 sogod [19]: |SOGo| request took 0.016037 seconds to execute
Nov 30 23:14:34 sogod [19]: 1.1.1.1 "REPORT /SOGo/dav/user/Contacts/personal/ HTTP/1.1" 207 125/210 0.019 - - 0 -

Catalina stops.

Big Sur:
Nov 30 23:10:54 sogod [19]: 1.1.1.1 "PROPFIND /SOGo/dav/user/Contacts/directory/ HTTP/1.1" 207 500/782 0.014 1363
Nov 30 23:10:54 sogod [19]: |SOGo| starting method 'PROPFIND' on uri '/SOGo/dav/user/Contacts/directory/'
Nov 30 23:10:54 sogod [19]: [obj-dav-dispatch] constructed root-url:
Nov 30 23:10:54 sogod [19]: |SOGo| constructed root-url: /SOGo/

Big Sur feels like it's in a "directory" loop, because there are many more of this PROPFIND /directory requests.

I've replaced my public IP with 1.1.1.1 and my username with user.

helmut72

helmut72

2020-12-01 17:13

reporter   ~0014983

It works. SOGo devs can fix it.

I found that Big Sur get a different XML file right before requests/reponses becomes different between Catalina and Big Sur.

When adding this line to my SOGo's Apache configuration, it works:
RequestHeader set User-Agent "Mac OS X/10.15.7 (19H15) AddressBookCore/1"

Is it possible rewrite the user-agent in Apache if it's anything like:
"macOS/11.1 (20C5048k) AddressBookCore/2452.2"

As a workaround? Thanks

mkuron

mkuron

2020-12-01 17:27

reporter   ~0014984

Good find. This probably needs to be fixed in https://github.com/inverse-inc/sogo/blob/master/SoObjects/SOGo/WORequest+SOGo.m, for which I have attached an (untested) patch.

macOS11.patch (1,539 bytes)   
--- WORequest+SOGo copy.m	2020-12-01 18:23:14.000000000 +0100
+++ WORequest+SOGo.m	2020-12-01 18:25:06.000000000 +0100
@@ -127,6 +127,7 @@
 
 //
 // Mac+OS+X/10.10.1 (14B25) CalendarAgent/315
+// macOS/11.0.1 (20B50) CalendarAgent/954
 //
 - (BOOL) isICal
 {
@@ -137,6 +138,7 @@
   return ([self isAppleDAVWithSubstring: @"Mac OS X/10."]
           || [self isAppleDAVWithSubstring: @"Mac_OS_X/"]
           || [self isAppleDAVWithSubstring: @"Mac+OS+X/"]
+          || [self isAppleDAVWithSubstring: @"macOS/"]
           || [self isAppleDAVWithSubstring: @"CoreDAV/"]
           || [[cc userAgent] rangeOfString: @"DAVx5"].location != NSNotFound);
 }
@@ -147,6 +149,7 @@
 // Mac OS X/10.8 (12A269) Calendar/1639
 // Mac OS X/10.8 (12A269) CalendarAgent/47
 // Mac OS X/10.8.1 (12B19) CalendarAgent/47
+// macOS/11.0.1 (20B50) CalendarAgent/954
 //
 - (BOOL) isICal4
 {
@@ -175,6 +178,10 @@
 // Mac OS X/10.8.1 (12B19) AddressBook/1143
 // Mac OS X/10.8.2 (12C60) AddressBook/1167
 //
+// For 11.0, we see:
+//
+// macOS/11.0.1 (20B50) AddressBookCore/2452
+//
 - (BOOL) isMacOSXAddressBookApp
 {
   WEClientCapabilities *cc;
@@ -197,6 +204,11 @@
           [[cc userAgent] rangeOfString: @"Mac OS X"].location != NSNotFound
           && [[cc userAgent] rangeOfString: @"AddressBook"].location != NSNotFound
         )
+        ||
+        (
+          [[cc userAgent] rangeOfString: @"macOS"].location != NSNotFound
+          && [[cc userAgent] rangeOfString: @"AddressBook"].location != NSNotFound
+        )
       );
 
   return b;
macOS11.patch (1,539 bytes)   
helmut72

helmut72

2020-12-01 20:35

reporter   ~0014985

Now I have a workaround. Because I'm private, I want to upgrade to macOS 11 asap and this was the only showstopper ;-)

On top of the Alias line in Apache, I set following:

SetEnvIf User-Agent "macOS/11.*" value macOS11
RequestHeader set User-Agent "Mac OS X/10.15.7 (19H15) AddressBookCore/1" env=macOS11

Alias /SOGo.woa/WebServerResources/ /usr/local/lib/GNUstep/SOGo/WebServerResources/

Access from any other client works as usual with his user-agent and I guess, this should also fix an older version of SOGo with Big Sur.

Related Changesets

sogo: master b9e19c2c

2020-12-01 15:36

francis


Details Diff
fix(addressbook(dav)): add support for macOS 11 (Big Sur)

Fixes 0005203
Affected Issues
0005203
mod - SoObjects/SOGo/WORequest+SOGo.m Diff File

sogo: v2 c65e1212

2020-12-01 15:36

francis


Details Diff
fix(addressbook(dav)): add support for macOS 11 (Big Sur)

Fixes 0005203
Affected Issues
0005203
mod - SoObjects/SOGo/WORequest+SOGo.m Diff File

sogo: v2 00575249

2020-12-02 09:27

francis


Details Diff
fix(addressbook(dav)): add support for macOS 11 (Big Sur)

Fixes 0005203
Affected Issues
0005203
mod - SoObjects/SOGo/WORequest+SOGo.m Diff File

Issue History

Date Modified Username Field Change
2020-11-01 10:18 helmut72 New Issue
2020-11-02 16:30 tomierna Note Added: 0014915
2020-11-13 14:48 war Note Added: 0014940
2020-11-16 14:01 maku87 Note Added: 0014947
2020-11-17 06:17 helmut72 Note Added: 0014948
2020-11-17 08:38 war Note Added: 0014949
2020-11-17 16:51 tomierna Note Added: 0014954
2020-11-17 17:52 helmut72 Note Added: 0014955
2020-11-18 08:44 war Note Added: 0014958
2020-11-30 21:39 helmut72 Note Added: 0014979
2020-11-30 22:43 helmut72 Note Added: 0014980
2020-12-01 17:13 helmut72 Note Added: 0014983
2020-12-01 17:27 mkuron Note Added: 0014984
2020-12-01 17:27 mkuron File Added: macOS11.patch
2020-12-01 20:35 helmut72 Note Added: 0014985
2020-12-01 20:39 francis Changeset attached => sogo master b9e19c2c
2020-12-01 20:39 francis Assigned To => francis
2020-12-01 20:39 francis Resolution open => fixed
2020-12-01 20:39 francis Status new => resolved
2020-12-01 20:39 francis Fixed in Version => 5.1.0
2020-12-01 20:51 francis Changeset attached => sogo v2 c65e1212
2020-12-02 14:28 francis Changeset attached => sogo v2 00575249