Nothing magic about __guarded_setitem__ unfortunately.
Ah, so in fact __guarded_setitem__ is not much point at all...Hum.
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.
That could be a possibility.
Currently I do something tricky: I actually set it as a *property* on the session object. That way it goes away when the session goes away, and it's protected. But it's a nasty hack. ;)
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?
That is a very interesting idea indeed.
Another idea: Maybe I could make an object that does not have public access, and store that in the session?
I'll try that.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce