What's wrong with my setup?
I am using django-allauth for social signup and recently i added contacts to it's scope. Things are working fine. It now asks for permission to manage contacts and I am able to get contact details of users through the API.
But once i make a request to get contacts of a user(I am not saving any refresh token or accss token at that time), after an hour when i make the request again with same token, It shows this error "Invalid token: Stateless token expired".
However I can still login into the website and the token does not change. However when I logout and login again the token changes and i can again get the contacts using that token for one hour.
What's the issue? What am I missing?
See, when you are logging into the website, you are probably using cookies. So basically you might be using the same session and actually the api is not called.
The time when you are logging in incognito mode or in a diffrent browser, that cookie cannot be used, so this time api is called. For this reason, the token is getting changed.
For example, if after few users have signed up with google, you change the scope of the app, what happens is, if the user has enabled cookies and it has not expired, when he visits your site, it simply logs him in. It does not asks for permissions (that you added recently to scope). But when he logs out and logs in again, then it asks for the additional permission and th token also gets changed.
What you should do is, you should go through th codes of django-allauth and clear it out how they are using the token. You must also know that for getting refresh token, you must have offline access enabled in your configuration.
Related
I'm working on a SPA where adal-angular lib is used to handle auth on client side. On backend app, passport-azure-ad is used with Bearer Strategy, to issue access token and other stuff(no refresh token though).
When user authenticates, accessToken, together with idToken is saved in localStorage, and with token timeout (which is around 1h).
When token expires, I get error (AADSTS50058) back saying single sign-in failed as it is missing cookie, to confirm identity. I'm not sure who needs to issue this cookie, and why it is not issued.
So I have one choice to manually, after reaching that error, call signIn method, programatically. It works to login, but full page reload happens and user loses work.
So my questions are:
Can this be fixed with missing cookie, who needs to issue the cookie, and will it also do full page reload or not?
If I cannot solve this with missing cookie, is there another way to re-login without doing full page reload?
Thanks.
This error may occur if the third-party cookies have been disabled in your browser.
If you are accessing angular application through Chrome browser on incognito mode. it disables third-party cookies at the home page.
If you are using incognito mode. Re-enable third party cookies in your browser to prevent this error from occurring.
For AADSTS50058 error you need to whitelist the
login.microsoftonline.com endpoint in your browser extension in order
to evade receiving this error again
For using access token, I would suggest to use refresh token, access token has a short life span as it becomes invalid or expires you need to re-login.
So make use of refresh token as it has long life span
However, there are two alternatives,
Set the shorter expiry date 60 minutes to Access Token.
Set the long expiry date 100 days to Refresh Token.
“Access token good for an hour, refresh token good for a year or good-till-revoked” So, you better use both Access Token and Refresh Token to fix this issue
To know more in detail please find these links if they are helpful:
Ref1 , Ref2 , Ref3
I have my site deployed in CCV2 SAP CX2011 version. Almost all of my requests redirects to login page, sometimes it autologins & redirects to actual url which I was accessing but sometimes I have to specifically login.
What I see in network tab is that the call "current?lang=en&curr=EUR" is getting cancelled but later automatically the same call goes through with same bearer token
SAP Spartacus is 100% API driven and its user session management is done with help of refresh token and access token issued by Commerce backend.
When users login Spartacus for the first time, a new refresh token together with the access token is send back to Spartacus. The access token is stored in browser local storage and refresh token is stored in memory for security reasons.
Both token can be expired, whose expiration time is maintained in Hybris Administration Console with properties oauth2.refreshTokenValiditySeconds(default: 30 days) and oauth2.accessTokenValiditySeconds(default:12 hours).
Please check this url for details.
When Spartacus sends OCC request to Commerce server, the access token is appended to http request via interceptor. If access token actually expires, Commerce will send error response like Access Token expires, then Spartacus will request a new access token with refresh token, and re-try the failed request automatically once a new access token is got. All such activities are happening under the hood, completely transparent to end user. There will be no user error message displayed in Spartacus UI.
On the other hand, if refresh token itself expires, user will be redirected to the login page, and has to maintain user name and password once again. Once logged in, Commerce issues a new refresh token and the scenario can continue.
So please kindly check the token expiration time configuraed in your Hybris Administration console if they are correctly maintained, or check fix mentioned by Caine.
Best Regards,
Jerry
I wanna to understand how I can retrieve the online status of a Facebook user. For example, I'm logged in my application through JWT auth, and then in my settings page, I wanna to see my facebook online status.
Do I need to log in through OAuth, or just I can put on the field my facebook userID and then make a request to facebook API?
Also if it's possible to have socket connection with that online status to know in real time my status?
Maybe do you know cases with node.js and socket.io with it?
Thx
There is no way to get a user’s “online status”.
Do I need to log in through OAuth, or just I can put on the field my facebook userID and then make a request to facebook API?
Even if you did make an API request with a valid user token, that says little about the user’s online status.
The token stays valid for two hours (for a short-lived one), but the user isn’t necessarily online “on Facebook” for the whole time. Only if they logged out of your app explicitly, thereby invalidating the token, you could take the error message you would then get on the next attempt to make an API request using that expired token as an indicator. But then they would also have to login to your app again, before you could recognize them as “online” again.
From a custom authenticator; is there a way of telling ember-simple-auth that a user is now invalidated/logged-out?
Some background: I am building an authenticator with token refresh, similar to oauth2-password-grant. While I haven't experimented with the oauth2 authenticator directly, it seems we face the same issue: if the token refresh fails to update, for example due to an expired token, the user remains logged in as far as ember-simple-auth is concerned.
EDIT: (to address comments for further clarification)
Ah, I use JWTs and the server does not maintain sessions; the server has no idea who is logged in nor does it matter. The authentication is done via username/password after which the server issues a JWT token along with a time when it expires. To prolong the expiry time, you may refresh this token (as long as its valid) and get a new token with an updated expiry time. All is well and good except that ember-simple-auth does keep track of whether the user is logged in, as it should. However, if a call to refresh the token fails the user should be considered logged out (the token is invalid/expired and any attempts to make a call to an API that requires authentication will fail).
My question is how do I tell ember-simple-auth that this user has been logged out.
This is the comment that led me to ask this question.
I've got a server side Node.js app, using googleapis package. Users log in with their Google accounts, and I store tokens in their session. The credentials I get are as follows
{ access_token: '<AN ACCESS TOKEN>',
token_type: 'Bearer',
id_token: '<A LONG ID TOKEN>',
expiry_date: <A TIMESTAMP> } // why do some places say there's an expires_in instead of this
There's no refresh_token because the users have already logged in for the first time and clicked accept, and I didn't store the refresh token (looks like I should've).
So, when the expiry_date is reached, if the user tries to make a request for us to save something to their google drive, I get an error message:
{ [Error: invalid_request] code: 400 } // ...no further details
My 2-part question:
I assume I'm getting that error message because the access_token in my OAuth client object is expired (because the call works fine before the token expires). Is this correct? Why is the error message not more detailed?
In the linked answer at the top, the solution is to force the accept prompt again, get the refresh token, and store it permanently, and use it to get a new access token when it expires. Why is this a better option than just checking if the token is expired, and having a user reauthenticate when we want to make a call to the API? Which is the "correct" way to ensure that my logged in users can always make the drive API call to save their documents?
Right, the 400 response is because of the expired access token. I'm not sure why Google doesn't give more detail, but it's common for services to use the 400 status code to indicate some kind of credentials problem. The definition of the status code indicates that it's a client issue.
Both approaches will work and they each have advantages and disadvantages. The client-side re-authentication method you're suggesting has the advantage of making the implementation simpler, since you don't have to store the refresh token and don't have to implement the refresh process. The downside is that forcing the user to re-authenticate every hour is less user-friendly. At the least they will be redirected away from your app, and they may have to explicitly log in or re-authorize as well. You'll just have to look at the trade-offs and pick what works best for your use case.