Don't put user object in the session?
Felix Schwarz
Currently, middleware.py puts the user object in the session. I think this
causes some problems especially when using Beaker's client-side session
storage as you really want to keep cookies small.
middleware.py:
> session['authority.user'] = self.scheme.get_user()
I thought about only putting the user's name in the session, not a complete
user object. The user name can be used to recreate the user object
afterwards, it does not need to be pickled. Furthermore I think that some
objects (Elixir's database Entities come to mind) can not be pickled
without complications.
What about putting the user object in the environment?
--
Felix Schwarz
Dipl.-Informatiker
Gubener Str. 38
10243 Berlin
Germany
www.schwarz.eu - software development and consulting
Kevin Horn
If we don't put the whole user object into the session, how would we "key" the object? You suggested using the user's name, but what if the user's name is not unique? Several people have expresssed interest in a system that could handle duplicate names which are only unique across a certain company, or bank branch, or store location, etc. We can't use a database id, because only users with a database will have one.
I had considered putting the user object in the environment, but that leads back to the "keying" issue. How would we tell from the session which user object to put into the environment?
As far as holding extremely complex objects in the session, my current plan for database users is to have the scheme.get_user() function, get the Elixir/SQLAlchemy/whatever object and return a AuthorityUser object, so complexity of that object should be greatly reduced, and should be manageable even for client-side storage.
Of course, this is all just planning, and isn't implemented yet, so if anyone sees any holes in my reasoning, feel free to object :)
Kevin Horn
Felix Schwarz
> If we don't put the whole user object into the session, how would we
> "key" the object? You suggested using the user's name, but what if the
> user's name is not unique? Several people have expresssed interest in a
> system that could handle duplicate names which are only unique across a
> certain company, or bank branch, or store location, etc. We can't use a
> database id, because only users with a database will have one.
Yes, when I said "user name" I actually meant a application/scheme defined
id which can be used to identify a user. How to generate that id is up to
the application.
Say you have employees (which are authenticated against the enterprise
LDAP) and customers (which are authenticated against a database) and both
user groups do only have a numeric id. IMHO it should be up to the
application to build an id string (e.g. prefix the id with "e" for
employees and "c" for customers) to identify one specific user.
What I named "application" in the paragraphs above, should be part of an
authentication scheme in authority, I think.
> As far as holding extremely complex objects in the session, my current
> plan for database users is to have the scheme.get_user() function, get
> the Elixir/SQLAlchemy/whatever object and return a AuthorityUser object,
> so complexity of that object should be greatly reduced, and should be
> manageable even for client-side storage.
Yes, this sounds quite reasonable. Maybe we could require that the scheme
does only put an id string into the session and puts the user object
somewhere in the environment.
Kevin Horn
You'd still have to store and retrieve the user object from the environment though, which is something that beaker essentially gives us for free. So (disregarding the security and data storage implications of the case where you use beaker's client-side storage) I don't see the advantage.
Even if the user wants client-side storage, there are only 2 reasons it's a bad thing:
- security: Beaker requires you to encrypt client side cookies pretty well, so this shouldn't be a big issue. Also, no passwords, etc. should be stored in the user object.
- limited data storage: Since we're talking about a very basic object here (not a SQLAlchemy or Elixir class) I don't see this a a huge problem either.
Of course, users may store a different user object...it's intentionally easy to do, so they might shoot themselves in the foot, but we can only code around so many eventualities.
To me it's easier to just say "don't use client-side storage with Authority unless you really know what you're doing".
Of course, I don't like the idea of client-side storage much to begin with, so I guess I'm biased :)
Kevin Horn