You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As of jose v0.1, adding additional, unregistered claims to the ClaimsSet has been deprecated. addClaim and unregistedClaims may be removed in the future.
The suggested migration strategy is to wrap the ClaimsSet in an application-specific data type that carries both the standard claims set and any other data you wish to add. You would then implement JSON instances for this type and use the generic signJWT and verifyJWT functions instead of the claim-specific ones.
For example:
dataMyClaimsSet=MyClaimsSet{jwtClaims::ClaimsSet, jwtExtraClaim::Text}instanceHasClaimsSetMyClaimSetwhere
claimSet f s =fmap (\a' -> s { jwtClaims = a' }) (f (jwtClaims s))
instanceFromJSONMyClaimsSetwhere
parseJSON =...instanceToJSONMyClaimsSetwhere
toJSON s =...
This approach is incompatible with the current implementation of FromJWT and ToJWT in servant-auth. These both work with the ClaimsSet directly, making it impossible to add additional claims if the deprecated methods are removed.
decodeJWT m =caseKM.lookup"dat" (m ^.Jose.unregisteredClaims) of
Nothing->Left"Missing 'dat' claim"
Just v ->case fromJSON v of
Error e ->Left$T.pack e
Success a ->Right a
--| How to encode data from a JWT.
--
-- The default implementation stores data in the unregistered @dat@ claim, and
-- uses the type's @ToJSON@ instance to encode the data.
classToJWTawhere
encodeJWT::a->Jose.ClaimsSet
default encodeJWT ::ToJSONa=>a->Jose.ClaimsSet
encodeJWT a =Jose.addClaim "dat" (toJSON a) Jose.emptyClaimsSet
Migration Strategy
With the way things are currently set up, servant-auth needs to:
Be able to convert any arbitrary type into a JWT by default, i.e. instance ToJWT User. This uses the unregistered "dat" claim.
Be able to modify claims after calling encodeJWT. For example, set expiry.
Support applications that want to retain access to the ClaimsSet and have custom To/FromJWT instances.
One solution is to modify the ToJWT and FromJWT classes and create a wrapper around ClaimsSet that captures any unknown claims. Basically, we replicate the same logic that jose is deprecating. Something along the lines of master...sandydoo:servant:wip/jwt-additional-claims.
Description
As of jose v0.1, adding additional, unregistered claims to the ClaimsSet has been deprecated. addClaim and unregistedClaims may be removed in the future.
The suggested migration strategy is to wrap the
ClaimsSet
in an application-specific data type that carries both the standard claims set and any other data you wish to add. You would then implement JSON instances for this type and use the genericsignJWT
andverifyJWT
functions instead of the claim-specific ones.For example:
This approach is incompatible with the current implementation of
FromJWT
andToJWT
inservant-auth
. These both work with theClaimsSet
directly, making it impossible to add additional claims if the deprecated methods are removed.servant/servant-auth/servant-auth/src/Servant/Auth/JWT.hs
Lines 20 to 40 in 50e3bfb
Migration Strategy
With the way things are currently set up,
servant-auth
needs to:instance ToJWT User
. This uses the unregistered "dat" claim.encodeJWT
. For example, set expiry.ClaimsSet
and have customTo/FromJWT
instances.One solution is to modify the
ToJWT
andFromJWT
classes and create a wrapper aroundClaimsSet
that captures any unknown claims. Basically, we replicate the same logic that jose is deprecating. Something along the lines of master...sandydoo:servant:wip/jwt-additional-claims.cc @frasertweedale
The text was updated successfully, but these errors were encountered: