Fork me on GitHub
#graphql
<
2018-04-04
>
souenzzo14:04:56

About graphql and auth: 1- Is a good idea send the token next to query? ( ?query=...&token=123 on url or {"query": "...", "token": "123"} on body) 2- I want to put a interceptor before the "main handler" that get this token, open, valid, and assoc :user 123 on the ctx. I know do this in pedestal, but on lacinia-pedestal there is some easy way to do (wo compromise ws and other cool stuff from lacinia pedestal)?

boubalou14:04:15

I believe that the best approach is actually to put/expect it to be in the headers.

boubalou14:04:40

And you use a lib such as Buddy to parse the headers within your isolated authenticated calls.

souenzzo15:04:56

and about the interceptors on lacinia-pedestal?

boubalou15:04:21

I have no idea about this one tho. We use ring middleware in our main project.

mattly16:04:51

both the Github graphQL API and the one I’m working on use tokens in the Authorization header

hlship18:04:18

Couple of options for #2. The request map is (by default) exposed as :request in the context passed to field resolvers (which, despite the name, is entirely distinct from the Pedestal context).

hlship18:04:52

But if you're writing your own interceptor, you can inject it into Lacinia's interceptor pipeline and put a new key directly into the field resolver context prior to query execution.

hlship18:04:25

If you do it after the query is parsed, you can even do checks that correlate the user (and their permissions) against the operations in the GraphQL request.

stijn18:04:44

I read this article when I started with lacinia, it explains a bit the 2 options: https://dev-blog.apollodata.com/a-guide-to-authentication-in-graphql-e002a4039d1

stijn18:04:13

we went for option 1 though. I think it's the simplest solution, although option 2 does have some advantages as well

stijn18:04:58

if you're looking for an example that uses option 2, I believe https://scaphold.io/ does so

souenzzo14:04:37

Thks 4 all; I will try to inject my custom interceptor.