Which SSO do you use?

What have you set for "Settings" --> "General" --> "General" --> "Refresh View"?

I use SAML
It's set to "Every Minute" as I don't like to miss out on emails..

the worst thing is that when you're somehwere in the past or future, especially in the calendar, you get back to the mail.

How long lasts your SAML Token?

Do you at least stay where you are when setting "Settings" --> "General" --> "General" --> "Default Module" to "Last Used"?

I'm not sure about the token duration, we have a "Session duration" which lasts till the user closes the browser.

This works ""Settings" --> "General" --> "General" --> "Default Module" to "Last Used"?"

we have a "Session valid not on or after" which "tells" the app that it should be logged in for 8400minutes rn

I updated SoGo to v5.3 and the problem is a bit worse now. when I first log-in (also after every reload - login (issue)) it takes about 15 seconds and then reloads to login again) sometimes it needs 4 "logins" (without interaction) just to load the inbox like this.

is there something I can do for debugging / logging to help fix the problem?

Have you looked at SOGoCacheCleanupInterval?

I changed this value from "900" to "10" and restarted sogo but it's not happening more often. it stays the same.

Do you run /usr/sbin/sogo-tool expire-sessions XXXin your cron job under /etc/cron.d/sogo?
If yes, which value are you using for the expiration time XXX

yes, I use "60"

So an inactive session is removed after an hour.
Therefore this too isn't the problem.

Do you have SOGoXSRFValidationEnabled = NO; in your sogo.conf?

I don't have "SOGoXSRFValidationEnabled" in my sogo.conf

This setting is mandatory for SAML usage.
Please add it.

I added the settings and restarted sogo but it doesn't fix it. (I actually don't see a difference).

any other idea?
is there a place where I can get logs from the behaviour?

sadly I cannot get a support-contract rn.. also because I'm not yet ready to sfart my OpenSource business.. But I would pay 200$ fixing this., and yes.. I know it's value is higher but that what I could pay rn..

I think this is fixed! it didn't happen anymore today on my 5.5.0!
love you :)

there's no way to close this issue on my own, right?

weird.. now it's happening again.

but it's better than before. It happens less often and the claendar keeps the right week open.
But when I compose a fresh email and it happens it will still discharge it.

yeah.. I need to correct that too.. " the calendar keeps the right week open " not really.. it goes to inbox as before

any way to speed this up? :)

I guess you could try purchase a support contract.

I finally really logged SAML client side.
which always resulted in a reload exactly after 4 minutes.

when I search the users-maillist I find multiple entries like this one, describing the same issue:
https://marc.info/?l=sogo-users&m=159320330828903&w=2

they always say that adjustements of the Entry "SOGoCacheCleanupInterval" in sogo.conf will fix it.
That's not the case anymore as I tried with much higher amounts (currently 43200).

there's also no entry with "240" == 4 minutes. inside sogo.conf

If the cache is getting wiped before SOGoCacheCleanupInterval has expired, maybe you need to look at your memcached instance to see what's happening there?

what I see on my sogo-instance is this:

<0x0x55e528ee0c80[SOGoWebAuthenticator]> Expired session received, redirecting to login page.
<0x0x55e528f6c880[SOGoWebAuthenticator]> tried wrong password for user '/verylongstring'! -> is there a way to find out wht user is meant exactly? base64 doesn't seem to be it.

I try to get logs from memcached..

Could the "very long string" be the SAML assertion given as password?
See here: https://github.com/ck-ws/pam-script-saml/

yes, I think so.

Are your servers synchronized with the same time/ntp server?

yes, they also show exactly the same time.

maybe it's just my /etc/pam.d/common-auth
it looks like this (removed the comments):
auth [success=1 default=ignore] pam_unix.so nullok
auth requisite pam_deny.so
auth required pam_permit.so
auth required pam_script.so grace=43200

maybe it's just my /etc/pam.d/common-auth it looks like this (removed the comments):

auth [success=1 default=ignore] pam_unix.so nullok
auth requisite pam_deny.so
auth required pam_permit.so
auth required pam_script.so grace=43200

maybe someone has a working example for his "/etc/pam.d/" -config?

update:
It has to be in sogo..
IO forgot that I just circumvented dovecot-auth when I setup SAML by whitelisting SoGos internal IP.. so I don't need to configure pam for dovecot.

alright.. mistery resolved.. not an issue with sogo. But an issue with my user-synch.. this issue can be closed.
I thank you all very much for the great support, I think I learned some things.

but what I also tested now is lowering the cache.. and it doesn't change anything.. so "SOGoCacheCleanupInterval" can stay on a lower value (tested with 200), it wouldn't log me out.