Clojurians Log v2
pathom
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)
thanks!
short answer: no, but we can build one 🙂
ya, that discussion helps a lot! appreciate it!
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.
thanks, I’ll check on it asap
My PR didn’t fully address the issue so I went ahead and closed it and will reopen when I get a better solution.
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.
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)
@dehli can you try alpha16-SNAPSHOT and see if that works as expected for you?
awesome! i’ll give that a shot!
Just confirmed that the bug is gone 👍 thanks for the help!
this was the change in case someone is curious: https://github.com/wilkerlucio/pathom/commit/c9292962b54c2ad2820a626a8c82522798fa40bf
thanks! with it now being a runtime check should we wrap it with (when p.misc/INCLUDE_SPECS ?
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
the specs on connect are using guardrails to define, they don't check for p.misc/INCLUDE_SPECS
gotcha; thanks for the explanation!
no worries, and thanks for updating the issue