Add frontend for JWT refresh tokens #3273
Conversation
🦙 MegaLinter status: ✅ SUCCESS
See detailed report in MegaLinter reports
|
Test results 9 files 9 suites 8m 26s ⏱️ Results for commit 80d6175. ♻️ This comment has been updated with latest results. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #3273 +/- ##
==========================================
+ Coverage 60.58% 60.59% +0.01%
==========================================
Files 606 606
Lines 43733 43868 +135
Branches 48 48
==========================================
+ Hits 26494 26582 +88
- Misses 17227 17274 +47
Partials 12 12 ☔ View full report in Codecov by Sentry. |
stveit
force-pushed
the
jwt-refresh-token-frontend
branch
from
f33e025 to
38ae35e
Compare
stveit
force-pushed
the
jwt-refresh-token-frontend
branch
from
38ae35e to
80d6175
Compare
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| @pytest.fixture(scope="module") | ||
| def private_key() -> str: | ||
| """Yields a private key in PEM format""" | ||
| key = """-----BEGIN PRIVATE KEY----- |
Check failure
Code scanning / SonarCloud
Cryptographic private keys should not be disclosed High test
There was a problem hiding this comment.
Dummy key. But a more relevant point is that there are already tests that define PEM keys, so instead of redefining keys here its probably better to restructure the fixtures to allow this test file access to those fixtures
|
Adds a frontend for managing JWT refresh tokens. You can see which tokens exist, expire existing ones and generate new ones.
A quirk of allowing the users to expire the token by setting the expiry date to be
now, is that there will be a mismatch between the expiry timestamp in the token itself, and the expiry date in the database. Basically, the database timestamps decide if the token is active or not, not the claims in the token itself. In practice, I dont think this detail matters much, but a different approach could be to instead allow users to "Revoke" a token, setting an extra flag that marks the token as revoked without touching the expiry date itself. End result is that the db decides if its active or not either way, which is what we want so there actually is a way to revoke tokens.Thoughts?