Re: [Zope-dev] Protected session items?
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]
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 )
Re: [Zope-dev] Protected session items?
Lennart Regebro wrote: Another idea: Maybe I could make an object that does not have public access, and store that in the session? That seems to work! Here is the class: class ProtectedUsername: An object where the username is not accessible from user code. def _setUsername(self, username): self.__username = username def _getUsername(self): return self.__username Very simple indeed. It is impossible to define up a class that has methods that start with underscore from user code. and even other usercode classes seem not to be pickable (is that correct?) so even though you can replace the value of SESSION['__ac'] you can't replace it with any usercode object, and definitely not with anything that has a _getUsername() method. And, as additional security, when I use I check that it really is a ProtectedUsername object: if ob is not None and isinstance(ob, ProtectedUsername): username = ob._getUsername() This *should* mean, that as long as you don't allow usercode to import a ProtectedUsername object, it should be safe. In fact, you can't even figure out what the username is. ;) It would be great if somebody could try and break this. Hmmm. I should offer an incentinve of some sort. I'll buy you a beer (or equivalent) next time you are in Paris, if you succeed ;) //Lennart ___ 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 )
Re: [Zope-dev] Protected session items?
Hi, Am Fr, den 27.08.2004 schrieb Lennart Regebro um 11:32: Lennart Regebro wrote: Another idea: Maybe I could make an object that does not have public access, and store that in the session? That seems to work! Here is the class: class ProtectedUsername: An object where the username is not accessible from user code. def _setUsername(self, username): self.__username = username def _getUsername(self): return self.__username Very simple indeed. It is impossible to define up a class that has methods that start with underscore from user code. and even other usercode classes seem not to be pickable (is that correct?) so even though you can replace the value of SESSION['__ac'] you can't replace it with any usercode object, and definitely not with anything that has a _getUsername() method. And, as additional security, when I use I check that it really is a ProtectedUsername object: if ob is not None and isinstance(ob, ProtectedUsername): username = ob._getUsername() This *should* mean, that as long as you don't allow usercode to import a ProtectedUsername object, it should be safe. In fact, you can't even figure out what the username is. ;) Even a traceback will not show this username anymore if its inside an object without __repr__ :-) Regards Tino ___ 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 )
Re: [Zope-dev] Protected session items?
class ProtectedUsername: An object where the username is not accessible from user code. def _setUsername(self, username): self.__username = username def _getUsername(self): return self.__username Very simple indeed. Even a traceback will not show this username anymore if its inside an object without __repr__ :-) Well the username is not secret. Indeed, it would be interesting to have a __str__ to debug what's in SESSION and maybe allow user code to check what's there. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 71 59 http://nuxeo.com mailto:[EMAIL PROTECTED] ___ 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 )
Re: [Zope-dev] Protected session items?
Florent Guillaume wrote: class ProtectedUsername: An object where the username is not accessible from user code. def _setUsername(self, username): self.__username = username def _getUsername(self): return self.__username Very simple indeed. Even a traceback will not show this username anymore if its inside an object without __repr__ :-) Well the username is not secret. Indeed, it would be interesting to have a __str__ to debug what's in SESSION and maybe allow user code to check what's there. Yup. However, I just made it a bit more generic, so now it's not the username that is stored, but any authentication info you might like. That makes it possible to use from other plugins too, but of course, displaying it them may be a bit more sensitive. Probably it would only store username and password, and the user obviously already knows his own password, but still... Ah well, this is PLuggableUserFolder internal stuff anyway, so... ___ 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 )
[Zope-dev] Protected session items?
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 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! :) 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? //Lennart ___ 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 )
Re: [Zope-dev] Protected session items?
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 )
