Hello,
I am faced with a particular situation that don’t know how to solve.
Analyzing the logs from a customer, which uses my app from a REST client they created, I see that they are calling the Login method more frequent than they need. My guess is that they found it an easy way to ensure they are logged in (instead of using some of my other methods that return true/false for that) at all times.
The issue is the following: when logging in, I store some info on the Session.Values[] array, including an instance of an object that represents the user info. That instance is created at that point, and it’s destroyed when destroying the session.
So, doing the Login several times results on N instances of that class created, but as the session is not destroyed, then only the last instance is destroyed.
I have “solved” this simply checking if the login parameters sent correspond to the ones stored on the Session.Values[], and if that’s the case, then I just return Ok without doing anything more.
But then I thought: what if they sent some other login data? I was trying to destroy the session in that case then follow with the normal path: try the login, if Ok, then create the session, store the values, etc.
The issue here is that DestroySession() appears to only set a flag to destroy the session, for what I can see on the code, but that doesn’t happen until, I guess, the call finishes? If I call CreateSession() I stil get the same SessionID, for instance.
Calling the SessionManager.DeleteSession, although it does delete the session in that moment, the behavior afterwards seems undefined: I call the CreateSession hoping to get a valid one, but I get AVs when trying to access the Session.Values[] array, for instance.
So, apart from the obvious (fix the client), the other option I can think of is to just return an error if the client called Login in an existing session with different data. But I wonder if there is a way to make the “delete the old session and create a new one in the same call” path work.
Thanks!