User stored in http session after custom auth

Hi,
I’m creating a custom authenticator, based on JWT access tokens.
The initial request (with ?accessToken=…) query Param works fine … I can identify and load the user etc.

However the user is not present in the session.

If I make a web request, there are lots of other background/ajax requests that all go unauthenticated and the browser page continually reloads.
If I make an initial request using cURL …

curl -i http://host/bin/view/Main/?accessToken=<JWT>

HTTP/1.1 200 
...
Set-Cookie: JSESSIONID=1D2A4E6F4B672A1526E8D60B6D89C768; Path=/; HttpOnly
...

<html> main page etc </html>

But then if I replay that but using the JSESSIONID cookie I just received …

curl -i --cookie JSESSIONID=1D2A4E6F4B672A1526E8D60B6D89C768  http://host/bin/view/Main/ 

HTTP/1.1 302
Location: /bin/login/XWiki/XWikiLogin?srid=Rm4tU6JI&xredirect=%2Fbin%2Fview%2FMain%2F%3Fsrid%3DRm4tU6JI
...

Then I am obviously not logged in.

Do I need to manually put the XWikiUser into the http session?

I don’t see this in any other authenticator.

Thanks for any help.

Depend on which authenticators you looked at. When you just implement Principal authenticate(String userId, String password, XWikiContext context) you indeed don’t need to do that because the returned Principal is put in the session, but when you bypass all this plumbing and directly react to XWikiUser checkAuth(XWikiContext context) (which is generally the case for a custom token based authenticator like yours) then you have to fully take care of stuff like remembering the current session principal (when the token is not sent with each request).

You can access the session through the XWikiContext (context.getRequest().getSession()).

Ah, excellent clarification.
Thank you
Rob