Open ChrisPenner opened 2 years ago
The HasServer
instance for Auth
does depend on cookie settings being present in the context anyhow:
To be clear, I do think it is a design wart: the instance should be independent on the authentication scheme. There is a draft PR that intends to solve this problem:
Awesome, glad to see there's a PR in the works. For now I guess I'll use one of the work-arounds I mentioned 👍🏼
Hi all 👋🏼
I've been setting up auth for my server using
servant-auth
andservant-auth-server
I've run into a few different issues, first for a bit of context:Pursuing this goal, I added the following type:
Now I use
Auth '[JWT] AccessTokenClaims
in my API routes, but my call tohoistServerWithContext
complains:Which is strange because I'm not reading or setting cookies anywhere, nor do I intend to.
I've read elsewhere that
servant-auth
sets session cookies for all users regardless of whether you want it to, and as a result ALSO requires aToJWT
instance on anything thatAuth
returns. This is at worst an annoyance forAccessTokenClaims
, but I proceeded to add a custom combinator which reads and validates the jwt, and then loads the user from our DB:The idea here is to allow loading the authenticated user for all requests which need it.
However once again I'm told that I need
ToJWT
forUser
, which implies that Auth wants to saveUser
in a session cookie. I don't want the User to be saved in a session cookie, not only is it potentially large, but it may hold sensitive information that shouldn't leave the server.It seems like this isn't how Auth is intended to be used, but simultaneously seems like the most sensible way to load an authenticated user safely.
I suspect I could write my own combinator to do this which circumvents
servant-auth
entirely, or I can just load the user inside every endpoint which requires it; but figured I'd ask whether this is something servant-auth supports somehow first.