Oscar Rambla wrote:

>>
>>
>>This I would suggest putting in private_thing.  Then when you add another
>>access-controlled object you simply have it inherit (or implement directly)
>>whatever access method and there's no need to add to a growing switch in
>>_q_access.
>>
Yeah, well, actually, I have quite some calls which need to be secured.
I'm actually working on an User - Role - Permission implementation. Each
method/function would get a permission which the user which requests the
method needs to have before continuing.

>
>There are some situations that this is not clear.
>Ex: Supose you want  permit someone to view an object but you don't want to
>let him edit it.
>
>I guess different solutions:
>.Adapt export list to session info, but that raises Traversal Error instead.
>.Use _q_lookup for everything.
>
Done that, works quite well actually. That way the "secured" methods are
not listed in _q_access, which is kind of strange.

>.Wrap methods or functions with classes provided with q_access;  over clompex
>for most cases.
>
I was thinking about using descriptors from the new-style classes to
help out here. http://users.rcn.com/python/download/Descriptor.htm>, but
that only works for methods, and not for modules.

Well doing the check in the method itself is also not bad. It can be
done in one or maybe even two lines of code. It also matches with the
"no magic" idea of quixote.

After thinking about it a bit more, I think _q_access is meant to do
access checks for an entire namespace, and not just for an accessable
member of that namespace. Works the same for items listed in _q_exports,
and items returned by _q_lookup. That would be kind of messy if that
would be done with _q_access.

Anyhow, thanks for the feedback,

Maas