Chrome Browser OIDC Login Fails Due to Session oidc_state Loss #5531

New Issue

OVERLORD · 2026-02-05T10:08:57+03:00

OVERLORD commented

2026-02-05 10:08:57 +03:00

Originally created by @jacac on GitHub (Dec 1, 2025).

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. cf847974d2/app/Access/Controllers/OidcController.php (L33) causing it to be removed before the login completes The subsequent check during the callback fails in cf847974d2/app/Access/Controllers/OidcController.php (L48)

Browser Details

Chrome Version 142.0.7444.176

Exact BookStack Version

v25.07.3

Originally created by @jacac on GitHub (Dec 1, 2025). ### 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

OVERLORD added the 🐛 Bug 🚀 Priority labels 2026-02-05 10:08:57 +03:00

OVERLORD commented

2026-02-05 10:08:59 +03:00

@ssddanbrown commented on GitHub (Dec 2, 2025):

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:
fcef1a7948

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.

@ssddanbrown commented on GitHub (Dec 2, 2025): 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.

OVERLORD commented

2026-02-05 10:09:02 +03:00

@jacac commented on GitHub (Dec 2, 2025):

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

Steps/Experience:

After logging out, refreshing the page multiple times could restore a previous login session.
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.

@jacac commented on GitHub (Dec 2, 2025): 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.

OVERLORD commented

2026-02-05 10:09:05 +03:00

@hwangsvb commented on GitHub (Dec 2, 2025):

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.

@hwangsvb commented on GitHub (Dec 2, 2025): 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.

OVERLORD commented

2026-02-05 10:09:06 +03:00

@ssddanbrown commented on GitHub (Dec 3, 2025):

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 commented on GitHub (Dec 3, 2025): 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.

OVERLORD commented

2026-02-05 10:09:07 +03:00

@ssddanbrown commented on GitHub (Dec 3, 2025):

This has now been addressed by the changes in adfac3e30e, 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.

@ssddanbrown commented on GitHub (Dec 3, 2025): 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.

OVERLORD commented

2026-02-05 10:09:08 +03:00

@hwangsvb commented on GitHub (Dec 3, 2025):

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

@hwangsvb commented on GitHub (Dec 3, 2025): 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

OVERLORD commented

2026-02-05 10:09:10 +03:00

@ssddanbrown commented on GitHub (Dec 4, 2025):

@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).

@ssddanbrown commented on GitHub (Dec 4, 2025): @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).

OVERLORD commented

2026-02-05 10:09:11 +03:00

@hwangsvb commented on GitHub (Dec 4, 2025):

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

@hwangsvb commented on GitHub (Dec 4, 2025): yes, can confirm running 25.11.5 using this image: https://hub.docker.com/layers/linuxserver/bookstack/version-v25.11.5/images/sha256-da5e49f7e867fd20a6c6e554eeaa017228c6788f63f19ff71fd46758cb1113fa

OVERLORD commented

2026-02-05 10:09:12 +03:00

@jacac commented on GitHub (Dec 5, 2025):

@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; }

@jacac commented on GitHub (Dec 5, 2025): @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; }`

OVERLORD commented

2026-02-05 10:09:12 +03:00

@hwangsvb commented on GitHub (Dec 9, 2025):

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

@hwangsvb commented on GitHub (Dec 9, 2025): @jacac have just tested and for me blocking manifest.json is what resolves the issue.

OVERLORD commented

2026-02-05 10:09:13 +03:00

@igittigitt commented on GitHub (Dec 9, 2025):

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

@igittigitt commented on GitHub (Dec 9, 2025): 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

OVERLORD commented

2026-02-05 10:09:14 +03:00

@ssddanbrown commented on GitHub (Dec 9, 2025):

@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?

@ssddanbrown commented on GitHub (Dec 9, 2025): @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?

OVERLORD commented

2026-02-05 10:09:15 +03:00

@igittigitt commented on GitHub (Dec 9, 2025):

@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?

@igittigitt commented on GitHub (Dec 9, 2025): @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: ```<script type="module"> /* 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?

OVERLORD commented

2026-02-05 10:09:17 +03:00

@hwangsvb commented on GitHub (Dec 9, 2025):

@ssddanbrown root of subdomain. no session_* options.

@hwangsvb commented on GitHub (Dec 9, 2025): @ssddanbrown root of subdomain. no session_* options.

OVERLORD commented

2026-02-05 10:09:17 +03:00

@Tomblarom commented on GitHub (Dec 10, 2025):

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.

@Tomblarom commented on GitHub (Dec 10, 2025): 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: <img width="453" height="159" alt="Image" src="https://github.com/user-attachments/assets/3916bedb-f2d7-4273-9b2e-f190580be1d0" /> 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`.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#5531