If possible, instantiate connection to JWKS on startup #3795
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
🦋 Changeset detectedLatest commit: a0e6346 The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 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 |
Collaborator
|
Thanks for the Neo4j GraphQL Toolbox updates. The Neo4j GraphQL Toolbox has now been torn down - reopening this PR will republish it. |
Collaborator
Performance ReportNo Performance Changes Show Full Table
Old Schema Generation: 39.834s |
a-alle
reviewed
Aug 16, 2023
Comment on lines
+117
to
+124
| if (secret instanceof Uint8Array) { | ||
| debug("Verifying JWT using secret"); | ||
| const { payload } = await jwtVerify(token, secret, this.authorization.verifyOptions); | ||
| return payload; | ||
| } | ||
| debug("Verifying JWKS using url"); | ||
| const { payload } = await jwtVerify(token, secret, this.authorization.verifyOptions); | ||
| return payload; |
Contributor
There was a problem hiding this comment.
these are now the same. Is there any reason for the if-else?
Contributor
Author
There was a problem hiding this comment.
Yeah, believe it or not, TypeScript gives an error if you don't do it like this - I don't know if there's a way to resolve this without @ts-ignore.
| return payload; | ||
| } | ||
|
|
||
| private async verifyBearerToken(token: string, secret: Key): Promise<JWTPayload> { |
Contributor
There was a problem hiding this comment.
verify was changed to receive the resolvedKey all the time, but verifyBearerToken was not. Is there a reason for this?
Contributor
Author
There was a problem hiding this comment.
This actually mirrors the previous behaviour - keys were not resolved via callback for Subscriptions. I want to change this in 4.0.0 where we have the better context typings - it's almost too difficult here.
This was referenced Aug 18, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
If possible, instantiate connection to JWKS on startup. I was informed that caching was not working between requests, and this was because we were instantiating a new JWKS connection on every request.
This PR, where it can, creates a single connection on startup.
NOTE: Subscriptions are a hot mess ("bearerToken" stuff) - this needs fixing on 4.0.0 where we have better context typings. The context there needs looking at.
Complexity
Complexity: Low