-
Notifications
You must be signed in to change notification settings - Fork 695
setupAutomaticSilentRefresh() works but is called too frequently #432
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I have only little knowledge of pre 3.x versions, nor the inner workings of how silent refreshes are set up, but based on your code: shouldn't you configure the |
Is it possible, that your Id_Token is the reason? You can find it in your session storage and by coping it into the form on jwt.io you can see its expiration date. |
Hi, @jeroenheijmans That's a good point/catch. The default setting is .75 (75%) according to the documentation though so it shouldn't be refreshing for 6 hours. @manfredsteyer I did just that before creating this issue. jwt.io is very handy. I confirmed that the token expiry matches what it should be as per the Identity Server configuration. It's represented in ticks so I had to use https://www.epochconverter.com/ |
Actually I just noticed here that there are two expiry settings in Session Storage. "expires_at" is correctly set to 10 hours as per the Identity Server configuration "id_token_expires_at" is 3 minutes or so. Could it be that the Silent Refresh functionality is using the "id_token_expires_at" to set up the frequency of refreshing? |
I looked at the code for doing the silent refresh and it seems to take the lesser expiry time which makes sense. It would be good if the setupAutomaticSilentRefresh() method could accept a parameter which indicates which expiry time to use. My understanding is that the Id Token is only used to authenticate and will be short lived whereas the access token will live longer and is used to consume APIs. |
@manfredsteyer Is there any chance we can get this out in an official npm release? It looks like it's merged in #462 |
Hello @manfredsteyer do you any timeframe for a new release with this feature please? We do have the same problem in our development and we are stuck... |
@martin1cerny Although the option is added to filter token_expires based on the listenTo parameter, the code that sets up the timers setupExpirationTimers() still continues to use the shorter expiring time which will be id_token. I dont think the issue is still fixed. |
There's been a few new releases July 2019, so I'm assuming everything's available now. Let us know if the issue remains with new versions and we can reopen! |
@jeroenheijmans the issue still remains the way @davdev82 described. If the id token has a shorter lifespan than the access token and you configure setupAutomaticSilentRefresh to only listen to access token expiration, the access token will never be refreshed. I created a pull request that always fires the token_expires event for both token. setupAutomaticSilentRefresh() then filters the token_expires event for the correct token type. |
Okay cool, thx for the update and the PR, will reopen this issue then! |
We are experiencing the same issue where we want to refresh only on |
I have an id_token with a shorter lifespan and can only refresh access_tokens. I experience these same issues and can confirm I tried hooking into token_expires events but this has the same behaviour where it will endlessly emit events because the id_token is expired. @jeroenheijmans anything we can do to get a fix out? Or can you think of a workaround for now? |
No ideas come immediately to mind, other than forking until a fresh version is rolled out. The maintainer typically only puts out a new release with a new major Angular version, I currently only do some community chores... |
Hi,
We're using version 2.1.3 and are using silent refresh. It is configured like this:
Our token currently has a lifetime of 10 hours. I know, far far too long and we'll be reducing it to a more reasonable and secure timeframe but that's what it is for now.
I have checked the expires_at field in session storage and the ticks it is writing converts to 10 hours relative.
My question is about the automatic silent refresh. It's happening every 4-5 minutes which is far too frequent given the configuration outlined above. Any ideas why this might be?
The text was updated successfully, but these errors were encountered: