phoenix logout happens while working

[jnweiger]

Reproduce on ocis 1.0.0-beta8, 1.0.0-rc1 with eos installed via https://github.com/owncloud-docker/compose-playground/blob/master/examples/hetzner-deploy/make_ocis_eos_compose_test.sh

• log in user einstein with firefox
• slowly do many actions: upload files, create folders, delete files, remove folders, so that time passes.
• while working, suddenly a logout occurs:
• I can continue type the folder name, but 'Create' does nothing.
• 'Cancel' makes the requester disappear, leaving me on a normal login screen

Expected behaviour:

• No. Do not interrupt users like that.

[micbar]

Could be fixed now. Phoenix silent redirect is now implemented.

beta8 was shipped with the fix but without the redirect url in the indentifier-registration.yml

@jnweiger can you confirm?

[micbar]

I have been logged in to ocis.owncloud.works for 6 hours.

Closing now

[jnweiger]

@refs fyi

[refs]

reopening issue, I was able to reproduce this on owncloud/ocis#409

[refs]

regardless of being logged out, the dialog should at least disappear.

[davitol]

Tested with ocis-1.0.0-rc1 via https://gitea.owncloud.services/jw/hetzner/src/branch/master/make_ocis_eos_test.sh

Still reproducible.

[jnweiger]

The logout happens exactly 10 min after login. Reproducable with or without user actions.

Expected behaviour according to @micbar :

• a token refresh is performed
• no autologout.

[jnweiger]

Tested on https://ocis.owncloud.works

Same there. Autologout after exactly 10 Minutes.

[jnweiger]

Large uploads / downloads break when hitting the 10 Minutes limit.

[pmaier1]

The logout happens exactly 10 min after login. Reproducable with or without user actions.

I can confirm that.

Potential explanation by @PVince81

the Phoenix UI is periodically sending a request to fetch notifications if one of those calls return 401 for example when the bearer token expired, it will redirect to the login page

[butonic]

hm locally the silent refresh works and keeps updating the access token ... so, might be a config issue ...

[butonic]

definitely a config issue. on localhost I see token refresh requests, which do not happen on ocis.owncloud.works

[butonic]

I take it back ... it just fetched a new access token on ocis.owncloud.works

[jnweiger]

yes, ocis.owncloud.works and my setup script both have the same config issue, if it is a config issue. 10min logout everywhere.

[jnweiger]

Retested with

• ocis master from 5h ago
• firefox
• chromium

ocis master version details

OCIS_VERSION:         master
ocis --version:       ocis version 7b8e9bc
git log:              commit 7b8e9bc2981c0fd9917bc576a291ab5231c02685 (HEAD -> refs/heads/master, refs/remotes/origin/master, refs/remotes/origin/HEAD)
eos --version:        EOS 4.6.5 (2019)
xrootd -v:            v4.11.0
bin/ocis contains:
    owncloud/ocis-accounts@v0.4.2-0.20200911161616-e55b8ae2f440
    owncloud/ocis-glauth@v0.5.1-0.20200909064150-0735ec933777
    owncloud/ocis-graph-explorer@v0.0.0-20200210111049-017eeb40dc0c
    owncloud/ocis-graph@v0.0.0-20200318175820-9a5a6e029db7
    owncloud/ocis-hello@v0.1.0-alpha1.0.20200828085053-37fcf3c8f853
    owncloud/ocis-konnectd@v0.3.2
    owncloud/ocis-migration@v0.2.0
    owncloud/ocis-ocs@v0.3.2-0.20200916110615-7ca52baa61c4
    owncloud/ocis-phoenix@v0.13.1-0.20200910090722-8e3ed0e966a5
    owncloud/ocis-pkg/v2@v2.4.1-0.20200902134813-1e87c6173ada
    owncloud/ocis-proxy@v0.7.1-0.20200907105449-201b9a652685
    owncloud/ocis-reva@v0.14.0
    owncloud/ocis-settings@v0.3.2-0.20200903035407-ad5de8264f91
    owncloud/ocis-store@v0.1.1
    owncloud/ocis-thumbnails@v0.3.0
    owncloud/ocis-webdav@v0.1.1

Rumors about increased 1h timeout instead of 10min cannot be confirmed with this deployment. Both tested browsers log out exaxtly after 10 min.

[exalate-issue-sync[bot]]

Alex Unger commented: As mentioned in the standup today, providing and endpoint / cli command to dump configuration of every service would be helpful during the debug process. Having the versions is not enough debug information. Is there a feature request already?

[exalate-issue-sync[bot]]

Patrick Maier commented: We have this epic https://jira.owncloud.com/browse/OCIS-47 for config/crash reports. Still empty but I'm very happy if you dump all things we need for supporting/debugging OCIS later on there.

[exalate-issue-sync[bot]]

David Christofas commented: Did some testing and observed different behaviors...

Multiple times while trying to upload a big file (ca. 800MB) the upload was interrupted by the logout. (Unsuccessful token refresh)

One time the upload worked though.

And then a few times I just did some slow tasks like uploading small files or deleting files and I was logged out 2 times but also not logged out 2 times... Couldn't find any hint in the logs why this was happening.

Need to do more investigation.

[exalate-issue-sync[bot]]

David Christofas commented: An idea that just came to my mind is that maybe when ocis gets redeployed it causes these random logouts?

It shouldn't since the auth mechanism is stateless but who knows...

[exalate-issue-sync[bot]]

David Christofas commented: So I think the normal silent refresh at ocis.owncloud.works works without problems. But as soon as somebody merges something to ocis/master and ocis gets restarted, konnectd is also restarted and will generate new secrets for signing etc.

This should be solve once we configure static secrets.

When konnectd is regenerating new secrets, it cannot verify the old jwt anymore since they were signed with the old secrets. So that could result in "random" logouts.

[exalate-issue-sync[bot]]

Jörn Friedrich Dreyer commented: qa saw a problcem when switching users. check if the timeout occurs after switching from einstein to marie.

[exalate-issue-sync[bot]]

David Christofas commented: So I configured a static secret and a RSA keypair for konnectd on ocis.owncloud.works now when the service gets restarted the jwts are still valid (until they expire).

[exalate-issue-sync[bot]]

David Christofas commented: After more experiments I could observe that normal silent refreshes work but if some long running upload is happening or some action is started exactly between the old token expiring and before the new token was aquired then the application will logout.

So we have to find a solution for long running uploads. I'm not too sure if the actions timed between expiration and refresh are occuring often or not.

[exalate-issue-sync[bot]]

Michael Barz commented: ok, so the bug ticket can e´be closed.

We need a follow up.

Created https://jira.owncloud.com/browse/OCIS-698