[goelsonali]

Description

Issue :
Unconditionally inserted a new token with no cap and no revocation of prior sessions; QA reproduced this by issuing 100 logins for one account and ending up with 100 simultaneously valid tokens, bounded only by the configured TTL.

Resolution :

1. Login now enforces exactly one active token per user: a Postgres advisory lock scoped to the transaction serializes concurrent logins for the same user ID, after which any existing active tokens are revoked before the new one is created.
2. A Caffeine-backed cache now sits in front of the user_tokens table (CachingUserTokenRepository)

• so the per-request token validation used by every authenticated call avoids a database round-trip.
• every write path that changes a token's validity (create, revoke, revoke-all) updates or evicts the corresponding cache entry in the same call.

Closes #655

Related Issue

Please link to the issue here

Change Type

• Bug Fix
• New Feature
• Code Refactor
• Documentation
• Test
• Other

Screenshots

Pull request checklist

Please check if your PR fulfills the following requirements:

• I checked and followed the contributor guide
• I have tested my changes locally.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[dricazenck]

I think you can review the PostgresMenteeRepository that show how to use Cacheable and is not needed to create another repository

[goelsonali]

@dricazenck - I cannot leverage the just the @Cacheable annotation as is, because it is not suitable for the findValidByToken method due to the custom logic of checking the token's validity (isRevoked and expiresAt).
The @Cacheable annotation caches the result of a method based on its parameters, and it does not allow for dynamic validation logic like the one I have implemented for findValidByToken.