-
Notifications
You must be signed in to change notification settings - Fork 3
feat(oidc-client): implement tokens.get #369
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
Conversation
View your CI Pipeline Execution ↗ for commit 7cb0519
☁️ Nx Cloud last updated this comment at |
Deployed b3e84fb to https://ForgeRock.github.io/ping-javascript-sdk/pr-369/b3e84fb754a3b2acfaf5365c187464c1d6663b05 branch gh-pages in ForgeRock/ping-javascript-sdk |
📦 Bundle Size Analysis📦 Bundle Size Analysis🚨 Significant Changes🔺 @forgerock/oidc-client - 21.1 KB (+3.1 KB, +17.4%) 📊 Minor Changes📈 @forgerock/sdk-types - 5.9 KB (+0.0 KB) ➖ No Changes➖ @forgerock/protect - 152.3 KB 11 packages analyzed • Baseline from latest Legend🆕 New package ℹ️ How bundle sizes are calculated
🔄 Updated automatically on each push to this PR |
🦋 Changeset detectedLatest commit: 7cb0519 The changes in this PR will be included in the next version bump. This PR includes changesets to release 9 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
store, | ||
options: storageOptions, | ||
}).pipe( | ||
Micro.flatMap((tokens) => |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
may be slightly more readable if we don't nest this pipe inside of the outter pipe, and just keep them on one level.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Addressed
endpoint: wellknown.token_endpoint, | ||
store, | ||
options: storageOptions, | ||
}).pipe( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
similar comment here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I addressed this as it was the same as the other comment.
store, | ||
options, | ||
}: BuildTokenExchangeµParams) { | ||
return Micro.sync(() => createValuesµ(code, config, state, endpoint, options)).pipe( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unneccessary Micro.sync
I think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually made a mistake in naming createValuesµ
as it didn't return a Micro
, but I fixed that and removed the Micro
here.
Micro.flatMap((options) => validateValuesµ(options)), | ||
Micro.flatMap((requestOptions) => | ||
Micro.promise( | ||
async () => await store.dispatch(oidcApi.endpoints.exchange.initiate(requestOptions)), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unneeccessary await
and async
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Non blocking comments that are mostly semantic. Looks good
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #369 +/- ##
=======================================
Coverage 57.58% 57.58%
=======================================
Files 32 32
Lines 2044 2044
Branches 320 320
=======================================
Hits 1177 1177
Misses 867 867
🚀 New features to boost your workflow:
|
), | ||
Micro.flatMap((requestOptions) => | ||
Micro.promise( | ||
async () => await store.dispatch(oidcApi.endpoints.exchange.initiate(requestOptions)), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This oidcApi endpoint returns a TokenExchangeResponse type but the type returned by buildTokenExchangeµ is OauthTokens which has properties that don't exist in TokenExchangeResponse. Did you means to remove TokenExchangeResponse and replace it with OauthTokens?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch. Let me work on this.
log, | ||
authorizeOptions, | ||
).pipe( | ||
Micro.flatMap((response): Micro.Micro<OauthTokens, TokenExchangeErrorResponse, never> => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need the types here, I assume there was a reason we added them explicitly here instead of the inferred type
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a good question, and I'll try my best to articulate it in as comment, but it may require a chat.
I like using inferred types as I've been developing, but as I was "tightening up" the code, and ensuring that what was being returned was exactly what I intended, inferred types was hindering me.
By explicitly declaring the types, I was declaring the contract, and if I strayed from it by changing some internals, I was immediately notified that I broke the contract. Does that make sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm totally fine with that. I just was double checking that it was with a purpose and not because we just didn't have something being inferred.
I actually think declaring types has benefits, especially at the edges of code that consumers touch.
Micro.sync(() => log.error('Error handling token exchange response', error)), | ||
), | ||
Micro.flatMap((data) => | ||
Micro.promise(async () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Micro.promise
seems unneeded here, therefore making flatMap
unneccessary. I think this can just be simplified to a map
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, good catch!
store, | ||
options: storageOptions, | ||
}).pipe( | ||
Micro.flatMap((tokens) => |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nitpick, but I think tap
maybe more semantic. I think it should unwrap tokens
still
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a good callout. I've made the change in my local branch.
const state = store.getState(); | ||
const wellknown = wellknownSelector(wellknownUrl, state); | ||
|
||
if (!wellknown?.end_session_endpoint) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unrelated to tokens.get but I didn't notice this before. Do we need to add a check for || !wellknown.ping_end_idp_session_endpoint
? It seems the logout method calls one or the other depending on the server.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, this is actually a good question. This check is more like a quick check that we have a wellknown response, more or less. It's not really intended to be a complete error proof check. I'll have to think on it.
One more unrelated to tokens.get, sorry. In the logout method should we be passing some key to ping-javascript-sdk/packages/oidc-client/src/lib/client.store.ts Lines 446 to 449 in 764854f
|
No, the key is derived from the name saved within the closure of the |
JIRA Ticket
SDKS-4252
Description
This PR introduces local token
get
method with token auto-renew. This also introducesoauthThreshold
that will renew a valid token if it's within X time until expiration. The default is 30 seconds. This also extracts the bulk of exchange out of the top-level client file into it's own file for better sharing.