Superfluous calls on login/logout

[0cv]

I've put some console.log on login and logout and I always get a sequence of 1# get, 2# destroy, #3 set, e.g. for logout

<-- POST /api/User/logout?
getting sid SESSION:7sAWNTc02BKJE7iviPkNL7PhaqfacSDE, value: {"passport":{"user":{"_id":"5739d53fda88d2287e1f8631","username":"1234","password":null,"__v":0,"type":"User"}}}
destroying sid SESSION:7sAWNTc02BKJE7iviPkNL7PhaqfacSDE
setting sid SESSION:n-4yQqUH_q_OX9kZEhFcTlvZrmRnLDe3, value: {"passport":{}}
--> POST /api/User/logout? 200 419ms 4b

or for login:

<-- POST /api/User/login?include=user
getting sid SESSION:n-4yQqUH_q_OX9kZEhFcTlvZrmRnLDe3, value: {"passport":{}}
cb from login
destroying sid SESSION:n-4yQqUH_q_OX9kZEhFcTlvZrmRnLDe3
setting sid SESSION:n-4yQqUH_q_OX9kZEhFcTlvZrmRnLDe3, value: {"passport":{"user":{"_id":"5739d53fda88d2287e1f8631","username":"1234","password":null,"__v":0,"type":"User"}}}
--> POST /api/User/login?include=user 200 679ms 242b

Probably the logout does not need to set anything after having destroyed it, or the login does not need to destroy the session for after setting it anyway.

I think this line of code is aiming at tacking this issue, but session is not undefined, it's just the object inside the passport key, which is empty.

[Secbone]

@Krisa Yes, that is different way with passport. I think it's better to add an option to set the session key by custom, and I will check the empty object session too. Do you have a better way to resolve it?

[lostpebble]

I appear to be getting some similar logs with my session (connected to a Memcached store)

<-- GET /
Getting something from memcached session: Y02mgvruKOkIVqdjdYVLgmPAtl289iQb
{ userViews: 12 }
Injecting (MobX) state into current request/response context
Setting counter random value and getting a random user profile
Rendering React with state
Destroying something in memcached session: Y02mgvruKOkIVqdjdYVLgmPAtl289iQb
Setting something in memcached session: OjYnB8cFQcOVOFsKcQImAaMGN9vnohfF : {"userViews":13}
callback called
  --> GET / 200 887ms 3.35kb

Every single request to my site seems to get > destroy > set something in the session. But the session as a whole maintains it's state for whatever keys are set. Just seems a little strange.

[Secbone]

@lostpebble It seems you will update userViews on every single request and set it in the session. If you want update the session without destroy, maybe you can use the destroy method as a callback. That means the method is not real destroy your session store, it will be called before the session update or real destroy, so you can choose that destroy the old key and create a new key or just update in the method.

[lostpebble]

Okay, cool I'll try that thanks. So I see the default behaviour is to destroy the state completely if anything in the session changes, and create a new session. Is that normal session behaviour? I'm just curious, I don't know much about session management really.

[chang-zhao]

Okay, cool I'll try that thanks. So I see the default behaviour is to destroy the state completely if anything in the session changes, and create a new session. Is that normal session behaviour? I'm just curious, I don't know much about session management really.

I think it may depend on the session storage. If the session records are stored in temporary files, then perhaps it's easier to insert some information into an existing file. Probably the same with SQL-like databases, with their constant set of columns. But in case of in-memory or document-based databases, where objects are stored more like JSON strings, it may be more efficient to just rewrite the whole object, rather than searching the place to insert the changed value, then maybe shifting the right-side part of the object and inserting the new value inside... Not mentioning that we need enough free memory directly to the right of the object. It's easier to just destroy the record and put another one into any free place.