You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 3, 2021. It is now read-only.
I am confused as to how an example such as this, found in your documentation, is compatible with graphql-auth-directives:
const server = new ApolloServer({
schema: augmentedSchema,
context: ({ req }) => {
return { /* Note: We return a context object containing both `driver` and `req` fields */
driver,
req
};
}
});
Given that graphql-auth-directives usage effectively co-opts the entire context object via returning only one sub-field of the context object it processes:
const server = new ApolloServer({
schema,
context: ({ req }) => { /* Here we pluck the variable `req` from context, via a destructured fn param */
return req; /* Here we substitute req for the entire context object from which it came */
}
});
And if we inspect graphql-auth-directives, we find that the verifyAndDecodeToken function takes for granted that the context object is the req:
var verifyAndDecodeToken = function verifyAndDecodeToken(_ref) {
var context = _ref.context; /* <-- Note: I *will not* find the headers on "_ref.context.req" */
if (
!context ||
!context.headers ||
(!context.headers.authorization && !context.headers.Authorization)
) {
throw new _errors.AuthorizationError({
message: "No authorization token."
});
}
Thus we end up in a situation where whenever an authDirective is used, we get the error message "No authorization token.", regardless of whether there's a valid auth header in the req.headers.authorization field of the object returned by the handler we've assigned to the ApolloServer constructor's config.context.
Yet the usage pattern is officially documented.
Am I overlooking something simple here? Perhaps I've been staring at the screen for too long, but on my end changing the code in verifyAndDecodeToken such that it expects a context object possessing a req field fixes the issue and makes my directives behave as expected, given the usage pattern documented in the neo4j-graphql-js docs.
The text was updated successfully, but these errors were encountered:
Phylodome
changed the title
Conflicting isAuthenticated & Middleware Context req Patterns
Conflicting Auth Directives & Middleware Context Config Patterns
May 13, 2019
I am confused as to how an example such as this, found in your documentation, is compatible with
graphql-auth-directives
:Given that
graphql-auth-directives
usage effectively co-opts the entire context object via returning only one sub-field of the context object it processes:And if we inspect
graphql-auth-directives
, we find that theverifyAndDecodeToken
function takes for granted that thecontext
object is thereq
:Thus we end up in a situation where whenever an authDirective is used, we get the error message
"No authorization token."
, regardless of whether there's a valid auth header in thereq.headers.authorization
field of the object returned by the handler we've assigned to theApolloServer
constructor'sconfig.context
.Yet the usage pattern is officially documented.
Am I overlooking something simple here? Perhaps I've been staring at the screen for too long, but on my end changing the code in
verifyAndDecodeToken
such that it expects a context object possessing areq
field fixes the issue and makes my directives behave as expected, given the usage pattern documented in theneo4j-graphql-js
docs.The text was updated successfully, but these errors were encountered: