•  
      request #35847 Management of session expiration
    Infos
    #35847
    Manuel Vacelet (vaceletm)
    2024-06-18 17:47
    2024-01-12 11:33
    37449
    Details
    Management of session expiration

    Right now there are a couple of situations where we can loose the navigation due to session expiration:

    • When someone stay on a page for too long and reload the page (either Ctrl + R or restart of browser with tabs that reloads the previously browsed pages) => we end up on "tuleaplogin" page that doesn't do any login and we loose the original page.
    • When someone edit a page and the session expire, there is no transparent renew of the token and the editor has to do some ticky manipulation to force renew of the token in another tab before being able to save.
    Mediawiki Standalone
    Empty
    Empty
    • [ ] enhancement
    • [ ] internal improvement
    Robert Vogel (rvogel), Dejan Savuljesku (dsavuljesku)
    Stage
    Manuel Vacelet (vaceletm)
    Closed
    2024-06-18
    Attachments
    References
    Referencing request #35847
    Referenced by request #35847

    Artifact Tracker v5

    rel #36799 15.10

    Follow-ups

    User avatar

    Since Laetitia is out of office: Due to the public holiday this week, the delivery date will be Monday, June 3rd.

    User avatar
    Thomas Gerbet (tgerbet)2024-05-06 17:41

    The refresh_token is not really suitable here, it grants a long lived token per user and as a general rule this should be avoided. Also, as specified in the OIDC specification when using it it is mandatory to request the offline_access scope which require consent every single time. Also I'm a bit confused about when this token would be used, it is used elsewhere then when retrieving the sidebar/theme info almost right after the login flow?

    We might have 2 issues mixed in this situation. For

    When someone stay on a page for too long and reload the page (either Ctrl + R or restart of browser with tabs that reloads the previously browsed pages) => we end up on "tuleaplogin" page that doesn't do any login and we loose the original page.

    There is a quick way to reproduce it:

    1. In fresh browser (no cookie/session whatever), access to /index.php?title=Special:TuleapLogin&returnto=Main_Page
    2. The auth flow happens and we are properly redirected to Main_Page
    3. Access /index.php?title=Special:TuleapLogin&returnto=Main_Page again, nothing happens. We are still properly authenticated so I would have expected to be redirected to the Main_Page directly

    We end up on this page when browser tabs are restored after a start or frozen then restored by the browser if you keep them without using it for a quite a long time. I'm not sure why we end up on this page but we should be probably redirected anyway. I'm guessing this is the part of the code that is incorrect: https://github.com/wikimedia/mediawiki-extensions-TuleapIntegration/blob/d2ff0b6efa2aa7a49934bde92ede165ace4cfaf7/src/Special/TuleapLogin.php#L231-L242 as it always expects to find the value from the session which it is not the case when it's a direct access.


    User avatar

    @vaceletm we have analysed this topic. One thing that worries us is that in the code it says "Cannot refresh" as a comment for when the token has expired. So we have an important question: Is the refresh token flow supported on Tuleap? Can you please confirm? If yes, it would take us about 4 hours to implement this refresh_token.

    User avatar

    Is session-loss a general issue? Like the session expires too quickly / gets lost frequently?

    I don't think so. It's a good thing if the session expire "quickly" as long as it's transparent for the end user. It's the best way we have to ensure that user still have access to Tuleap.

    It may be a good idea to use the database as a session store, if that's not already the case.

    It's already used: https://tuleap.net/plugins/git/tuleap/tuleap/stable?a=blob&f=plugins/mediawiki_standalone/additional-packages/mediawiki-tuleap-config/LocalSettings.Tuleap.php#L153