satom99
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. ![]()
Trending in Questions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixirconf-us
- #elixir-ls
- #ai
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming










Showing Posts 1 to 6- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
OvermindDL1
For note, I do do permission checks in the resolving functions, because it specifically limits the amount of information as well, not just overall access. I have very fine grained permissions so I don’t see any other way of doing this.
hlx
Maybe passing options to
middleware/2macro will help.Example:
My personal opinion though is that your GraphQL (or any other API) layer is your client app and should not do permission checking. In our case the
MyAppapp is the logic app which contains all the app logic.MyAppAPIis a client app (GraphQL) that will handle the schema parsing and resolving andMyAppWebis the Phoenix app which basically just handles the routing and Plug stuff. This way we can add another client app, a REST API for example, and not have to reimplement the permissions mechanism in that app as well.In our app a plug (located in
my_app_api/lib/my_app_api/context.exstill fetches the access token from the request, looks up the correct token in the database and places that in the private absinthe context before the schema is parsed.Example:
jstlroot
Hi @OvermindDL1,
I’m trying to do the same thing you did, for exactly the same reasons.
However, I’m not yet able to figure out a way to use
Absinthe.Resolution.put_result(resolution, {:error, "forbidden"})(for example) in a resolver function, probably because, contrary to a middleware, resolver functions are meant to return data, not a resolution.One way I can think of would be to use a middleware in my schema after resolution but it seems very redundant.
Did you find a better approach?
Thank you in advance.
Cheers!
jstlroot
Bingo!
Wow, was I thinking about this the wrong way!
The resolution function’s return becomes the absinthe resolution’s result! Therefore, returning
{:error, "forbidden"}from the resolver function is the same as doingAbsinthe.Resolution.put_result(resolution, {:error, "forbidden"})in a middleware.It’s so stupidly simple and obvious now that I see it! I’ll leave this here anyway in case it could help someone.
Cheers!
OvermindDL1
Yep. ^.^
benwilson512
Simply return this value from your resolver.
Absinthe.Resolution.put_resultexists to map resolver tuples on to middleware. If you are in a resolver, just return the tuple.