Fork me on GitHub
#pathom
<
2020-09-13
>
kenny16:09:46

Is there anything to be aware of if I were to call the parser within a resolver?

wilkerlucio17:09:18

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...)

Thomas Moerman10:09:04

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?

kenny14:09:20

@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.

Thomas Moerman18:09:09

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.

kenny18:09:41

Could you alter the query prior to calling the parser?

fjolne07:09:01

@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

Thomas Moerman08:09:54

Thanks, i'll look into it.

Thomas Moerman09:09:00

Ok I think I understand it now, that's indeed a subtle vulnerability that I did overlook tbh... many thanks for pointing that out