These are chat archives for deployd/contributors

16th
Jan 2015
Eric Fong
@ericfong
Jan 16 2015 10:16
Scott also have point that out.
I think we cannot fix that in the new release. But should target to fix this in next release. I hope can use 3rd party session management library instead of from deployd
Andrei Alecu
@andreialecu
Jan 16 2015 11:26
it's not necessarily a big fix, it can be fixed easily, we need to expose a session expiration time, and we need to not store sessions in the database unless there is an actual user login involved
no default sessions otherwise
which isn't a big deal since in a REST architecture as deployd should be, sessions should be really basic, which in this case would be just for authentication
Nicolas Ritouet
@NicolasRitouet
Jan 16 2015 11:27
ok
Andrei Alecu
@andreialecu
Jan 16 2015 11:27
and mongo actually has a timetolive feature which can delete records automatically http://docs.mongodb.org/manual/tutorial/expire-data/
Andrei Alecu
@andreialecu
Jan 16 2015 12:20
https://github.com/deployd/deployd/pull/486/files merge this when you can, I'm reworking it so for the sake of history and potential rollbacks to it, it should be there since it's a pretty critical fix
Nicolas Ritouet
@NicolasRitouet
Jan 16 2015 15:38
@andreialecu done
Andrei Alecu
@andreialecu
Jan 16 2015 15:38
I'm 99% done with the refactoring of sessions to not create one on every request
and I added expiration
I'm adding invalidation on username and password change
and will push soon
all tests pass and I tested in my app and it looks good
If only store a userId into the session is possible.
Andrei Alecu
@andreialecu
Jan 16 2015 16:27
we could, but you lose the capability of controlling sessions from the server
say you want only 2 simultaneous sessions ever per user, you can do that if you store the sessions on the server
with this MAC based approach that's pretty much impossible, although it does look like a good idea, I think in general it's mostly suitable for api-to-api (machine to machine) code
not as much for browser (user) to api
but we can mull it over, maybe provide it as an option in the future
I'm done with my session changes, even invalidation of previous sessions on user/password change works
Eric Fong
@ericfong
Jan 16 2015 16:31
I have not tried something like that too. But stateless scale well. We may need redis for session and websocket pub/sub
Great !
Andrei Alecu
@andreialecu
Jan 16 2015 17:02
deployd/deployd#489
well, here it is
if you have an app to test it on, it would be a good idea :)
all tests pass, I added another, and it seems to work great in my app so far, but need a second pair of eyes
Andrei Alecu
@andreialecu
Jan 16 2015 17:10
@ericfong regarding stateless login, also read here: http://security.stackexchange.com/questions/49145/avoid-hitting-db-to-authenticate-a-user-on-every-request-in-stateless-web-app-ar -> the logout issue in particular is of concern