View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005342||SOGo||Documentation||public||2021-06-21 10:24||2021-07-05 11:34|
|Status||resolved||Resolution||no change required|
|Summary||0005342: Upgrading broke Sogo|
Today after upgrading via the official, supported repositories, Sogo became unavailable. I could not identify anything relevant in the logs, even after activating debug, and did not find anything relevant in the changelog. Eventually I had to restore the system to a previous version.
|Steps To Reproduce|
Upgrade to Sogo v5.1.1 with LDAP auth enabled.
So, after the drama I reproduced the issue on a test server, and it turned out that the issue is with the new default for SOGoXSRFValidationEnabled
"Parameter used to enable or not XSRF (also known as CSRF) protection in SOGo. Default value is YES, or enabled."
From the changelog :
The XSRF protection is now enabled by default in SOGo. If you use a single sign-on mechanisim such as C.A.S. or SAML2, you need to disable XSRF by adding SOGoXSRFValidationEnabled = NO to your configuration file.
→ LDAP in itself is not single sign-on, so I didn't care much about that note. Yet it is very much impacted!
Other issues mentioning this partly:
|Tags||No tags attached.|
Please share an anonymized version of your
Anonymised version of sogo.conf
It should work with this configuration. Try to empty your browser's cache, restart your Web server and memcached instance.
I did it all before, including connecting from private browsing. I even rebooted the server before restoring.
Also, aside from memcached there are no caching servers associated with sogo.
Now that I have a test server handy, I will triple check though. However the 500 error is delivered from the local Apache which sends all to sogo daemon, so it looks like there is a issue bigger than cache at hand.
I've re-run tests this morning, still reproducible 100% as soon as I enable XSRF and reload.
With SOGoXSRFValidationEnabled set to 'NO', everything is back, no more HTTP error code 500.
Below is the packet capture from the Sogo server, as it receives the packets from the reverse proxy.
How about the
Putting the solution here as well: if you have enabled httpOnly for your cookies on Apache, you need to disable it for XSRF to work and not break Sogo.
Typically, I had to comment out the following line in my Apache configuration :
#Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
Then I do get the X-XSRF-TOKEN header. I hope this helps others facing the same issue.
|2021-06-21 10:24||jean38||New Issue|
|2021-06-21 10:30||francis||Note Added: 0015325|
|2021-06-21 10:31||jean38||Note Added: 0015326|
|2021-06-21 10:31||jean38||File Added: sogo_error_XSRF.png|
|2021-06-21 10:36||jean38||Note Added: 0015327|
|2021-06-21 10:40||jean38||Note Added: 0015328|
|2021-06-21 11:03||francis||Note Added: 0015329|
|2021-06-21 11:04||francis||Note Edited: 0015329|
|2021-06-21 11:10||jean38||Note Added: 0015330|
|2021-06-22 03:37||jean38||Note Added: 0015332|
|2021-06-29 10:02||francis||Note Added: 0015341|
|2021-06-29 10:02||francis||File Added: xsrf-token cookie.jpg|
|2021-06-29 10:02||francis||File Added: x-xsrf-token header.jpg|
|2021-06-30 03:08||jean38||Note Added: 0015342|
|2021-06-30 03:08||jean38||File Added: sogo_error_XSRF-2.png|
|2021-06-30 03:10||jean38||Note Added: 0015343|
|2021-06-30 03:10||jean38||File Added: 2021-06-30_09-08_XSRF_500.png|
|2021-06-30 03:29||jean38||Note Added: 0015344|
|2021-06-30 03:29||jean38||Note Added: 0015345|
|2021-06-30 03:29||jean38||File Added: 2021-06-30_09-08_XSRF_500_capture.png|
|2021-06-30 08:37||francis||Note Added: 0015346|
|2021-07-05 10:04||jean38||Note Added: 0015348|
|2021-07-05 10:04||jean38||File Added: 2021-07-05_15-43_XSRF_Http_only_off.png|
|2021-07-05 10:06||jean38||Note Added: 0015349|
|2021-07-05 10:06||jean38||File Added: 2021-07-05_15-43_XSRF_Http_only_off_header_OK.png|
|2021-07-05 10:48||francis||Note Added: 0015350|
|2021-07-05 11:34||francis||Changeset attached||=> sogo master f8f4de60|
|2021-07-05 11:34||francis||Assigned To||=> francis|
|2021-07-05 11:34||francis||Resolution||open => fixed|
|2021-07-05 11:34||francis||Status||new => resolved|
|2021-07-05 11:34||francis||Resolution||fixed => no change required|