Hi SOGo user list. Hoping for guidance please. SOGo 5.12.2 (upgraded from 5.8.0 or so) configured with SAML via Keycloak 26.2.4. MariaDB 11.8.2
Broadly speaking everything works very well. However I am experiencing sogo web session timeout consistently approx 5min after login (not aligned with cron execution). As the session is still valid in Keycloak it drops to Keycloak then immediately returns to the SOGo web interface with only a small (500ms) delay. However if the user is in the middle of drafting an email any edits since the last autosave are lost and the draft is closed and needs to be reopened to continue. Autosave is set to 1min to mitigate. I have confirmed that sogo_sessions_folder table in MariaDB is being populated. Structure is: > describe sogo_sessions_folder; +----------------+--------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +----------------+--------------+------+-----+---------+-------+ | c_id | varchar(255) | NO | PRI | NULL | | | c_value | text | YES | | NULL | | | c_creationdate | int(11) | NO | | NULL | | | c_lastseen | int(11) | NO | | NULL | | +----------------+--------------+------+-----+---------+-------+ 4 rows in set (0.001 sec) Session timeout is not aligned to cron job executions. In the instant before timeout the sogo_sessions_folder session is updated with the new ‘lastseen’ value however on return from keycloak a new session is written into the database and the old session(s) is eventually expired. The log file shows the following: 2025-07-02 14:53:07.043 sogod[869523:869523] <MySQL4Channel[0x0x5644342e0620] connection=0x0x5644344ab160> SQL: SELECT t1.c_creationdate, t1.c_id, t1.c_lastseen, t1.c_value FROM sogo_sessions_folder t1 WHERE t1.c_id='REDACTED'; 2025-07-02 14:53:07.043 sogod[869523:869523] <MySQL4Channel[0x0x5644342e0620] connection=0x0x5644344ab160> query has results, entering fetch-mode. 2025-07-02 14:53:07.043 sogod[869523:869523] <MySQL4Channel[0x0x5644342e0620] connection=0x0x5644344ab160> SQL: ROLLBACK; 2025-07-02 14:53:07.044 sogod[869523:869523] <MySQL4Channel[0x0x5644342e0620] connection=0x0x5644344ab160> query has no results. 2025-07-02 14:53:07.044 sogod[869523:869523] <MySQL4Channel[0x0x56443414c950] connection=0x0x5644340a4be0> SQL: BEGIN; 2025-07-02 14:53:07.044 sogod[869523:869523] <MySQL4Channel[0x0x56443414c950] connection=0x0x5644340a4be0> query has no results. 2025-07-02 14:53:07.044 sogod[869523:869523] <MySQL4Channel[0x0x56443414c950] connection=0x0x5644340a4be0> SQL: UPDATE sogo_sessions_folder SET c_lastseen = 1751433787, c_creationdate = 1751433457, c_value = 'VERY_LONG_REDACTED_TOKEN', c_id = 'REDACTED' WHERE c_id='REDACTED'; 2025-07-02 14:53:07.045 sogod[869523:869523] <MySQL4Channel[0x0x56443414c950] connection=0x0x5644340a4be0> query has no results. 2025-07-02 14:53:07.045 sogod[869523:869523] <MySQL4Channel[0x0x56443414c950] connection=0x0x5644340a4be0> SQL: COMMIT; 2025-07-02 14:53:07.047 sogod[869523:869523] <MySQL4Channel[0x0x56443414c950] connection=0x0x5644340a4be0> query has no results. Jul 02 14:53:07 sogod [869523]: <0x0x5644339a4b70[SOGoWebAuthenticator]> tried wrong password for user 'VERY_LONG_REDACTED_TOKEN_WITH_63_LEADING_CHARACTERS_CHANGED'! The 'VERY_LONG_REDACTED_TOKEN' from the SQL UPDATE is the value from the c_value field in the sogo_sessions_folder table. I haven't been able to decode what the meaning of the 63 changed leading characters in the 'user' attempt toward SOGoWebAuthenticator represents but only the leading 63 characters (out of some 600++) are altered. The "tried wrong password for user" has been the focus of my diagnostic effort. In this context (https://github.com/Alinto/sope/blob/master/sope-appserver/NGObjWeb/SoObjects/SoCookieAuthenticator.m#L255) I believe this refers to session details stored in the cookie file. If I open a draft immediately on login I can see via detailed logging that the cookie details succeed the first 4 authentication checks (it appears a check is undertaken as a test immediately prior to autosave). On the 5th attempt / 5 minutes the identical check appears to fail with the error message above “tried wrong password for user”. The c_id changes from one login session to the next but not within a single login session as far as I can tell. Altering various session timeout / token validity periods within Keycloak has no impact at all. I am also getting the following two errors which may be related and are included for completeness: (process:1035072): Lasso-CRITICAL **: 23:41:45.860: 2025-07-02 23:41:45 (profile.c/:913) Trying to unref a non GObject pointer file=profile.c:913 pointerbybname=profile->identity pointer=0x55556efe2b30 (process:1035072): Lasso-CRITICAL **: 23:41:45.860: 2025-07-02 23:41:45 (profile.c/:916) Trying to unref a non GObject pointer file=profile.c:916 pointerbybname=profile->session pointer=0x55556ec0b210 I tried SOGoTrustProxyAuthentication = YES; but no change in behaviour. I have SOGoXSRFValidationEnabled = YES; Any advice would be greatly appreciated. Mark.
