Task #3342
closedSSO tokens are preserved across browser sessions
0%
Description
From André Littoz 's #3341:
I disconnected from the Discourse session by using the menu command associated with "avatar" at top right of screen (labeled Log Out). I was effectively disconnected but some token (cookie?) remained on my computer.
Next time I logged in, I did not need to enter manually my credentials as the token was automatically used (even if my computer was rebooted to make sure I started afresh).
Cookies set by the Single Sign-On system should be deleted when the current session ends. (I.e., expire
and max-age
attributes needs to be absent in the Set-Cookie
header.)
Updated by Guilhem Moulin about 4 years ago
Looking at Set-Cookie
header values I don't see any expire
and max-age
attributes. André Littoz , could it be that your browser doesn't delete so-called session cookies when you close it? Could you please open your browser (new session), visit https://auth.documentfoundation.org and authenticate, visit https://ask.libreoffice.org and authenticate (with username+password), then close your browser, restart it, and visit these two sites again. Are you pre-authenticated or do you land in an anonymous session?
Updated by André Littoz about 4 years ago
Recent versions of Firefox are not as convenient as older ones to examine cookies. You now need to be connected with the site to be able to dump them.
Is the site auth.documentation.org ?
EDIT OK, I figured out. I found "generic" cookies `.documentfoundation.org` plus specific "application" cookies`redmine.…` or `vm22.…`. I think the "critical" ones are those with name `lemonldap` and an apparently random hashed name, both in the "generic" domain and same for all applications. They have Session, HttpOnly and Secure attributes.
I'm beginning to suspect my problem is related to my workflow.
Updated by Guilhem Moulin about 4 years ago
André Littoz wrote:
I'm beginning to suspect my problem is related to my workflow.
Please try the experiment suggested earlier so we can confirm. :-)
Updated by André Littoz about 4 years ago
I confirm that after a full shutdown and restart (not a simple reboot), I still don't need to enter my credentials to log in.
Pressing the login link is enough to connect to Discourse and Redmine.
This means some information is persistent on my computer.
Updated by Guilhem Moulin about 4 years ago
André Littoz wrote:
Pressing the login link is enough to connect to Discourse and Redmine.
These two rely on the Single Sign-On portal (and the same auth protocol) for authentication. Please also check with AskBot (using username+password authentication not OAuth/OpenID) to confirm it's not an issue with our SSO system.
Updated by André Littoz about 4 years ago
AskLO signin with password
No persistent data. After sign-out, I must retype userid/password.
AskLO signin with Google
A click on this icon suffices to be connected. Some persistent data is kept somewhere.
Updated by Guilhem Moulin about 4 years ago
André Littoz wrote:
AskLO signin with password
No persistent data. After sign-out, I must retype userid/password.
Yes of course, but that's not what I was interested in. Quoting msg#1 of the present issue:
Guilhem Moulin wrote:
Could you please open your browser (new session), visit https://auth.documentfoundation.org and authenticate, visit https://ask.libreoffice.org and authenticate (with username+password), then close your browser, restart it, and visit these two sites again. Are you pre-authenticated or do you land in an anonymous session?
So do not log out. Just log in to these sites, close your browser, and start it again please (better not click the “restart” button as it might not completely flush the state).
Updated by Guilhem Moulin about 4 years ago
FWIW it appears AskBot doesn't set session cookies but cookies with a 1 year resp. 14 days lifetime.
$ curl -so/dev/null -D- https://ask.libreoffice.org/en/account/signin/ | grep -i ^Set-Cookie: set-cookie: ask.libreoffice.org_en_csrf=…; Domain=ask.libreoffice.org; expires=Thu, 02-Sep-2021 20:35:33 GMT; Max-Age=31449600; Path=/ set-cookie: libo-session-pt-br=…; Domain=ask.libreoffice.org; expires=Thu, 17-Sep-2020 20:35:33 GMT; httponly; Max-Age=1209600; Path=/
I'm not familiar enough with the AskBot authentication mechanism to comment on that. OTOH the Single Sign-On portal sets session cookies, and if your browser doesn't delete them when you close it I'm not sure what we can do about that.
André Littoz wrote:
AskLO signin with Google
A click on this icon suffices to be connected. Some persistent data is kept somewhere.
I read the exact opposite at https://vm222.documentfoundation.org/t/custom-log-in-control/115/8 . AFAICT the above 1/ suggests that your browser indeed doesn't close session cookies when you close it; and 2/ the log-out button doesn't act as a single sign-out (which TBH would be rather strange for a third-party Identity Provider).
Updated by André Littoz about 4 years ago
Before making the experiment as precisely described in comments #1 and #7, more information:
I used my laptop to connect to Discourse. Behaviour is totally different. Everything goes as expected. After logout and browser close, credentials are requested anew.
The main difference between my laptop and my desktop is my laptop has not been updated for months (because I want to backup safely works I did on it years ago and make sure data is accepted in newer versions of applications on my desktop; until I'm confident I won't lose data, the laptop is "frozen").
OS (Linux too) is lagging many releases behind my desktop. Firefox is an outdated version.
I disapprove directions taken by Mozilla security-wise. In latest Firefox versions, you can no longer set your own cookie acceptance and lifespan policy. Cookies are always stored and trying to mitigate that is quite cumbersome, needing to explore the local sites store. And even here, you can't selectively delete cookies, you can only enable or disable sites as a whole.
Considering the difference between my laptop and desktop, I think browser configuration/behaviour plays a role in the issue.
Updated by André Littoz about 4 years ago
Trial protocol as requested
Preparatory phase
I went to auth.documentationfoundation.org to logout. Took me several attempts to be really logged out.
Closed browser
Experiment
- open browser
- access auth.documentationfoundation.org to authenticate (leave tab open)
- access ask.libreoffice.org and log in with userid/password (leave tab open)
- close browser
- open browser
- both tabs are restored and show that I'm connected (auth page displays the password change form and AskLO the usual question list)
Technical details
- kernel Linux 5.8.4
- desktop KDE Plasma 5.18.5
- Firefox 80.0.1
Updated by Guilhem Moulin about 4 years ago
Thanks for trying! Based on this I'm tempted to close this as “can't fix”: I don't see what we can do on our end to fix this, but if you know of a cookie attribute to force deletion when the browser closes let us know :-)
Last quick experiment, does the same thing happens if you close the browser by closing all tabs successively?
- open browser
- open https://auth.documentationfoundation.org in a new tab, authenticate
- open https://ask.libreoffice.org in a new tab, log in with userid/password
- close both tabs (I guess closing the last tab closes the browser)
- open browser
- visit https://auth.documentationfoundation.org again: are you pre-authenticated
- visit https://ask.libreoffice.org again: are you pre-authenticated?
(For AskBot this is not too surprising since it doesn't set session coookies, however for the the SSO portal the situation is different.)
Updated by André Littoz about 4 years ago
Last experiment
- log out from documentfoundation.org with explicit argument ?logout=1 (from bookmarks)
- close browser
- open browser
- new tab to auth.…, authenticate
- new tab to ask.libreoffice.org, log in with userid/password (not through OpenID)
- close auth tab
- close ask tab
- close browser
- open browser
- new tab to auth, screen displays page to change password (hence already logged in)
- new tab to ask, already logged in
Don't close the ticket for the moment. I'll install a VM with basic configuration when I have time. I want to make sure that nothing in my daily configuration is causing the problem.
Meanwhile, I've bookmarked the full sign out URL and this is an acceptable workaround.
Side remark:
For several weeks now, it has been impossible to login into AskLO with Yahoo!. I must use either Google (which I don't like) or userid/password. It already happened in the past and was fixed. Can you do something about that?
Updated by Guilhem Moulin about 4 years ago
- Status changed from New to Rejected
André Littoz wrote:
Last experiment
I'll install a VM with basic configuration when I have time. I want to make sure that nothing in my daily configuration is causing the problem.
An intermediate step would be to try with a throw-away profile (and disabling all extensions to be sure). I ran MOZILLA_DISABLE_PLUGINS=y firefox-esr -no-remote -Ptransient-rdm3342
. This is with Firefox 68 ESR on Debian sid, dunno if some of this is Debian-specific or not.
- Visit
about:addons
, disable all extensions, close the tab to close the browser. - Start the browser using the same command, open https://auth.documentfoundation.org , authenticate, and close the tab (without logout) to close the browser.
- Start the browser using the same command, open https://auth.documentfoundation.org . I land on the authentication page (“Authentication required”) so the session did not survive the browser restart.
With Chromium 83 on the same system, started with chromium --user-data-dir="$XDG_RUNTIME_DIR/transient-chromium-rdm3342"
. ("$XDG_RUNTIME_DIR/transient-chromium-rdm3342"
is initially inexistent.)
- Visit
chrome://extensions/
, disable all extensions, close the tab to close browser. - Start the browser using the same command, open https://auth.documentfoundation.org , authenticate, and close the tab (without logout) to close the browser.
- Start the browser using the same command, open https://auth.documentfoundation.org . I land on the authentication page (“Authentication required”) so the session did not survive the browser restart.
Closing this for now, will reopen if needs be.
Side remark:
For several weeks now, it has been impossible to login into AskLO with Yahoo!.
This would warrant a separate ticket :-P Note also that https://ask.libreoffice.org is normally managed by upstream not the infra team.