Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Concurrency Issues #222

Open
davidmilligan opened this issue May 12, 2022 · 1 comment
Open

Concurrency Issues #222

davidmilligan opened this issue May 12, 2022 · 1 comment

Comments

@davidmilligan
Copy link

We have an app running in a cluster managed as a service for us, that uses authservice and keycloak to provide auth for us "automatically". The app utilizes a service-worker.js to provide PWA functionality. The problem we're running into is that when the user needs to re-authenticate (tokens have expired or whatever), a request receives a 302 response to keycloak, and the redirect is followed (as expected), the user goes through the login process, and when they complete it and get redirected back, it hasn't actually worked and they get redirected back to the login again. It appears this is happening because after the initial redirect request, while the user is on the login page, the browser decides to, of its own accord, make a request for /service-worker.js in the background (presumably checking to see if it's up-to-date), and this exact behavior varies from browser to browser. This subsequent background request seems to be "fudging up" the original login attempt. As if every new request that is intercepted by authservice, will somehow "invalidate" or "break" any previous or currently "in-progress" re-authentication attempts.

Is this the expected behavior of authservice? for it not to be able to handle concurrent requests like this? Is there anything we can do about it via configuration? Is there some way to have particular paths (i.e. /service-worker.js) ignored for the redirect attempts, but still get the JWT attached if the user is actually already logged in.

The service-worker.js itself can be used to intercept any requests before they leave the client and block them, or prevent following of redirects, etc., which is what we had to do initially to get this working at all (even with the multiple login attempts required). However, the browser attempts to fetch 'service-worker.js` of it's own accord, at various and uncontrollable times, and obviously, not routing those requests through the existing service worker (would be pretty circular if it did). I'm not sure if the browser is actually attempting to follow the redirect and that's what is messing up the flow, or if it's just enough that the request is made at all to mess things up.

Thanks for any insight.

@davidmilligan
Copy link
Author

I'll also add, that I know probably typically, you'd have static assets like this service-worker.js simply available on public routes ("not behind auth" so to speak) and this wouldn't be a problem, but we have security requirements imposed by the manager/operator of our cluster that apps must be "completely" behind auth (so not even inconsequential, static assets like this are accessible without the user being authorized)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant