[Zope-dev] Protected session items?

[Chris McDonough]

On Thu, 2004-08-26 at 11:06, Lennart Regebro wrote:
> In TransientObject __guarded_setitem__ is just set to __setitem__.
> This means, that everything you set in the session dictionary is 
> changeable through user code. Is there a good reason for this?

I don't think __guarded_setitem__ is at fault.

> I think it would be nice if I could set secret things in the session, 
> mainly authentication information. If i do this currently, any user code 
> can change it, which isn't exactly safe.
> 
>     REQUEST.SESSION['__ac_username'] = 'root'
> 
> Ooops! :)

REQUEST.SESSION.set('__ac_username', 'root')

Nothing magic about __guarded_setitem__ unfortunately.

For this particular case maybe just don't trust __ac_username in the
session; just put the credentials in the session as __ac and do what
CookieCrumbler does (set REQUEST._auth, and so on) on each request from
trusted code.  Then it becomes exactly as safe as basic auth or cookie
auth wrt risk of identity change.

I agree though that it would be nice to be able to have a kind of
session where the ability to write anything into it could be restricted
by a permission.

> This change:
> 
>      def __guarded_setitem__(self, k, v):
>          if k[0] == '_':
>              raise SomeThingOrAnotherError
>          self.__setitem__(k, v)
> 
> Fixes that. Then you can only set it from protected code.
> Is there some reason why this is NOT a good idea?

Since nobody does attribute access with a session
(SESSION.__ac_username), they always do SESSION['__ac_username'], or
SESSION.get('__ac_username'), it's even more magical than usual in the
Zope sense.  The session was always meant to act almost exactly like a
dictionary and not like a typical persistent SimpleItem-based Zope
object.

I suspect that the problem of providing "authorized" session data access
can be solved using permissions and place instead of baking the
underscore hack in (a separate session data manager and/or transient
object container could be used to provide this kind of session and it
could be put in a separate place).  Too bad I didn't anticipate this in
TransientObject and protect the setting methods with some permission
(they're all public now).  But maybe a subclass or alternate
implementation could do that?

- C