Chris McDonough wrote:
REQUEST.SESSION.set('__ac_username', 'root')

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 - )

Reply via email to