This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-04-11
Channels
- # announcements (14)
- # beginners (119)
- # boot (9)
- # calva (7)
- # cider (12)
- # cljdoc (2)
- # cljsrn (28)
- # clojure (127)
- # clojure-dev (2)
- # clojure-europe (3)
- # clojure-italy (2)
- # clojure-losangeles (9)
- # clojure-nl (6)
- # clojure-spec (15)
- # clojure-uk (39)
- # clojurescript (35)
- # community-development (4)
- # cursive (9)
- # datascript (8)
- # datomic (5)
- # duct (3)
- # emacs (10)
- # fulcro (45)
- # graphql (3)
- # jobs (1)
- # kaocha (8)
- # luminus (2)
- # off-topic (121)
- # onyx (3)
- # pathom (15)
- # pedestal (31)
- # planck (5)
- # reagent (25)
- # reitit (3)
- # remote-jobs (1)
- # shadow-cljs (48)
- # slack-help (1)
- # sql (142)
- # tools-deps (78)
There's a reason that we parse the query in one interceptor, and execute it in a later interceptor. There's a point in the middle where you can identify what the operation is. Our code at Walmart uses that opportunity to apply auth, and whitelist what operations a given API key is allowed to access.
I’m simply building my authorization checks for mutations atop the mutations’ resolver fns, though if there grew to be a bunch of them, separate interceptors would be easier to validate. But my question was at a slight remove from that: I wanted a query that could tell me if a given mutation (with some subset of args) might be authorized.
I now have a :may
query which takes a mutation name and an json string map of args and returns a boolean, which is reasonable, if a little annoying what with the map smuggling.