Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Andrei Alecu
    @andreialecu
    should be minor
    Nicolas Ritouet
    @NicolasRitouet
    ok :sparkles:
    Andrei Alecu
    @andreialecu
    deployd/deployd#485
    is this squashable? I pushed to the same branch I used before instead of making another
    Andrei Alecu
    @andreialecu
    the bug I fixed in #486 actually appeared in the wild once here: https://travis-ci.org/deployd/deployd/builds/46467404 in a randomly failed travis build
    in my case I could not actually login a user and retrieve it without crashing deployd without this fix. because my mongo is not on the same network as where I'm hosting my app
    Andrei Alecu
    @andreialecu
    @ericfong or @NicolasRitouet , if you have production apps can you check db.sessions.stats()
    the session handling in deployd is so rudimentary at this point that the table grows indefinitely and can even create a new session on every request without ever deleting any of them
    deployd/deployd#314
    I have 7451 sessions in mine without any actual production so far, just my testing
    Nicolas Ritouet
    @NicolasRitouet
    "count" : 11803
    but I have something like 5 users using the app almost everyday
    Andrei Alecu
    @andreialecu
    there is a huge issue in the code where if you don't resend the sid cookie that was first generated it will create a new session every time
    Nicolas Ritouet
    @NicolasRitouet
    ok
    Andrei Alecu
    @andreialecu
    this is especially possible across servers with CORS
    for example the $http object in angular needs an extra flag passed to it {withAuthentication: true}
    otherwise the cookie is not sent by default, thus creating sessions on every single request
    it's also impossible now to log out a user without deleting the session from mongo directly, they never expire
    once logged in you'll be logged in forever
    Nicolas Ritouet
    @NicolasRitouet
    :worried:
    Andrei Alecu
    @andreialecu
    if you change the username or password, that still doesn't log the session out
    you have to change the user id to invalidate a session, that's the only way
    Nicolas Ritouet
    @NicolasRitouet
    ok
    I have to go, we can talk about that later
    Eric Fong
    @ericfong
    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
    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
    ok
    Andrei Alecu
    @andreialecu
    and mongo actually has a timetolive feature which can delete records automatically http://docs.mongodb.org/manual/tutorial/expire-data/
    Andrei Alecu
    @andreialecu
    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
    @andreialecu done
    Andrei Alecu
    @andreialecu
    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
    Eric Fong
    @ericfong
    If only store a userId into the session is possible.
    Andrei Alecu
    @andreialecu
    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
    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
    deployd/deployd#489
    well, here it is