-
|
Forgive me for my ignorance here as I am still trying to learn how this library works. We are using your library in an application with a React front end and Rails api backend using doorkeeper with the token expiration set to 1 hour. We have a situation where sometimes the background token refresh fails to happen and so the stored token has become stale and so api requests to our backend fail. The token would refresh if requested but unfortunately it won't happen in the background automatically for up to an hour. Is there a simple way to catch the api error and manually make a call to refresh the token using your library. I am seeing that the I am going to keep exploring on my own and will close this issue myself if I figure it out but I thought I would post it in case the maintainers of the library can save me some time and point me in the right direction. Thanks! |
Beta Was this translation helpful? Give feedback.
Replies: 6 comments 13 replies
-
|
What we often do as a "hack" when testing new functionality, is to just set the token expiration to So you could write a simple function like: function triggerTokenRefresh() {
window.localStorage.setItem("ROCP_tokenExpire", 0)
}Note that this won't make it trigger immediately, but at some time within the next 15 seconds. Otherwise, as most other libraries, the main functionality is built to "depend" on other components working as intended, so I don't see us exposing the refresh-function any time soon. |
Beta Was this translation helpful? Give feedback.
-
|
@sebastianvitterso thanks so much for responding to my question so quickly and converting this to a discussion. My sense is that our scenario must be pretty common and so I am guessing we must be not configuring our application in a proper way and I am wondering if someone could point us in the right direction. To explain again we are doing a get request on the root page of our React app. You need to be authenticated in order to access that page and so far we just check that there is a token in localStorage needed for the request. If someone has closed their tabs and then returns after the expiry time for the token then we get a 401. The token then refreshes and repairs itself in the next 15 seconds or so like you suggest but it creates a bad initial experience for the user. I am curious how you or others would suggest handling this scenario more gracefully. Should we be checking ourselves whether the token is expired before making the api request? Is there some kind of configuration that we are missing? I still feel like it would be helpful if we could "manually" refresh the token if we get a 401 response and not have to wait the interval for the refresh to happen in the background. We would be happy to contribute to a PR if that seems like it would be a valid, reasonable feature that the library wants to support. Let me know if any of this is unclear. Thanks again for the help! |
Beta Was this translation helpful? Give feedback.
-
|
Also, I am really curious about how I can publish the |
Beta Was this translation helpful? Give feedback.
-
|
What do you mean by "publish the Good luck! |
Beta Was this translation helpful? Give feedback.
-
|
Heya @jonsgreen - did you ever figure out an alternative? |
Beta Was this translation helpful? Give feedback.
-
|
You should verify that the token_expire, and refresh_token_expire values are returned from the auth server, and are set in localStorage. |
Beta Was this translation helpful? Give feedback.
-
|
To piggyback off of this: how about the situation where the access token is valid for 24 hours, and the refresh token is valid for 30 days. Say you log in at at Monday, 10:00. You leave the page, and you don't back, until Tuesday 11:00. You open a new tab, and the access token has expired. The first API call that happens, a simple Wouldn't it make sense to call the Or, another case: if someone has revoked existing sessions/authorizations, by changing their password, so the API calls would return 401. Their refresh token would have been revoked too, but that's absolutely fine, as the Am I missing something, or would these be legitimate use cases that are not covered right now? |
Beta Was this translation helpful? Give feedback.
-
|
Interesting. Would you mind creating a new issue for this? |
Beta Was this translation helpful? Give feedback.
-
Done. #227 |
Beta Was this translation helpful? Give feedback.
-
We need a manual refresh token mechanism because when a 401 error occurs, the access token gets invalidated without the client being aware. As a result, the client UI loses its session state if we explicitly call logIn(), leading to a poor user experience—especially when a user is in the middle of an action and is suddenly prompted to log in again. Having an on-demand refresh token allows us to seamlessly recover the session and avoid unexpected logouts, ensuring a smoother and more reliable user experience. Would it be possible, we can raise the PR.. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with what @bhattadp explained about how the library currently handles token refresh automatically and why a manual refreshAccessToken() API isn’t exposed today — that approach makes sense from a standard OAuth2/PKCE design perspective. That said, I wanted to add some context from embedded and long-running application scenarios. In these environments, there are cases where an access token can become invalid unexpectedly — for example, when certificates are renewed, during long idle periods, browser tab suspension, or when storage is cleared. When this happens, forcing a full re-login can negatively impact the user experience, especially when users are actively working in the application. From a UX standpoint, having the ability to manually trigger a token refresh instead of redirecting to login would allow the application to recover more gracefully and keep users in flow. Thanks @bhattadp for the explanation and context — really appreciate it. |
Beta Was this translation helpful? Give feedback.
-
|
@bhattadp That being said, I think token revocation is a very exotic edge case, since most of the time when a token is revoked, the refresh token will be revoked as well. Leaving "logIn()" as the only option. And in regards to losing UI state on a full login, that you can solve by calling But I see some cases where having the option to call "refreshAccessToken" manually can be useful. Will get it added 🙂 |
Beta Was this translation helpful? Give feedback.
-
|
@jonsgreen A quick example: const { token, refreshAccessToken } = useAuthContext()
return (
<>
<button onClick={() => refreshAccessToken()
.catch((err) => alert(`Failed to refresh access token: ${err.message}`)
)}>
Refresh access token
</button>
</>
) |
Beta Was this translation helpful? Give feedback.
@jonsgreen
The option to manually refresh access tokens has now been added in version 1.24.0.
We also modified the check for expired tokens, so when the javascript thread "wake-from-sleep" it will catch and refresh the token almost immediately (as opposed to "within 15sec").
A quick example: