Why does JwtCirce.decode lead to java.time.Clock validating the expiration? #504
Replies: 3 comments
-
It looks like you're inheriting it from trait JwtCore[H, C] {
implicit private[jwt] def clock: Clock
...
}
trait JwtJsonCommon[J, H, C] extends JwtCore[H, C]
...
trait JwtCirceParser[H, C] extends JwtJsonCommon[Json, H, C] The wording of |
Beta Was this translation helpful? Give feedback.
-
@drewboardman if you can guide can I pick up this issue ? |
Beta Was this translation helpful? Give feedback.
-
The fact that I'm moving it to discussions so you can discuss the problem you're facing. |
Beta Was this translation helpful? Give feedback.
-
The
JwtCirce.decode
function does not implicitly take an instance ofjava.time.Clock
jwt-scala/core/src/main/scala/JwtCore.scala
Line 809 in c73b571
However, this leads to the function
JwtTime.validateNowIsBetween
jwt-scala/core/src/main/scala/JwtTime.scala
Line 60 in c73b571
This is unexpected behavior. I've tried searching through the flow of this decoding, and I can't find where this
Clock
instance gets slipped in.Is this intentional? The documentation seems to infer that
JwtCirce
simply decodes the JWT, and makes no assumptions about its expiry.Beta Was this translation helpful? Give feedback.
All reactions