losing session cookie between end points (unsolved)

[faint pulsar]

This seems to be a problem of your front-end 😁 in your FE http library you'll need to set withCredentials: true in order for the browser to attach the cookies to the requests.

[lunar hedge]

have you read my post fully?

to persist login on my front-end i have a end point that requests the session data using said cookie

i'm doing the exact same thing here
use cookie -> session -> return user

[faint pulsar]

I did read it, although I got a bit confused with persisting login, so I pointed out the most common reason why cookies get lost 🙂
It would be helpful to see a screenshot of the network tab in your browser of both the working endpoint and the /users. Headers tab is the one that tells us most.

[lunar hedge]

although /me is not protected by a guard unlike /users
both need the req.user
/me uses it to help my front-end persist if logged in/found

/users needs it to verify the user role
if user does not exist the guard stops it and gives a 403

the fact /me returns the user means i'm authenticated
and can return req.user just fine

then why does the /users guard stops it then?

this issue does not arise when doing the same with a http-client

[faint pulsar]

That's hard to tell without seeing the code of the guard. Or the Headers tab.
If /users request works from one http client and not from the other, you have to find what's different. And since requests are mostly headers, comparing headers is what you should do first.

[lunar hedge]

the code of the guard is pretty simple and nothing to special

@Injectable()
export class SessionGuard implements CanActivate {
  private readonly logger = new Logger(SessionGuard.name)
  async canActivate(context: ExecutionContext) {
    const req = context.switchToHttp().getRequest()
    const authenticated = req.isAuthenticated()
    return authenticated
  }
}

but due the fact the cookie is missing -> user is undefined -> return false
i already have logged debugged and check this

[faint pulsar]

Also, it says Cached at the highlighted request. It's a good idea to disable cache (there's a checkbox for that in upper right corner), so you're sure the issue is actually only on one of the requests. Maybe /me is cached from earlier and doesn't work now either, that would change the view a bit.

[lunar hedge]

disabled the cache

and reloaded the page
the /me re-fetches the user and works just fine
/users still did not change a thing as expected

comparing the headers of both requests

HTTP/1.1 403 Forbidden
Content-Length: 69
ETag: W/"45-T7Txzr/IRLfQ4TEPfbVWLpgje4Q"

those 3 where extra in the /users that the /me didn't have
further they share the exact same response headers

[faint pulsar]

Right, sorry, the Request tab is the interesting one in Firefox, that's where the Request Headers are — what the client sent to the server.

[lunar hedge]

both have are the exact same as the Request tab is empty

"No payload for this request"

going to take my rest before tunnel vision takes over here

[lunar hedge]

even stranger now
i have the cookie so why does my back-end not have access to req.user