tg1 - where do I define detailed authorization predicates for static content?

[Daniel Fetchinson]

I understand that if I want to enable authorization/authentication for
static content then all I have to do is put identity.on = True into
the static content sections of my configuration file:

[/static1]
static_filter.on = True
static_filter.dir = '%(top_level_dir)s/static1'

[/static2]
static_filter.on = True
static_filter.dir = '%(top_level_dir)s/static2'

But where do I define who is exactly allowed access to /static1 and
/static2? In particular I'd like to allow users in group A to access
only /static1 and users in group B to access both /static1 and
/static2. Where do I need to put the code corresponding to these
predicates?

Cheers,
Daniel

--
Psss, psss, put it down! - http://www.cafepress.com/putitdown

[Ken Kuhlman]

On Tue, Sep 15, 2009 at 9:21 PM, Daniel Fetchinson <fetch...@googlemail.com> wrote:

[/static1]
static_filter.on = True
static_filter.dir = '%(top_level_dir)s/static1'

[/static2]
static_filter.on = True
static_filter.dir = '%(top_level_dir)s/static2'

But where do I define who is exactly allowed access to /static1 and
/static2? In particular I'd like to allow users in group A to access
only /static1 and users in group B to access both /static1 and
/static2. Where do I need to put the code corresponding to these
predicates?

Cheers,
Daniel

I haven't tried it, but it looks like you should be able to just add an "identity.require" line to your config sections.

See:
  The SecureObject class in turbogears.identity.conditions
  http://trac.turbogears.org/changeset/552
  http://nerd.metrocat.org/2006/01/refining-the-identity-framework

hth,
-Ken

[Christopher Arndt]

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

> See:
> The SecureObject class in turbogears.identity.conditions
> http://trac.turbogears.org/changeset/552
> http://nerd.metrocat.org/2006/01/refining-the-identity-framework

Wow, where did you dig up that article?! Almost from the prehistoric age
of TurboGears ;) Interestingly, Jeff seems to claim that SecureObject
should protect a whole controller tree too, not only SecureResource. If
that is so, it sheds a new light on #2207.

Chris

[Ken Kuhlman]

I knew it would be a good question since it was from Daniel, so I went digging.  I saw the reference to an identity.require config setting in turbogears.identity.conditions right away but couldn't find any docs so I went googling. 

After reading a related thread, where Kevin Horn asked about moving identity predicates from controller code to config [1], I was able to narrow the search down to postings from Jeff Watkins.  That led me to his blog. 

If those days weren't prehistoric, they were at least the wild west. :-)

Thanks,
-Ken

[1] http://groups.google.com/group/turbogears/browse_thread/thread/31840a7cbdfac119

[Daniel Fetchinson]

>> > 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...
>>
>> > See:
>> > The SecureObject class in turbogears.identity.conditions
>> > http://trac.turbogears.org/changeset/552
>> > http://nerd.metrocat.org/2006/01/refining-the-identity-framework
>>
>> Wow, where did you dig up that article?! Almost from the prehistoric age
>> of TurboGears ;) Interestingly, Jeff seems to claim that SecureObject
>> should protect a whole controller tree too, not only SecureResource. If
>> that is so, it sheds a new light on #2207.
>>
>>
>> Chris
>>
>>
> I knew it would be a good question since it was from Daniel, so I went
> digging. I saw the reference to an identity.require config setting in
> turbogears.identity.conditions right away but couldn't find any docs so I
> went googling.
>
> After reading a related thread, where Kevin Horn asked about moving identity
> predicates from controller code to config [1], I was able to narrow the
> search down to postings from Jeff Watkins. That led me to his blog.
>
> If those days weren't prehistoric, they were at least the wild west. :-)

Thanks a lot Ken!

When this problem came up I thought this must be dead easy, went
through the docs but didn't find anything, which kind of gave me the
I-thought-I-knew-more-or-less-how-tg1-identity-works,-but-apparently-I-don't
moment Chris was describing :) But I had no leads from there on, so
thanks again for digging this up.

[Kevin Horn]

Wow, that _is_ ancient history...I had completely forgoten that discussion.

Kevin Horn

[Christopher Arndt]

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

[Ken Kuhlman]

On Wed, Sep 23, 2009 at 6:26 PM, Christopher Arndt <chris...@web.de> wrote:

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

Sorry for sending you on a wild goose chase.   Nice work hunting it down & making something tasty out of it!

-Ken