Hi Ori, This is odd, and the behavior (in the logs) make it seem like there are multiple calls to the REST API happening here (or maybe one of those calls is using a temporary "short lived" token?).
When I see those three logged lines, they don't seem possible to occur *for the same request*. Each time you see that "Received valid token" or "tried to use an expired token" sort of message should be a separate REST API request (as far as I'm aware). That'd imply to me that perhaps one of those requests is using either a token that either *is invalid* or *is expired*. It is also possible that it's something with your EPerson object. I do see that token "invalidation" occurs by setting the "SessionSalt" to empty. This kills the user's session. See the code here: https://github.com/DSpace/DSpace/blob/main/dspace-server-webapp/src/main/java/org/dspace/app/rest/security/jwt/JWTTokenHandler.java#L194-L203 If you are curious about how JWTs are supposed to behave, they have very extensive automated tests (to ensure they are secure) in these classes. There are many scenarios tested there including expired tokens, tampered tokens, token invalidation, etc. Maybe they can provide clues to you as well. * https://github.com/DSpace/DSpace/blob/main/dspace-server-webapp/src/test/java/org/dspace/app/rest/security/jwt/JWTTokenHandlerTest.java * https://github.com/DSpace/DSpace/blob/main/dspace-server-webapp/src/test/java/org/dspace/app/rest/AuthenticationRestControllerIT.java I admit, it's very difficult to understand what is going on here. But those are my best guesses based on what you've provided. Tim On Monday, November 13, 2023 at 5:52:51 PM UTC-6 [email protected] wrote: > Kia ora all, > > I'm writing a library to integrate one of our services with DSpace 7.6 and > I'm having an issue with the REST API that occurs when I run integration > tests. > > Every so often, a call to the REST API will return an HTTP 401 > Unauthorized, despite being logged in as an admin account, the JWT not > having expired, and correctly sending the CSRF header and cookie. > > Looking at the logs, it seems that DSpace is detecting the JWT as invalid. > However, the *same* token is used both before and after this point > without issue, as shown below: > > 2023-11-14 11:28:52,796 DEBUG unknown unknown > org.dspace.app.rest.security.jwt.JWTTokenHandler @ Received valid token for > username: [email protected] > > 2023-11-14 11:28:52,864 WARN unknown unknown > org.dspace.app.rest.security.jwt.JWTTokenHandler @ 0:0:0:0:0:0:0:1 tried to > use an expired or non-valid token > > 2023-11-14 11:28:52,968 DEBUG unknown unknown > org.dspace.app.rest.security.jwt.JWTTokenHandler @ Received valid token for > username: [email protected] > > This occurs even I if I add a check to the /authn/status endpoint to > ensure that the client is still authenticated before making each call. > > The only related oddity I've managed to note in the logs is that the > EPerson for the user is mostly blank: > > 2023-11-14 11:28:52,913 DEBUG unknown 4eb31978-f7fd-414f-851c-a9a0d7071efe > org.hibernate.internal.util.EntityPrinter @ > org.dspace.eperson.EPerson{handles=<uninitialized>, > metadata=<uninitialized>, salt=[redacted], lastActive=2023-11-14 > 11:28:51.279, sessionSalt*=*, netid=null, > resourcePolicies=<uninitialized>, requireCertificate=false, > groups=<uninitialized>, digestAlgorithm=SHA-512, selfRegistered=false, > canLogIn=true, password=[redacted], legacyId=null, > id=41784848-fe6c-4b7e-82db-c81fe3c89f6e, [email protected]} > > But for other calls it's populated correctly. > > Ngā mihi nui, > Ori > -- All messages to this mailing list should adhere to the Code of Conduct: https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx --- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/8b749ac0-6410-4783-922c-8377a291c296n%40googlegroups.com.
