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 _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )