Lets say I have a method called getUsers and an API Interceptor which handles my token refresh functionality.
Here is the scenario:
I send a GET request using getUsers to:
http://example.com/api/users
My token is expired so I get a 401 error
API Interceptor refreshes my token and calls the endpoint again:
response.config.headers.Authorization = "Bearer " + response.access_token;
$http(response.config);
It works fine, but how do I actually re-use my original method (getUsers) instead of just resending $http request because I need to modify some data on callback
What really worked in my case is actually intercepting requests, not responses. So basically I have a timestamp of my token creation in my local storage which I compare to current time every time I send an API request. If it's been longer than say 10 hours (insert your lifespan) I request a new token.
Related
I have a React application and I'm using Axios to make http calls. Calls are authorized with an authorization header.
In Axios I'm using the response interceptor and in case I get a 401 from one of the calls I make another call to get a new token using a refresh token obtained upon login and stored in the browser, and then retry the original call using the new token. It works well.
The issue starts with the way it's handled in my application. I have pages where there are multiple components that request data from the server, at the same time. The page returns a 401 causing my logic to ask for a refresh token - so basically all requests are also asking for a new token using that refresh token. The issue is that the first request asking the new token is served while the others are failing - this is because when asking a new token using the refresh token a new refresh token it granted. Meanwhile the other calls for a new token all use an "old" refresh token that cannot be validated on the server side because it had been replaced on the first call - making the request fail.
Also in the above logic - the login is called more then it should - it should be called only once when the first call detects that it should.
What I'm looking for is a way that if the first call fails due to the need to refresh the token, how do I make the other calls understand that a call for a new token is already made and hang until it's returned (or retry with the newly stored token once it's available)?
I have this request that is querying my service which is inside of tryMax.
The access token to authenticate a request expires every five minutes and is generated at the beginning of the simulation run as ${token}
Is there a way within the tryMax to send another token generation request that will update the expired ${token} (Authorization header value) if the response code is 401 or the response body contains information about the request not being authenticated. Then retry the request before tryMax moves to the next iteration?
I have tried setting status code as a session attribute, however the request is not being sent and the token doesn't update, I tried doing a .doIf after the request exec, putting a doIf inside it's own exec and even playing around with transformResponse, all with no success.
Any suggestions how to approach this?
you can do something like what is outlined in
Gatling (performance test):how to perform task in background every x-minutes
However - is this really the scenario you want to model? How does the client you are simulating handle the 401? The scenario you are proposing only works if the client is in charge of manually handling its own refreshes.
We have a client which communicates with a server secured by OAuth2.
As implementing tokens flow we have faced a problem. When page loads, there are few components that make calls to different secured endpoints.
There is a situation when access token is expired so all requests get error and try to refresh it. So we have few asynchronous requests.
Is there an approach to deal with such situation?
Our client is written on React JS.
There are a number of solutions to this.
One solution would be to create something like a TokenService.
Before you fire any http call, you work with this service and check if you have a valid token. This is easy since when you create the token you get back information on how long the token is valid for. You store that somewhere and before you fire a call you check if you are still in the validity window. If you are then you fire the http call, if you are not then you request another and update the stored one with the new one. Once this is done then you fire your http call with the valid token.
If you don't want to manage this complexity then you could simply request a new token for every request and you're done. You use each token for one call and that's it really.
You could also use the refresh tokens functionality if you have that implemented, so if your token expires, you simply refresh it and move on
I have a requirement in AngularJS.
My user token expiry is set to one hour.
Whenever I submit a form , if the token is expired,
is there any way to hold the form value till I receive token from another API and the token is updated.
You can use the Auth Interceptor Module. If your API call receives a 401 status code, it will move your API call to a buffer, does the call to receive a new token and when the new token is received your initial API call will be executed with the new token.
I have an app that has OAuth2 implemented. It works fine, but I'm confused with refresh_tokens here. My app is using React + Redux combination.
I know I need to check if my access_token expired and then ask for new one using refresh_token. Okay... But when should I refresh it? After the 401 happened or in time when some API request that needs authorization is ready (just before send)?
I also know how to use HTTP interceptors to get all API requests before send or detect the 401 responses.
The problem is I'm confused how to solve the problem in Redux flow. How to "freeze" a request for the time the token is being refreshed? Or how to repeat the request when I solve the problem on 401 response?
When first authenticating with server successfully, we will have {access_token, expires_in, refresh_token}. We will store access_token and expires_in in session storage and refresh_token in local storage.
Whenever getting access_token for fetching data (you should enhance/wrap the fetch with filling access_token), you'll check if the expires_in is due soon (less than 1 minute, or what you feel comfortable), then we use the refresh_token to request new access_token. And of course, we have to update new result to the storage as well.
Pseudo code:
function getToken() {
const expiresIn = storage.getItem(KEY_EXPIRES_IN);
const accessToken = storage.getItem(KEY_ACCESS_TOKEN);
if (accessToken
&& (!expiresIn || moment.unix(Number(expiresIn)).diff(moment(), 'minute') > 1)) {
return accessToken;
}
return refreshToken();
}
Above function will be called every time you make a request to server.
P/S: you may want to make it as promise to use with isomorphic-fetch