Our use case suggests logging out the customer support agent's session after 10 minutes, consequently routing to the /login page.
Say, the user stays idle in the homepage for 10 minutes, his session should logged out automatically and redirect to the /login page. Current scenario is, session is indeed logged out but the /login redirect is not happening.
This is different with the OOTB, wherein logout is explicitly triggered onClick of a button. And will execute if isCustomerEmulationToken(token) is true.
I'm trying my way using the isCustomerEmulationSessionInProgress() method in AsmComponentService but is unsuccessful since isCustomerEmulationToken(token) at this point is already false.
Is there a proper way to handle this in Spartacus?
Related
We have developped a SPA SaaS and went to a soft production launch recently.
Everything was fine until one of our customers told us they had trouble using the app.
Once they open the app, the first request to our backend triggers their proxy credential prompt. Hopefully on the login request.
They have to enter their proxy credentials to let the request go. All subsequent requests are passing properly and they can use the app.
The problem is:
When they stop using the app, close the browser and then come back the day after, the persistent login tries to connect them to our backend, but the proxy credentials prompt is not triggered and the request fails. All subsquent requests fail also.
For it work again, they have to delete all app data in chrome (so the service worker is unregistered, the localstorage and cache are cleared). The next api call will trigger their proxy credentials prompt and they will be able to work again.
So is there any way for the app to know if the proxy is set or not ? Any way of triggering the proxy prompt if not set or whatever ?
I don't exactly know how those proxies work and we have zero access to the proxy settings.
It surely is something with the credentials expiration after some time but that's all we can figure out right now. Maybe we could monitor some params in the request headers ?
We are using VueJS with axios for the requests.
My guess is when user session credentials get expired, your UI is not handling redirection to login page. When the user login for the first time you should store that the user has logged in successfully in browser localstorage. If your server returns 401 error code, you can delete the flag and redirect the user to login page. You can achieve that using meta fields in router.
Check out this link on how to use meta fields https://router.vuejs.org/guide/advanced/meta.html
Simple problem, I want to login and out of an app with various users to check different app functionality. App is using Auth0 for user management.
I am calling the /v2/logout url as a part of my flow.
But somehow, after logging out, when I login again the seamless SSO behavior runs and I'm immediately logged in again with no prompts -- it's as if the logout URL was never called.
Only way to get a login prompt again, is to clear my browser cache. Is there an auth0 cookie somewhere I need to delete as well? Or am I missing something? I'm reading the seamless SSO docs but don't see anything beyond calling /v2/logout.
Calling the Auth0 /v2/logout API endpoint will log the user out of Auth0 and optionally the IdP (if you specify federated parameter). It will not log out the user from your Application so you will need to implement that in your application.
Here in the Javascript SPA example, in the setSession() we are storing the Access token(along with its expiry) and the ID token in localStorage. In the logout() function we are then removing these entries. This is logging out from the Application user session. You can optionally redirect to /v2/logout to clear the Auth0 and IdP session as well in this function. That way, when you are checking if user is authenticated, the isAuthenticated() returns false and we force the user log in again.
So turns out, the issue is around redirecting the user as opposed to calling the logout url directly. I was using a separate ajax api call to the logout url. However when I use window.location.replace(logoutUrl), the logout actually happens.
From the auth0 docs:
To force a logout, redirect the user to the following URL:
https://YOUR_AUTH0_DOMAIN/v2/logout
Redirecting the user to this URL clears all single sign-on cookies set by Auth0 for the user.
So a separate call doesn't work -- have to redirect. Which I suppose makes sense -- a separate ajax call doesn't have the user session context.
We are currently implementing keycloak and we are facing an issue that we are not sure what’s the best way to solve it.
We have different webapps making use of the sso and that’s working fine. The problem we have is when we make log in using the sso in one webapp and then we do the same in a different webapp.
Initially this second webapp does not know which user is coming (and it’s not necessary to be logged in to make use of it). When clicking on “login”, it automatically logs in the user (by making a redirection to keycloak and automatically logging the already logged user in the other webapp). This second logging happens “transparently” to the user, since the redirection to keycloak is very fast and it’s not noticeable. This behaviour is not very user friendly.
The question is: Taking into account that this second webapp can’t know upfront which user is accessing the site (unless actively redirecting to keycloak), is it possible to force always the users to log in for a specific keycloak client? By this I mean actually ask the visitor for user/pw even if keycloak knows already them from other keycloak clients.
Thanks in advance!
In the mail listing from keycloak, they gave me a good solution but for version 4:
in admin console, go to Authentication
make a copy of Browser flow
in this new flow, disable or delete Cookie
go to Clients -> (your client) -> Authentication Flow Overrides, change Browser Flow to your new flow, click Save."
Use logout endpoint as a default login button action in your app and redirect uri param use for login page, where you use your specific client (of course you need proper URI encoding):
https://auth-server/auth/realms/{realm-name}/protocol/openid-connect/logout?redirect_uri=https://auth-server/auth/realms/{realm-name}/protocol/openid-connect/auth?client_id=client_id&redirect_uri=.....&other_params....
=> user will be logged out and then it will be redirected to the login page
I have a React app rendering client-side, in which I handle authentication the following way:
Upon loading, the app fires an AJAX request to the backend, basically asking whether the user's session is valid ;
It updates the app's state with the server's response ;
It renders the "/" route accordingly (the homepage if the session is invalid, a dashboard if it is valid).
(Maybe there are better solutions for handling this in front-end applications, I'm all ears if you have ideas)
This works pretty well, but introducing Service Workers into the mix and trying to turn the app into an offline-first progressive web app seems... complicated.
On the one hand, if I don't cache the "Am I logged in ?" request and the app is offline, the app will always render the homepage.
On the other hand, if I do cache the AJAX request, the users will eventually be shown an empty dashboard because their sessions will have expired and the server will be throwing 403s.
Is there a way to handle this effectively?
I solved my problem by taking a different approach: I now persist the state in localStorage.
This way, when the user arrives on the app, he is presented with stale data from his last visit. Meanwhile, a "Am I logged in?" request is fired in the background.
If it is succesful and returns true, the other AJAX requests get fired and fill the app with fresh data ;
If it is successful and returns false, the state is updated accordingly and the user redirected to the homepage ;
If the request is unsuccessful (i.e. the app is offline) the app keeps showing stale data from last session in the dashboard. We don't know if the user's session is still valid, but we can't retreive any data so it does not matter.
One way of doing it is adding a /verifyToken (assuming you are using some kind of token to validate the session) in your back-end api to check if the token is valid.
So you cache your session token. If the app is offline it shows the dashboard.
If the app is online, you fire a request to /verifyToken to check is the session is still valid. If it is then you continue to dashboard. If it isn't you redirect them back to homepage (or the sign in page).
Edit:
When your app is online, you can technically fire a request to any authorized route and check if the response was 403 (in case you can't modify the backend). If it is then you can send them back to sign in page.
Is there a way to implement multi factor authentication in Shiro? Can somebody give me a hint on how to implement this?
For more details:
The basic idea is, that a user needs to login just as usual, using username and password, but before being actually authenticated the user also needs to enter a one-time-token he received as an SMS.
Thank you!
I finally solved my problem on my own, but I'm of course always open to other suggestions.
I implemented my own 2 - Factor Authentication Flow:
First of all I changed the URL of the login page, to which Shiro redirects an unauthenticated user to my own login page, that leads into the authentication mechanism.
A user needs to complete two "stages" to login.
On the first stage he/she has to provide a username and password, if
these are valid, the user is redirected to the second stage of login.
Meanwhile, a one time token has been generated and sent to the user
via SMS. Also the user's authentication progress has been saved in
the session (which means I remember, that stage 1 was completed
successfully).
On stage 2 the user needs to enter the token. If the
token was
not valid or the number of attempts (5) was exceeded
expired (after 5 minutes) the number of attempts
to correctly enter the token exceeded 4 the user will be redirected
to Stage 1 and all progress will be deleted. I
if everything went fine, the user will be authenticated to Shiro
(of course without letting him/her know)
In the end the user will be redirected to the page he/she originally requested, which still allows him/her to bookmark pages. Of course Shiro's remember-me will always be deactivated.