You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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)
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.
The text was updated successfully, but these errors were encountered: