It’s been a couple days of tinkering already and I cannot seem to
find a way to do permissions within Absinthe that fully satisfies me.
I am essentially looking for a mechanism that handles roles and future
user-specific permissions the simplest way possible. At first I figured a
middleware would be the way to go, because one may grab the query
or mutation’s name directly from the passed resolution struct and work
from there - so basically grab the user previously stored within the context
and perform whatever checks both with the action name and the user struct.
Now, that would indeed do the trick but that is not quite a clean solution.
The reason being we only work with an action name and a user struct, as
well as possibly the arguments that were passed in from the resolution, and
therefore we’d pretty much end up having a single centralized module needing a
per-action specific definition to delegate pertinent permission checks to elsewhere.
Let me also include that the reason I am looking for a solution within the lines of
the above is because I would rather not do permission checks directly within the
resolving functions. Mainly because of readability concerns and code repetition.
Another concern to discuss would be resource fetching. In a regular phoenix setup one
could set-up their own plug that fetches a resource from an Ecto schema of sorts before
even reaching the controller’s function and then have a second plug right after that does
permission checks taking into account all the resources fetched prior. Ideally, one could
want to mimic this behaviour within Absinthe. For which an obvious solution would be to
call the resolving function manually, of course only in case of queries, and then in case of
a successful return pass the returned object down to the permission checks to determine
whether the resolution result should be set to an error or the actual successful response.
Of course when doing this we would ideally want to process all middlewares that go before
resolution, because otherwise we’d be losing the functionality provided by other middlewares.
And this is bad, real bad in fact. Because we would be recreating internal behaviour manually.
So to wrap up… I would love to hear how others have tackled these things to hopefully untangle.