Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2020-10-16

Channels

#pathom
<
2020-10-16
>
dehli15:10:44

Is there a standardized way to handle access control with pathom? i have an upstream resolver that checks for access but I’d like to prevent downstream resolvers from resolving for cases where access is restricted. I can do a runtime check in each resolver to see if the upstream resolved value is something like :access-denied but I’m curious if there’s something more baked into pathom (I couldn’t find anything when looking through the docs)

souenzzo15:10:01

short answer: no, but we can build one 🙂

dehli16:10:19

ya, that discussion helps a lot! appreciate it!

dehli18:10:23

When I pass identity as {::pc/transform identity} to my defresolver I’m getting identity - failed: fn? Has anyone seen something similar? (I’m using alpha15) Edit: I think it’s a bug. I’ll get a test pushed up and see if I can trace it. Here’s the failing test: https://github.com/wilkerlucio/pathom/pull/176 and a potential fix.

wilkerlucio23:10:33

thanks, I’ll check on it asap

thanks3 3
dehli15:10:44

My PR didn’t fully address the issue so I went ahead and closed it and will reopen when I get a better solution.

dehli16:10:37

I believe the problem is that the spec is checking at compilation time rather than run time so to the compiler it’s just seeing transform as a symbol, persistentlist, etc.

wilkerlucio16:10:05

gotcha, makes sense, I'm doing a few tests here, I guess the solution is to move the validation into resolver instead of defresolver for the options map, this way validate on the realised values (instead of the macro stuff)

wilkerlucio16:10:11

@U2U78HT5G can you try alpha16-SNAPSHOT and see if that works as expected for you?

dehli16:10:43

awesome! i’ll give that a shot!

dehli16:10:30

Just confirmed that the bug is gone 👍 thanks for the help!

dehli16:10:33

thanks! with it now being a runtime check should we wrap it with (when p.misc/INCLUDE_SPECS ?

wilkerlucio16:10:16

I have a little concern with performance, but not much, unless someone is doing resolver generation on the fly all the time, this shouldn't be an issue, and for those cases the user can create the resolver without going though pc/resolver

wilkerlucio16:10:32

the specs on connect are using guardrails to define, they don't check for p.misc/INCLUDE_SPECS

dehli17:10:21

gotcha; thanks for the explanation!

wilkerlucio17:10:28

no worries, and thanks for updating the issue

👍 3