Closed eidota closed 3 months ago
"integrity.check.disabled": "false",
[..]Integrity checker has been disabled. Integrity cannot be verified.
Any idea why your integrity check output conflicts with your configuration?
We have 2 Application Servers behind an HA-Proxy, the DB and redis are on its own servers.
Just to rule out things: are you doing any caching or header manipulation in HAProxy?
Also, how are you distributing traffic between the two app servers?
We use local nextcloud-accounts that are synchronised once a day via a custom script using occ-calls.
Synchronized to/from where?
And in some of these cases people get loaded into another users cloud.
Any pattern to what actions are taking place when this occurs? Is it immediately upon visiting? Or when going to edit an office document? Etc.
How frequently is this happening?
"loglevel": 3,
I would encourage you to set your loglevel back to the default (2) - particularly while trying to isolate this situation.
Also, can you fill in the app list as requested in the template (i.e. occ app:list
)?
"integrity.check.disabled": "false",
[..]Integrity checker has been disabled. Integrity cannot be verified.
Any idea why your integrity check output conflicts with your configuration?
No, as you see we didnt disable it via config. Do you have any idea where we can check further why its not working?
We have 2 Application Servers behind an HA-Proxy, the DB and redis are on its own servers.
Just to rule out things: are you doing any caching or header manipulation in HAProxy?
The proxy adds X-Forwarded-Proto and sets X-Forwarded-For and X-Forwarded-Port
Configuration for caching: total-max-size 1024 max-age 30
Also, how are you distributing traffic between the two app servers?
IP-based round-robin
We use local nextcloud-accounts that are synchronised once a day via a custom script using occ-calls.
Synchronized to/from where?
From our LDAP where we have prepared trees for the users and groups.
And in some of these cases people get loaded into another users cloud.
Any pattern to what actions are taking place when this occurs? Is it immediately upon visiting? Or when going to edit an office document? Etc.
Thats the problem. We cant see a clear pattern and it happens infrequently.
We have ~800 daily users at the moment and the problem was reported 1-3 times a day. Mostly it seems to be happening when visiting the cloud with an already active shibboleth-session. But we also had at least one case where it happened while using the cloud (editing a document in only-office)
How frequently is this happening?
see above
"loglevel": 3,
I would encourage you to set your loglevel back to the default (2) - particularly while trying to isolate this situation.
I set it back to 2 Also, can you fill in the app list as requested in the template (i.e.
occ app:list
)? I added the occ output to the initial post.
We downgraded the user_saml app to 6.1.3 as this was version was running fine before. As this didnt fix the problem we upgraded the server to 29.0.4. The problem persists.
Any idea if there where some changes since >28.0.4 that could connected to this? 28.0.4 + 6.1.3 was running fine for months and the first report from an user was some hours after we updated 28.0.4=>28.0.8.
Please let me know if you need more information and thank you for your time.
Any idea why your integrity check output conflicts with your configuration?
Because it is a string -> truthy. It should be 'integrity.check.disabled' => false
Are you using sticky sessions to keep sessions of one user on the same server? https://thisinterestsme.com/haproxy-sticky-sessions/
Any idea why your integrity check output conflicts with your configuration?
Because it is a string -> truthy. It should be
'integrity.check.disabled' => false
Thank you, now the output is: "No errors have been found."
Are you using sticky sessions to keep sessions of one user on the same server? https://thisinterestsme.com/haproxy-sticky-sessions/
We use sticky IP.
⚠️ This issue respects the following points: ⚠️
Bug description
This happens rather rarely, and we have not been able to reproduce it reliably.
What we have found out is that when loading the page, the "Logout" button is occasionally visible, which should not actually be there because of SSO. In this case, Nextcloud sets several unexpected cookies (nc_session_id, nc_token, nc_username) that are not normally present.
It seems that Nextcloud occasionally gets lost when checking the Shibboleth session and then loads in a local context. And in some of these cases people get loaded into another users cloud. We can also report that in the case of a correct session, the local cookies (nc_...) are also set when the page loading. These are then automatically removed again, presumably as soon as the shibboleth session has been verified. You only see a brief flicker of the cookies in the web tools before they disappear again.
On our IDP side, the requests and responses to Nextcloud look completely correct.
This problem occured first after we updated Nextcloud from 28.0.4 to 28.0.8 in the course of which user_saml was upgraded from 6.1.3 to 6.2.0
Steps to reproduce
Expected behavior
No access to foreign accounts.
Installation method
Community Manual installation with Archive
Nextcloud Server version
28
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.1
Web server
Apache (supported)
Database engine version
MariaDB
Is this bug present after an update or on a fresh install?
Updated from a MINOR version (ex. 28.0.1 to 28.0.2)
Are you using the Nextcloud Server Encryption module?
None
What user-backends are you using?
Configuration report
List of activated Apps
Nextcloud Signing status
Nextcloud Logs
No response
Additional info
We have 2 Application Servers behind an HA-Proxy, the DB and redis are on its own servers. We use local nextcloud-accounts that are synchronised once a day via a custom script using occ-calls. Authentification is realised with user_saml (Shibboleth). This setup is up and running since April.
user_saml configuration REMOTE_USER Mapped displayName and mail