This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-09-13
Channels
- # announcements (5)
- # babashka (23)
- # beginners (3)
- # business (6)
- # clj-kondo (40)
- # clojure (81)
- # clojure-berlin (1)
- # clojure-france (12)
- # clojure-nl (1)
- # clojure-norway (1)
- # clojurescript (4)
- # cursive (7)
- # data-science (1)
- # datascript (1)
- # emacs (9)
- # events (1)
- # fulcro (37)
- # malli (3)
- # meander (5)
- # membrane (2)
- # nrepl (1)
- # parinfer (1)
- # pathom (9)
- # re-frame (31)
- # reitit (10)
- # sci (2)
- # shadow-cljs (3)
- # sql (3)
- # tools-deps (16)
- # uncomplicate (4)
- # vrac (1)
Most things should work, but understanding how pathom works can surely helps, a few points that quickly come to my mind: - cache is shared, so if you env up hitting cached resolvers, pathom will use the cache - adds a cost of more planning, which just means you are doing some of the parser work again (convert query to ast, create a plan for each attribute you ask, plugin infra to run, etc...)
I was wondering about this too, is calling a parser from within a mutation the correct approach for e.g. resolving some permission keywords that need to be taken into account? Or is there a better approach to resolve some contextual information during a mutation?
@U052A8RUT Perhaps your use case is more specific but in our mutations we'll typically return a map that has, at least, a /id
attribute that a pathom resolver takes as an input. Pathom will then resolve any additional keys through the regular facilities.
My case is different: the idea is to call the parser to use the existing resolvers to resolve additional (e.g. permission) info that might prevent the mutation from executing. So it's not a mutation join using an /id
return value, as you mention.
@U052A8RUT it’s generally fine, but you should beware of calling parser with the current env, as it can be modified via open idents by the user [1]. there’s some discussion on auth best practices [2] [1] https://github.com/souenzzo/eql-style-guide#security [2] https://github.com/souenzzo/eql-style-guide/issues/4
Thanks, i'll look into it.
Ok I think I understand it now, that's indeed a subtle vulnerability that I did overlook tbh... many thanks for pointing that out