Christopher Arndt schrieb:
> Ken Kuhlman schrieb:
>> I haven't tried it, but it looks like you should be able to just add an
>> "identity.require" line to your config sections.
> 
> I thought I knew the identity framework in TG1 pretty well but I never
> noticed this functionality. Amazing! I don't think this is documented
> anywhere in the official docs. I'm opening a ticket now...

I did some test with this functionality today and it turns out the code
in SecureResource to read the identity predicate from the configuration
is buggy and rather useless:

1) URLs served by the CherryPy static filter bypass the controller tree
completely, so there's nowhere to attach a SecureResource mix-in too.

2) Even if it were possible, you can't set a identity predicate object
instance in a config file, you have to do it in your Python code with
'config.update()'. Which somehow defeats the purpose of having a
configuration setting for this at all. It seems that at the time when
Jeff Watkins wrote this, the configuration was still Python code, so I
guess it made sense then.

3) When SecureResource checks the 'identity.require' setting, it doesn't
specify a config path, so you can't do something like this:

[/path/to/controller]
identity.require = ???

resp.

config.update({'/path/to/controller': {
    'identity.require': identity.not_anonymous()}}

You are only able to set one identity predicate globally, which is
rather limiting.

4) Finally the current code has a name error bug: it uses
'turbogears.config.get' but the top-level package is not imported, so it
should be 'config.get'. This bug only manifests itself when the
SecureObject instance has no 'require' attribute (fixed in SVN now).


BUT, I have written a small controller, which emulates the CherryPy
static filter and implements reading identity permissions from the
configuration. In this implementation you are only able to specify a set
of permissions (OR-ed together), which is required to access the static
files served by this controller. Most of the other predicates can be
expressed by setting up appropriate permissions and assigning users to
groups and groups to permissions, so I don't think this is a real
limitation. If you need finer access control you can always change the
implementation or overwrite the 'permissions' property of the
identity.current object.

Here's the `controller.py` file for a quickstarted project with SA
identity, which contains the implementation of this controller:

http://paste.chrisarndt.de/paste/954084526979404f9f178ba8129da381


Share & enjoy!

Chris

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to