This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-05-28
Channels
- # babashka (29)
- # beginners (179)
- # bristol-clojurians (1)
- # calva (9)
- # chlorine-clover (47)
- # cider (57)
- # clj-kondo (1)
- # cljs-dev (13)
- # clojure (241)
- # clojure-europe (9)
- # clojure-nl (4)
- # clojure-norway (88)
- # clojure-spec (4)
- # clojure-uk (15)
- # clojurescript (211)
- # clojutre (1)
- # community-development (8)
- # core-async (1)
- # datomic (31)
- # figwheel-main (33)
- # fulcro (29)
- # ghostwheel (6)
- # graalvm (11)
- # graphql (12)
- # instaparse (4)
- # jobs (1)
- # jobs-discuss (17)
- # leiningen (7)
- # malli (6)
- # meander (38)
- # off-topic (208)
- # onyx (6)
- # re-frame (23)
- # reagent (8)
- # shadow-cljs (61)
- # spacemacs (10)
- # sql (5)
- # yada (5)
I thought using a mutation login that after check user and password return a token that will pass in all queries. Is that a good way to do this?
We just pass an Authentication header, with a JWT that you got from an oauth provider
You can pass a connection-init-payload with Apollo or re-graph, and lacinia-pedestal can handle it
I use https://www.keycloak.org as an external OAuth 2 provider and have an interceptor attached to verify this token. Works fine.
… now I’m trying to use GraphQL directives implement role based access controls on resolvers and I’m struggling with finding the right place to put my interceptor…
We basically have a little interceptor in our stack that checks you have a valid access token (JWT in our case). So thats prior to lacinia getting involved.
And our clients send it with the Authorization
HTTP header using the Bearer
schema
Regarding https://lacinia.readthedocs.io/en/latest/directives.html… I use JWT for login/access control and in the token’s claims there are the roles assigned to the user. I used GraphQL directives to attach roles to queries and mutations and I’d like to check them before executing the resolver. Within the resolver I can access the directive defined in the schema:
(->> context
:com.walmartlabs.lacinia/selection
:field-definition
:directives
(filter #(= :access (:directive-type %)))
first
:directive-args
:roles)
In the schema the directive is defined like this:
:directives [{:directive-type :access
:directive-args {:roles ["admin"]}
and I can check against the claims I’m extracting from the JWT token using a custom interceptor.
Now I’m struggling to find the right place to inject an interceptor that checks the roles from the JWT token claims against the access-roles defined in the schema (query directive).
The thing is, that he context
in none of the places I tried to inject my interceptor has the :com.walmartlabs.lacinia/selection
key.
Any ideas?
… after digging around and thinking a little, I guess I’ll go with wrapping all resolvers before passing them to com.walmartlabs.lacinia.util/attach-resolvers
.
Any better ideas?