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