-
Notifications
You must be signed in to change notification settings - Fork 72
JWT Instances for servant-foreign #8
Comments
Looks good. I'll start a new package for it. My inclination is to have the instance be This kind of screws over Node, but I'm okay punting on that problem. |
@jkarni What is the package? :) |
I've had another go at this, with some success. Note that this requires GHC > 8.0 (but it will likely be possible to support earlier versions with the same principle). I'm not sure how it interacts with #31 or haskell-servant/servant#706. I've tested with It would be good to see some progress, as part of the integration of servant-auth.
This approach prefers Cookie auth over straight up JWT; I'm not sure how one would go about handling both. The closed type family generates the header name, and in principle another would be used to automatically ensure that the type family TokenHeaderName xs :: Symbol where
TokenHeaderName (Cookie ': xs) = "X-XSRF-TOKEN"
TokenHeaderName (JWT ': xs) = "Authorization"
TokenHeaderName (x ': xs) = TokenHeaderName xs
TokenHeaderName '[] = TypeError (Text "Neither JWT nor cookie auth enabled") instance
( TokenHeaderName auths ~ header
, KnownSymbol header
, HasForeignType lang ftype Token
, HasForeign lang ftype sub
)
=> HasForeign lang ftype (Auth auths a :> sub) where
type Foreign ftype (Auth auths a :> sub) = Foreign ftype sub
foreignFor lang Proxy Proxy req =
foreignFor lang Proxy subP $ req & reqHeaders <>~ [HeaderArg arg]
where
arg = Arg
{ _argName = PathSegment . T.pack $ symbolVal @header Proxy
, _argType = token
}
token = typeFor lang (Proxy @ftype) (Proxy @Token)
subP = Proxy @sub Annoyingly the (Edit: typo with TokenHeaderName in instance constraint) |
I'd like to suggest to keep the token header type family open, so as to support other auth schemes, which is the end goal of servant-auth. Similarly, should we always assume auth schemes use a header? Regardless, thanks already! We should indeed do our best to get this into a mergeable shape :) |
This is surely not the only place in the library where that might be assumed. I've no knowledge of any other schemes, so sadly I can't answer on that. I suspect the Anyway, keep it up. And I'll contribute any useful advances, here. |
@dbaynard oh it may not be indeed! I didn't mean to criticize your work. Certainly not. But in the context of the Google Summer of Code / Haskell.org Summer of Code, we might put together a proposal to implement a whole bunch of common auth schemes (see this ticket), so anything that makes that a little bit easier is welcome =) |
Relevant: haskell-servant/servant-elm#11 |
It would be handy to have instances for
HasForeign
fromservant-foreign
Something along the lines of this, I'm not sure about the correctness of using Text to represent JWTs, but I believe this is along the right lines. It could probably be generalised a bit too so it's not fixed to exactly
'[JWT]
The text was updated successfully, but these errors were encountered: