Clojurians Log v2

it really depends on your architecture, in my case I never got too deep on it because I have mainly used Pathom as a big router doing HTTP requests to other services, and in this case I forward the user token, so the authorization check is done in the underlying service

but I think the best place is to it at resolver level, so you can fine tune the access on each edge of the system, I imagine you would start doing it quite manually in resolver code, but patterns will probably emerge, and once they do, you can write some plugins (or resolver transformers) to make it more ergonomic

From what i understand you are using pathom at Nubank to access information to multiple services which you mentioned above. What if customer support person wants to see extra details that only managers/admins/bank officials should be able to see? Meaning restful service has basic resource level authorization (that was historically used from a different place) but you specifically need to be careful about which properties client (customer support app) can see. You don't have cases like this? Would you still 'remove' those properties in the resolver? Separate question but related to this 'big router' you mentioned. How do you structure it? I am assuming you have routes that call resolves and pass information to the client. So client -> http -> big router -> resolvers -> rest of the services. Where http -> big router is quite basic api or is it? github says pathom3 is still alpha. Is that still the case? Pathom3 seems much more elegant to beginner like me Sorry i bombarded you with questions but pathom has such appeal to me i am so drawn to it 😄

no worries, the alpha state says more about my usage than project stability at this point, some folks have been using in prod, I will wanna retain some space to break things before making it non-alpha (mostly breaks in internal sides, maybe a few on user land, but I try to be diligent here, for full transparency, I might change internals related to error handling and tracing)

about the structure, its simple, there is a single API endpoint in the service thats the big router, the clients all use EQL requests though this service to fetch data, but I think its good to remember this is a specific system for customer support, not a widespread used API

and about authentication, its simple as a I told you, the details are in the token itself, which is a surrogate token that the customer support operator gets when it starts doing support, and that token already considers scopes and the customer being served, so they can only access things they are supposed to, so the token is the one that defines everything, which leaves this concern out of the router service (that used Pathom)

That's so niceee

We have an ABAC implementation that we call into, with:

(p.plugin/register
      {::p.plugin/id                                         `filter-in-entry
       :com.wsscode.pathom3.format.eql/wrap-map-select-entry filter-in-entry})

@danie i am not familiar enough with pathom to fully understand code snippet you shared. 😞 sorry Could you share little bit about ABAC implementation? I've never done it only read about it. Is it clojure based or some external service usage?

There's a discussion here https://github.com/souenzzo/eql-style-guide/issues/4

We use https://pathom3.wsscode.com/docs/plugins#eql-output to explicitly filter-in data the user is allowed to see. We have the token in the pathom-env, so we can do authorisation against that. When the resolvers return more than the user was allowed to query for, we alert on that as a second layer of checking. We wrote our own.