This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-04-04
Channels
- # aws (1)
- # beginners (163)
- # boot (1)
- # bristol-clojurians (1)
- # cider (7)
- # clara (1)
- # cljs-dev (22)
- # cljsjs (1)
- # clojure (43)
- # clojure-denver (1)
- # clojure-finland (6)
- # clojure-italy (1)
- # clojure-nl (3)
- # clojure-russia (1)
- # clojure-spec (1)
- # clojure-uk (6)
- # clojurescript (107)
- # cursive (4)
- # data-science (2)
- # datascript (2)
- # datomic (19)
- # duct (31)
- # emacs (1)
- # fulcro (50)
- # graphql (15)
- # hoplon (3)
- # lein-figwheel (2)
- # luminus (21)
- # off-topic (74)
- # onyx (3)
- # parinfer (15)
- # portkey (2)
- # precept (9)
- # proton (1)
- # re-frame (130)
- # reagent (73)
- # reitit (7)
- # ring-swagger (5)
- # shadow-cljs (61)
- # spacemacs (18)
- # specter (12)
- # uncomplicate (1)
- # vim (88)
- # yada (2)
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)?
I believe that the best approach is actually to put/expect it to be in the headers.
And you use a lib such as Buddy to parse the headers within your isolated authenticated calls.
both the Github graphQL API and the one I’m working on use tokens in the Authorization
header
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).
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.
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.
http://walmartlabs.github.io/lacinia-pedestal/com.walmartlabs.lacinia.pedestal.html#var-default-interceptors spells out the existing interceptors and their execution order, and http://walmartlabs.github.io/lacinia-pedestal/com.walmartlabs.lacinia.pedestal.html#var-inject is an easy way to add a new interceptor to the chain.
These come together as the :interceptors option to http://walmartlabs.github.io/lacinia-pedestal/com.walmartlabs.lacinia.pedestal.html#var-service-map
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
we went for option 1 though. I think it's the simplest solution, although option 2 does have some advantages as well
if you're looking for an example that uses option 2, I believe https://scaphold.io/ does so