Authenticated Requests via MQ - SessionId Durability

ServiceStack
1

I’ve been reading the documentation about “Authenticated Requests via MQ”:

I can’t understanding how the SessionId will work (code below).

I’m confused since my understanding is that the SessionId is temporary. So, how do we know for sure that when we process a message from the MQ we will still have information about a particular SessionId?

mqServer.RegisterHandler<AuthOnly>(m => {
    var req = new BasicRequest { Verb = HttpMethods.Post };
    req.Headers["X-ss-id"] = m.GetBody().SessionId;
    var response = ServiceController.ExecuteMessage(m, req);
    return response;
});

Thanks in advance

2

The ss-id Session Id Cookie is only temporary in that if you close the browser window, the browser will discard the ss-id Cookie so would need to re-authenticate to establish a new session (i.e. it’s an anonymous request). If you use RememberMe=True then the Session is stored against the ss-pid (permanent Session Id) instead, in which case the browser hangs on to the Cookie permanently and will survive browser restarts.

But the client (e.g. Windows Desktop App) doesn’t need to discard and can re-use the existing ss-id Cookie, in which case the session lasts as long as the Session Timeout indicating how long it’s kept in the Cache (ICacheClient) which by default SessionFeature.DefaultSessionExpiry == 2 weeks or when the user explicitly logs out, in which case the Session is explicitly cleared and the Session Id’s discarded.

3

Thank you Demis,

Would you consider adding support for using the UserId (instead of the SessionId which is transient)?

4

Not really, the Users session are stored against the sessionId so you can’t retrieve it using the userId. It would require maintaining a dictionary and implementing it in all Caching providers which is going to add unnecessary overhead. Although you should be able to maintain a dictionary if you need it yourself using the Auth/Session Events hooks available.

Note: the Session Id isn’t transient, the client can hold onto it for how long as it wants in which case only the Session Entry Timeout will expire and invalidate the Session (i.e. default 2 weeks). When that happens the Users Session no longer exists so not even using a UserId will help with accessing an expired Session.

I don’t see any issues when you want to send authenticated requests to authenticate first and then re-use the same session id for subsequent requests, i.e. the session should always be available.