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
Related
I have kind a puzzle-headed task and i don't know where should i start.
We have a web app that is in our local net. We want to give access to this
app from the outside using apache.
Basically we want pre-login page on apache that will send user credential using api to our app and receive answer with OTP, which user can write in pre-login page inputbox, send again and in case off success apache will redirect user to standard apps login page.
Can apache do that?
Sort of: you can put an authenticating proxy in front of your app that will propagate the established user identity to the backend. See e.g.: https://github.com/zmartzone/mod_auth_openidc
I'm currently trying to implement silent refresh follow this workaround
However, even when I'm logged in, if I try to do an AJAX GET request to the oauth2/authorize endpoint, I get a status of 200. I tried going to the URL in the browser directly, and it worked. Do I need to pass additional information?
Any help would be greatly appreciated, thanks!
I ended up solving my own problem and was able to not have to use an iframe.
Solution to original problem (I was using authorization code flow):
Set up an endpoint on your server with a silent response that FusionAuth can redirect to (endpoint 1).
Set up an endpoint that you will call from your app to perform the silent refresh (endpoint 2).
From the app, send AJAX GET request to endpoint 2.
On the server side of endpoint 2, send AJAX GET request to FusionAuth with redirect_uri=(endpoint 2)
On success, get redirected url. (In express.js with axios I did response.request.res.responseUrl)
If the url is current server host and not the fusionauth service host, complete auth code flow. Return the token and tell the browser that the user is logged in.
In all other cases the user is not logged in, so return to app that user is not logged in.
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.
I have been trying to resolve this for some time now. I tried googling for this problem but didn't manage to find anything. All the questions I found were about replaying already recorded HTTPS requests.
So, I need to record HTTPS requests on a site protected with simple authentication (the pop-up window asking for username and password).
And this is where I get stuck. I enter correct login details and confirm it, nothing happens and in a second i get prompted to enter login details again, no error message nothing. When I press ESC I get 401 UNAUTHORIZED error.
Basically the site is acting as if the login details were incorrect when in fact I tried the same login details without Jmeter's proxy and the server accepted it.
What I tried:
1) Logging into this site without JMeter's proxy - works without problem
2) Recording different HTTPS site with JMeter's proxy - I tried my email and that works correctly as well
I should also mention that I am behind a company proxy, but I tried it at home and the result was same.
As for JMeter configuration, I am using everything on default having:
Thread Group
HTTP Cache Manager
HTTP Cookie Manager
HTTP Request Defaults
Recording Controller
HTTP(S) Test Script Recorder
Guessing the Thread Group doesn't really matter since I don't run any tests, only recording.
Additional Details:
Server:IIS
Logging into sharepoint website
EDIT:
Forgot to mention I tried already Blazemeter Extension, but when i try to record the logging session, it just freezes. Website hangs on trying to contact Blazemeter Cloud and Blazemeter plugin freezes, making it imposssible to stop recording and having to restart whole browser.
Also just noticed that when I am already logged in and try to access the site it records it without any issue. So it's only the login which is problematic for some reason.
JMeter removes cookies and authorization headers while recording.
You can use JMeter Chrome Extension as an alternate way of recording your test scenario.
In order to properly replay the recorded script you'll need to add HTTP Authorization Manager to it .
Sharepoint can have different authentication types, i.e.
Basic HTTP Authentication
Windows Integrated Authentication (NTLM)
Kerberos
See Windows Authentication with Apache JMeter guide to learn how to bypass each authentication challenge in your JMeter test.
So I was able to finally resolve this. The issue lied in sharepoint authentication. I was logged in a domain with my personal account, but was trying to access the sharepoint using a different account.
Sharepoint ignored the login details I was prompted to enter and used mw domain credentials instead. So the answer for me was to access the sharepoint website while being logged into domain(windows) with the same account.