-
Notifications
You must be signed in to change notification settings - Fork 984
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
fix(auth): Allows RedwoodAuthCurrentUserQuery when using Auth, GraphQL and Trusted Documents #10817
Merged
Conversation
This file contains 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
dthyresson
changed the title
DRAFT: fix(auth): Allows RedwoodAuthCurrentUserQuery when using Auth, GraphQL and Trusted Documents
fix(auth): Allows RedwoodAuthCurrentUserQuery when using Auth, GraphQL and Trusted Documents
Jun 19, 2024
Josh-Walker-GM
approved these changes
Jun 19, 2024
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.
Looks good. We discussed this and everyone was happy with the approach to let this particular query bypass the persisted operation logic.
Josh-Walker-GM
pushed a commit
that referenced
this pull request
Jun 25, 2024
…L and Trusted Documents (#10817) Fixes #10816 This is a draft proposal to allow authentication to function as expected when using Trusted Documents. See the issue above for more detail. One way to solve is to allow an arbitrary ad-hoc query -- but just a very narrow and well-defined (aka trusted so-to-speak) one. The plgin for persisted operations lets one define what can bypass trusted docs hash id checks: https://the-guild.dev/graphql/yoga-server/docs/features/persisted-operations#allowing-arbitrary-graphql-operations So, we can use that in the useTrustedDocuments plugin to just allow that specific request. ``` const REDWOOD__AUTH_GET_CURRENT_USER_QUERY = '{"query":"query __REDWOOD__AUTH_GET_CURRENT_USER { redwood { currentUser } }"}' ``` When using Redwood Auth, we want to allow the known, trusted `redwood.currentUser` query to be executed without a persisted operation. This is because the `currentUser` query is a special case that is used to get the current user from the auth provider. We'll check if the request is for the `currentUser` query and has the correct headers which are set by the useCurrentUser hook in the auth package. The usePersistedOperations plugin relies on this function to determine if a request should be allowed to execute via its allowArbitraryOperations option. By checking for that very exact string, and that there is a content type header, an auth-provider header and an authorization header then we can allow this to execute. The auth provider will still be used by the apes getCurrentUser resolver to determine if the credentials whatever they are are valid. Needs discussion.
1 task
Josh-Walker-GM
pushed a commit
that referenced
this pull request
Jun 28, 2024
…L and Trusted Documents (#10817) Fixes #10816 This is a draft proposal to allow authentication to function as expected when using Trusted Documents. See the issue above for more detail. One way to solve is to allow an arbitrary ad-hoc query -- but just a very narrow and well-defined (aka trusted so-to-speak) one. The plgin for persisted operations lets one define what can bypass trusted docs hash id checks: https://the-guild.dev/graphql/yoga-server/docs/features/persisted-operations#allowing-arbitrary-graphql-operations So, we can use that in the useTrustedDocuments plugin to just allow that specific request. ``` const REDWOOD__AUTH_GET_CURRENT_USER_QUERY = '{"query":"query __REDWOOD__AUTH_GET_CURRENT_USER { redwood { currentUser } }"}' ``` When using Redwood Auth, we want to allow the known, trusted `redwood.currentUser` query to be executed without a persisted operation. This is because the `currentUser` query is a special case that is used to get the current user from the auth provider. We'll check if the request is for the `currentUser` query and has the correct headers which are set by the useCurrentUser hook in the auth package. The usePersistedOperations plugin relies on this function to determine if a request should be allowed to execute via its allowArbitraryOperations option. By checking for that very exact string, and that there is a content type header, an auth-provider header and an authorization header then we can allow this to execute. The auth provider will still be used by the apes getCurrentUser resolver to determine if the credentials whatever they are are valid. Needs discussion.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Fixes #10816
This is a draft proposal to allow authentication to function as expected when using Trusted Documents.
See the issue above for more detail.
One way to solve is to allow an arbitrary ad-hoc query -- but just a very narrow and well-defined (aka trusted so-to-speak) one.
The plgin for persisted operations lets one define what can bypass trusted docs hash id checks: https://the-guild.dev/graphql/yoga-server/docs/features/persisted-operations#allowing-arbitrary-graphql-operations
So, we can use that in the useTrustedDocuments plugin to just allow that specific request.
When using Redwood Auth, we want to allow the known, trusted
redwood.currentUser
query to be executed without a persisted operation.This is because the
currentUser
query is a special case that is used to get the current user from the auth provider.We'll check if the request is for the
currentUser
query and has the correct headers which are set by the useCurrentUser hook in the auth package.The usePersistedOperations plugin relies on this function to determine if a request should be allowed to execute via its allowArbitraryOperations option.
By checking for that very exact string, and that there is a content type header, an auth-provider header and an authorization header then we can allow this to execute.
The auth provider will still be used by the apes getCurrentUser resolver to determine if the credentials whatever they are are valid.
Needs discussion.