Chrome Browser OIDC Login Fails Due to Session oidc_state Loss

[jacac]

Describe the Bug

When logging in to BookStack using OpenID Connect (OIDC) in the Chrome browser, the login process fails and loops between BookStack and the OIDC provider. After a few loops the login succeeds.

Steps to Reproduce

• Configure BookStack with OIDC authentication.
• Open Bookstack.
• Observe the session state in the session store (Redis in my case)
• Click on the login button.
• Observe the oidc_state in the session.
• After a few seconds observer the oidc_state. It was missing for me.

Expected Behaviour

The OIDC login flow should complete successfully in Chrome without being interrupted by unrelated or failing resource requests. The oidc_state should be preserved until the authentication process is finalized.

Screenshots or Additional Context

The issue occurs because Chrome triggers additional requests (such as manifest.json, opensearch.xml, and even 404 requests like /dist/app.js.map (if DevTools are open) during the login flow. These requests interfere with the session handling of oidc_state. session()->flash() only preservers it for the next request. https://github.com/BookStackApp/BookStack/blob/cf847974d2ffcddd9ffc10ad524237bf4b462a50/app/Access/Controllers/OidcController.php#L33 causing it to be removed before the login completes The subsequent check during the callback fails in https://github.com/BookStackApp/BookStack/blob/cf847974d2ffcddd9ffc10ad524237bf4b462a50/app/Access/Controllers/OidcController.php#L48

Browser Details

Chrome Version 142.0.7444.176

Exact BookStack Version

v25.07.3

[ssddanbrown]

Thanks for reporting @jacac. I've been trying to assist someone with very similar issues, which have been hard to re-produce, so thanks for digging into this to find the cause as it's helped considerably.

At a glance, and based on timing, it's probably only arising now due to this change: https://github.com/BookStackApp/BookStack/commit/fcef1a7948bff6da083f7d727fbcbf269fbe9252

Since before this would not have been part of the session. I'll mark this as a priority, with an aim to confirm, cover with testing, and patch into a new release tomorrow.

[jacac]

Maybe I should also mentioned that I blocked request on my proxy to opensearch.xml with a 404 return.

Steps/Experience:

1. After logging out, refreshing the page multiple times could restore a previous login session.
2. After logging in and navigating through several pages, the session could unexpectedly end (user logged out again).

Workaround: I blocked requests to opensearch.xml at the proxy level (returning 404). This prevented the session from resetting to a prior state and stabilized login/logout behavior.

Notes: I could not reproduce this on Firefox.

[hwangsvb]

Experiencing the same issue here. Tested on edge, chrome, and firefox, likely a chromium issue as it does not occur on firefox.

Issue started happening after updating from 25.07.2 to 25.07.3. An old clone of the instance running 25.07 is not having issues.

[ssddanbrown]

Unfortunately I have not been able to replicate this on either chrome or chromium (on OpenSuse) so wonder if other factors are in play. I can see that there are frequent manifest requests in these browsers, and opensearch requests are performed with cookies (and therefore would use sessions).

Regardless, the scenario can still be manually replicated so I'll look to change the flow to instead not depend on the next response being the callback (via session flashing) but instead be more persistent yet time limited. I'll also maybe add a little bit of caching via headers to the manifest responses just to prevent chromium browsers adding extra load via redundant repeated calls.

[ssddanbrown]

This has now been addressed by the changes in adfac3e30ebb5a407cb72e3546f0756ab63f298d, and these will be part of the next patch release which I'll put out within the next hour or so.

Thanks again for reporting and providing input @jacac @hwangsvb. Please let me know though if you continue to experience any issues after the update and this can be re-opened.

[hwangsvb]

updated to 25.11.5 and issue is still happening

for a bit more context: bookstack is running in docker on ubuntu 24.04.3 LTS using nginx as reverse proxy

[ssddanbrown]

@hwangsvb I'm not sure what might be going wrong for you then.

Having issues from 25.07.3 would indicate that it was due to the manifest requests, since there were little other changes in that release. But those should really not interfere with the login flow with the new changes. Are you confident you're running v25.11.5? (just checking since you mentioned docker since docker-based releases can be delayed).

[hwangsvb]

yes, can confirm running 25.11.5 using this image: https://hub.docker.com/layers/linuxserver/bookstack/version-v25.11.5/images/sha256-da5e49f7e867fd20a6c6e554eeaa017228c6788f63f19ff71fd46758cb1113fa

[jacac]

@hwangsvb Could you try blocking opensearch.xml in Nginx and delete all browsing data and see if you are still getting it? Something like: location ~ /opensearch.xml { return 404; }

[hwangsvb]

@jacac have just tested and for me blocking manifest.json is what resolves the issue.

[igittigitt]

I also got the same problem when trying to implement an alternative "Auto Login" by an URL parameter (?autologin=true). We had this requirement due to the fact that we like to provide public information without any login, but also internal information where a SSO login is required. For the convenience of our users we provide a link to the BookStack instance having the above param added and so they should be "in" automatically (as we also use Kerberos integration in out Browsers and Keycloak SSO). That worked, but only by adding a short timeout of 200 ms or more bewett detecting the login-page and submitting the login-button form. We run BS 25.11.3

[ssddanbrown]

@hwangsvb @igittigitt Could I confirm your URL setup. Are you hosting your instance on a URL sub-path? Or is the instance at the root of the domain/sub-domain? Do you have any SESSION_* options configured in your BookStack env config? If so, which?

@jacac Is this fixed for you without blocking requests, or does the issue remain?

[igittigitt]

@ssddanbrown sorry, i should have made a better userstory, so i corrected it afterwards. After updating to 25.11.5 it was much more stable. No more "manifest.json" and the submit-timeout could be set down to 100 ms (maybe less, but that was ok for us) and is now works all the time. I think when i send the form too fast, the internal system has not fully written the session data into the DB and the subsequent request runs into an undefined status.

For all who might want to do something similar, this is my Javascript code i've added in the customization page of BookStack:

  /* if login-button exists in the header navbar, the user is not logged in */
  const urlParams = new URLSearchParams(window.location.search);
  const isLoggedIn = document.querySelector('#header a[href$="/login"]') === null;
  if (!isLoggedIn && urlParams.get('autologin') === 'true') {
    const submitForm = document.getElementById('login-form');
    if (submitForm) {
      setTimeout(()=>{
        submitForm.submit();
      }, 100);
    }
  }
</script>

If you now call https://mybookstack.domain/login?autologin=true you get logged in like with "AUTH_AUTO_INITIATE=true" but only by using this parameter. If an (public) user get to BookStack, he will stay there and not get redirected to SSO. Maybe this is something i should create a feature-request for? To add another option which is only logging in users who click on the upper right login-button, but not if he is just visiting the page?

And no, i did not set any SESSION_* options. Do you suggest so, and if, which?

[hwangsvb]

@ssddanbrown root of subdomain. no session_* options.

[Tomblarom]

I'm the someone with very similar issues and updating to v25.11.6 solved it. 😉 I tested with Chrome+Firefox. The login now succeeds every time and never shows this error message:

I noticed that it only briefly shows it, when I refresh the page and leave /oidc/callback?code=[..] in the URL. But the login still succeeds. Without the callback-code, it never shows the error message.

Note: by succeed I mean, it shows the dump, because I currently have OIDC_DUMP_USER_DETAILS=true.