First of all thanks for this amazing library. Thanks a lot. The docs for authorization in Apollo docs suck
I have a doubt, is it possible to authorize subscriptions using graphql-shield? Mutations are also possible, right?
Thanks, it鈥檚 always great to get a welcoming feedback from other developers.
Shield does support mutations as you already mentioned. I am not uterly sure about subscriptions though. I think there might be a portion which works, but general functionalty is not implemented.
PS.: watch out for the new version which should debut soon as this will be one of the majors in the new release!
Cool. Is there any ETA for the new version? I'm waiting :)
Nah, nothing explicit yet. The most accurate we can do right now is soon. 馃檪
OMG, I was banging my head why shield doesn't work with subscription.
@maticzav can we please keep this open? subscriptions are fundamental to graphql. having this library admit access on subscription level is of paramount importance to quite large audience from apollo/yoga crowds.
isAuthenticate rule is being hit during subscription access evaluation. however no way to whitelist the specific



Error: Not Authorised!
at normalizeOptions (/Users/polfilm/git_madstat/api-apollo/app/node_modules/graphql-shield/src/shield.ts:25:32)
at shield (/Users/polfilm/git_madstat/api-apollo/app/node_modules/graphql-shield/src/shield.ts:43:29)
at Object.<anonymous> (/Users/polfilm/git_madstat/api-apollo/app/src/permissions.js:25:35)
at Module._compile (internal/modules/cjs/loader.js:688:30)
at Module._compile (/Users/polfilm/git_madstat/api-apollo/app/node_modules/pirates/lib/index.js:83:24)
at Module._extensions..js (internal/modules/cjs/loader.js:699:10)
at Object.newLoader [as .js] (/Users/polfilm/git_madstat/api-apollo/app/node_modules/pirates/lib/index.js:88:7)
at Module.load (internal/modules/cjs/loader.js:598:32)
at tryModuleLoad (internal/modules/cjs/loader.js:537:12)
at Function.Module._load (internal/modules/cjs/loader.js:529:3)
So evaluation of authorization is not taken under consideration.

@styk-tv could you compose a small reproduction repository? I believe this might be connected to graphql-middleware.
isAuthenticate rule is being hit during subscription access evaluation. however no way to whitelist the specific
I am not sure I understand what you mean "however no way to whitelist the specific". Could you elaborate on that so I can better understand the use case?
I am facing a similar issue. I want to protect subscriptions, but sadly ctx.request is undefined here when the connection is made using websockets whilst it works perfectly for queries and mutations.
const rules = {
isAuthenticated: rule()(async (parent, args, ctx, info) => {
return ctx.request.user !== null;
})
};
@bartosz-maciaszek could you compose a short reproduction repository?
Hey 馃憢,
I believe this issue is not connected with graphql-shield but rather a design decision in Yoga and Apollo Server.
(**) Notice that the req argument is an object of the shape { request, response, connection } which either carries a request: Request property (when it's a Query/Mutation resolver), response: Response property (when it's a Query/Mutation resolver), or a connection: SubscriptionOptions property (when it's a Subscription resolver). Request is imported from Express.js. Response is imported from Express.js aswell. SubscriptionOptions is from the graphql-subscriptions package. SubscriptionOptions are getting the connectionParams automatically injected under SubscriptionOptions.context.[CONNECTION_PARAMETER_NAME]
https://github.com/prisma/graphql-yoga#constructorprops-props-graphqlserver
PS.: @serverwentdown thank you for the reproduction. I hope this helps you solve your problem 馃檪
"I believe this issue is not connected with graphql-shield but rather a design decision in Yoga and Apollo Server."
This is like saying universe is flawed for producing gravity hence instead of putting steat belts in a car we will wait for laws of physics to change.
Subscriptions must be adressed. Until then, this bug should remain open.
@styk-tv I am not sure you鈥檝e read the entire issue.
I believe there are two different issues here.
The first @bartosz-maciaszek pointed out about the ctx.request being undefined has nothing to do with this library.
Apollo server provides a way to handle it with a combination of the 'subscriptions.onConnect' and 'context' options in the constructor.
The issue I'm currently facing is the rule isn't fired when the subscribe function is run.
Like it's bypassing the middleware entirely but only when running subscriptions.
Could someone provide reproduction for the second case? I am not sure whether this has been addressed in the thread.
Due to all these struggles, I rebuilt my app on Rest api which have very good authentication and authorization (Loopback). Later I put GraphQL on top. Feels much better!
@maticzav https://github.com/DavyBello/graphql-shield-subscribe-test
Run node index.js
i like what you done so far but it will be an excellent if there are to handle authorization for subscriptions with this repo
So can this lib used for subscriptions? And if yes, with what server or setup?
I managed to get ride of this issue in graphql-yoga
the problem is not in the shield library, but in the way to handle the access token
the rule : isAuthenticated in grapql-yoga for example uses the function
export function getUserId(context: Context) {
const Authorization = context.request.get('Authorization')
if (Authorization) {
const token = Authorization.replace('Bearer ', '')
const verifiedToken = verify(token, APP_SECRET) as Token
return verifiedToken && verifiedToken.userId
}
}
it seams that the request property of the context is not accessible from subscriptions
to get the user id you have to use another property which is "connection" the Authorization status can be accessible from it, so this code works fine for me
export function getUserIdForSubscriptions (context : Context) {
const Authorization = context.connection.context.Authorization
if (Authorization) {
const token = Authorization.replace('Bearer ', '')
const verifiedToken = verify(token, APP_SECRET) as Token
return verifiedToken && verifiedToken.userId
}
}
don't forget to declare it in the interface of the context
import { PubSub } from 'graphql-yoga'
import { ContextParameters } from 'graphql-yoga/dist/types'
export const pubSub = new PubSub()
export interface Context {
connection : any
request: any
pubSub : PubSub,
}
export function createContext(request: ContextParameters) {
return {
...request,
pubSub,
db
}
}
hope this will help
I believe there are two different issues here.
The first @bartosz-maciaszek pointed out about the ctx.request being undefined has nothing to do with this library.
Apollo server provides a way to handle it with a combination of the 'subscriptions.onConnect' and 'context' options in the constructor.The issue I'm currently facing is the rule isn't fired when the subscribe function is run.
Like it's bypassing the middleware entirely but only when running subscriptions.
@navigui
What about this?
Most helpful comment
@maticzav can we please keep this open? subscriptions are fundamental to graphql. having this library admit access on subscription level is of paramount importance to quite large audience from apollo/yoga crowds.
isAuthenticate rule is being hit during subscription access evaluation. however no way to whitelist the specific

So evaluation of authorization is not taken under consideration.