Allow refresh: true in getAccessToken()#2055
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2055 +/- ##
==========================================
+ Coverage 80.02% 82.53% +2.51%
==========================================
Files 21 21
Lines 1907 1941 +34
Branches 315 342 +27
==========================================
+ Hits 1526 1602 +76
+ Misses 376 333 -43
- Partials 5 6 +1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Thanks for prioritising this @tusharpandey13. I have it as a blocker for upgrading at the moment which blocks our NextJS 15 upgrade. Just wondering if you have a rough idea of when this might get completed and released? |
|
We'll release this soon, ETA might be tomorrow EOD |
|
Any more updates on when we can expect to see this go in? Right now it's a blocker on NextJS 15 upgrade which due to atrocious dev server performance in NextJS 14 is impacting our team's productivity heavily. Frustrating to see what feels ike a very simple change being dragged out. |
these changes have been added
There was a problem hiding this comment.
Pull Request Overview
This PR introduces a new option (refresh) to force a token refresh in getAccessToken(), addressing issue #1884. Key changes include updating method overloads in the Auth0Client, adding a new forceRefresh parameter to the AuthClient’s getTokenSet method, and updating integration tests and documentation to cover this new behavior.
Reviewed Changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| src/server/client.ts | Updated getAccessToken overloads to accept refresh option. |
| src/server/client.test.ts | Added integration tests for forcing token refresh. |
| src/server/auth-client.ts | Updated getTokenSet to support forced refresh logic. |
| EXAMPLES.md | Added documentation examples for forcing token refresh. |
Comments suppressed due to low confidence (1)
src/server/client.ts:349
- [nitpick] The parameter names 'arg1', 'arg2', and 'arg3' are ambiguous. Consider renaming them to more descriptive names (e.g., 'reqOrOptions', 'res', 'options') to improve code clarity.
arg1?: PagesRouterRequest | NextRequest | GetAccessTokenOptions,
| @@ -0,0 +1,472 @@ | |||
| /** | |||
| * @fileoverview | |||
There was a problem hiding this comment.
I think the seperate file is a good idea, but I would propose to:
- move the file to
client/get-access-token.test.ts - Also, as above, drop the
integrationin the file name.
There was a problem hiding this comment.
- renamed
getAcessToken()is present inclient.tspresent inserverdirectory. Makes sense to keep the test inserver.
| const fetchCalls = mockFetch.mock.calls; | ||
| expect(fetchCalls.length).toBeGreaterThan(0); | ||
| const tokenEndpointCall = fetchCalls.find((call: any) => { | ||
| let urlString: string; | ||
| if (call[0] instanceof URL) { | ||
| urlString = call[0].toString(); | ||
| } else if (call[0] instanceof Request) { | ||
| urlString = call[0].url; | ||
| } else { | ||
| urlString = call[0]; | ||
| } | ||
| return urlString.endsWith("/oauth/token"); | ||
| }); |
There was a problem hiding this comment.
We do not need to assert this, we know this is the case by asserting the returned values. If we want to assert this, I would propose to do it differently, as this doesnt look like what we want.
Fixes : #1884
Changes
refresh?: booleanoption togetAccessToken()Testing
PASSING
Usage
App Router (Server Components, Route Handlers, Server Actions):
When calling
getAccessTokenwithout request and response objects, you can pass an options object as the first argument. Set therefreshproperty totrueto force a token refresh.Pages Router (getServerSideProps, API Routes):
When calling
getAccessTokenwith request and response objects (fromgetServerSidePropscontext or an API route), the options object is passed as the third argument.