Francesco
Absinthe seems to work with an Absinthe.Resolution instead of Plug.Conn, however this makes interacting with Plug.Conn quite difficult, the only way seeming to be to hook into the before_send callback of Absinthe.Plug.
In cases where you need to change the session or cookies based on the return value of a resolver (for example a login mutation), then it’s not immediately obvious how to go about doing that. My current approach is to use a piece of middleware to put the resolution value on the resolution context, and then in the before_send callback grab that information and do whatever I need to do with Plug.Conn.
So my questions are:
- Why doesn’t Absinthe expose Plug.Conn for use in mutations?
- Is my current method of interacting with Plug.Conn (using the resolution context and before_send callback) the recommended best practice?
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Catch errors, track performance, monitor hosts and more.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #elixirconf-eu
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Bringing learning, work and compliance together since 1987.
**Building the future of software with AI, trust, and human connection.**
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Most Liked- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
axelson
I think most people (including me, and others from what I’ve gathered here and in the slack channel) handle login outside of graphql, that way all the graphql requests are fully authenticated already. Then it’s just a matter of adding what authentication info you need into the absinthe resolution context.
hauleth
GraphQL, in theory, do not require HTTP. Sometimes it is via WebSockets, but it can be over any other protocol you want. Nothing in standard prevents you from serving GraphQL queries over SCTP with ETF as a transport format.
benwilson512
Absinthe.Plug has this, Absinthe does not. Absinthe will continue to insist that GraphQL operations are handled without regard for transport. Absinthe.Plug is welcome to map Plug.Conn data to the context and map context info back to the conn, and I’m happy to consider proposals that make that more streamlined.
If you mean Absinthe middleware here, consider just ditching a resolver for that operation and just using middleware.
resolveis a thin layer aroundmiddlewareanyway.Last Post!
axelson
Have you looked at the context and authentication guide in the docs? The Context and Authentication — absinthe v1.11.0
You create a plug and call
Absinthe.Plug.put_options(conn, context: context)where context has something like:{current_user: user, login_count: 9}and whatever other info you need in your resolvers for your context.I’d recommend looking into Pow - Robust, modular, extendable user authentication and management system for the authentication if you don’t currently have anything, but plain hand-rolled cookies can be fine too, although I don’t have any guides handy for that.
Edit: sent early