[CentralOH] (Pyramid) Web Design

[Thomas Winningham]

No you're spot on, session is maintained as a separate collection of a
state outside of credentials. I know Gmail for instance likes to also
inform you at the bottom of the page where all it has registered
sessions and what IP they come from and are currently, or have been,
logged in using your credentials.

Expiration is to just pick some time in the future to expire the data.
The stuff you'd want to expire would be things that need to be unique
per session only... everything else it makes sense that two logins
would see that data identically as it is updated and as they refresh.
You'd ideally want to make sure the database couldn't block or lock,
but I think those kinds of things are working better by default these
days.

Just my 2c! I wish you luck!!

On Thu, Dec 8, 2011 at 9:45 AM, Mark Erbaugh <mark at microenh.com> wrote:
> In the demo pump sizing application that I showed during my presentation Monday night, I was keeping state information in a user record which is tied to the user id. That seemed like a good idea at the time, but what if two users log on with the same credentials? Obviously, the state information would become confused.
>
> One solution would be to use a different mechanism to hold state information. Perhaps there could be a unique record for each login, not just each user. The problem here would be how to expire the record, otherwise the database would fill up.
>
> A better (IMO) solution would be to prevent the second logon with the same user id. The problem here is that the first user could have left the application wiithout formally logging out, which means if the application sets a flag indicating that the user is logged in, that flag might not get reset when the user is actually done.
>
> How is this handled in real-world applications?
>
> Thanks,
> Mark
> _______________________________________________
> CentralOH mailing list
> CentralOH at python.org
> http://mail.python.org/mailman/listinfo/centraloh