JWT Creation and Expiry Check
Create two JWTs for the same user_id — one that expires an hour from now, and one that (deliberately) already expired an hour ago — then decode both and report the result.
Note: rather than literally creating a short-lived token and sleeping past its expiry (which would add a real, judge-timeout-risking delay to every run), this problem builds the "already expired" case directly by setting its exp claim in the past — testing the exact same jwt.decode()/ExpiredSignatureError behavior instantly and deterministically.
Approach: encode a validtoken (exp = now + 1 hour) and an expiredtoken (exp = now - 1 hour) for the given user_id, decode each in its own try/except, and print the outcome of both.
Input: One line: an integer user_id.
Output: Two lines: "Valid token decoded: user_id=<id>" and "Expired token: correctly rejected as expired".
42
Valid token decoded: user_id=42 Expired token: correctly rejected as expired
- user_id is a positive integer
Hint 1
jwt.encode(payload, SECRET_KEY, algorithm="HS256") signs a payload dict into a token string.
Hint 2
Setting "exp" to a datetime already in the PAST (datetime.utcnow() - timedelta(hours=1)) makes a token that is expired the instant it's created — no need to wait for real time to pass.
Hint 3
jwt.decode(token, SECRET_KEY, algorithms=["HS256"]) raises jwt.ExpiredSignatureError for a token whose exp has already passed.
Both tokens are created and decoded immediately — no real waiting is involved. The "valid" token's exp is set an hour in the future, so jwt.decode() succeeds normally. The "expired" token's exp is deliberately set an hour in the PAST, so jwt.decode() raises ExpiredSignatureError right away, exercising the exact same rejection path the notes describe (creating a token, waiting for it to expire, then failing to decode it) without needing an actual, judge-unsafe real-time delay.