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.
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.