Spring Security - SecurityContext always returning null

Greetings everyone, I’ve been struggling with hours of research, blogs, and YouTube video to resolve this. I’m trying to implement a login, register, logout, and currentUser routes in my controllers. I set authentication successfully in the log in route, however when I try to get the same user I authenticated in the currentUser route, I can access the principal user because it’s always null. I’ve tried billions of implementations and I’m basically now begging for assistance. The code base can found at: https://github.com/abufaarooq/productiv

Execution proceedings:

Register by sending a POST request, to: localhost:8080/api/v1/add, use the payload below:

{
   "id": 1,
   "firstName": "John",
   "lastName":"Applesead",
   "userName":"john123",
   "email": "[email protected]",
   "passWord": "1234",
   "userRole": "USER",
   "locked": false,
   "enabled":true
}

Send another POST request to: localhost:8080/api/v1/login, user the payload below:

{
"username": "john123",
"password": "1234"
}


Send a GET request to: localhost:8080/api/v1/currentUser, no payload required - this end point return null every time. That’s where my issue lays.

HTTP does not support continuous sessions like time-sharing systems do.

Every HTTP request/response is an independent connect/process/disconnect cycle.

The server cannot tell one logged-in user from another automatically. Every user on my LAN appears to be coming from the same source IP (it's a NAT system) and anyway, sometimes I have multiple browsers connecting to the same server, each of which would have a separate login.

Thus, in order to obtain the fiction of a continuous session, you have to provide context that uniquely — and securely! — defines your login session.

When using container-managed security, that context is the jsessionid value, which is sent either as a cookie or as an appendage to the URL that the logged-in client submits.

However, container-managed security requires a server-side HTTPSession to associate with that jsessionid, so it's not the best approach for ReST, and especially for an entire bank of ReST servers, In such a case, the security system you use has to return a similar token of its own.

What I think is your problem is that you should be getting back such a token when you log in, and you need to hold it and send it back on your subsequent ReST requests. If you don't do that, then your subsequent requests will not have a login identity and thus no userid.