Re: authentication/authorization

I had created a heirarchical perm scheme where Admin was the top node of
the perm tree, under that was guest and user. Under user were some other
options that I don't recall, but it could go to any arbitrary depth.

For each user you could permit or deny at multiple nodes in the tree,
and it applies to all sub nodes.

So a user with Admin permission will have access to everything unless
it's overridden for any subnodes.

It's been a long time since I've worked with any STML, but using it
would look something like this...

<:if Auth.have_perm("View Users") :>
<:include userform:>
<:endif:>

The permission system used MySQL. I started to try turn it into a
product to be able to drop it into other skunkweb projects. But I only
managed to get it working on my one skunkweb project, and I haven't done
any web development in a couple years.

The approach allowed for exellent granularity, so I thought I'd mention
it.

Spruce


On Wed, 08 Jun 2005 01:35:16 +0200, "Frank Tegtmeyer"
<[email protected]> said:
> Jacob Smullyan <[email protected]> writes:
> 
> > authenticated.  So it does do authorization, albeit only in a very
> > limited and inflexible way. 
> 
> Ok, I overlooked that.
> 
> All proposed things sound like never used - didn't you or anybody else
> implement something related to authorization? If you did, what was the
> approach?
> 
> > would be to make the vfs that AE uses security aware.
> 
> This would be interesting but also very "implicit" in its behaviour I
> think.
> 
> > admin_doSomething, guest_doSomething, friend_doSomething, etc.
> > callComponent could again be decorated/replaced so that you just call
> > <:component doSomething:> and the correct real component is
> > dispatched
> 
> This looks more like a thing I would like. It seems to be flexible
> enough to provide all that is needed.
> 
> > Of course, you could implement everything above AE, without changing
> > the behavior of callComponent, but then you have to restrict yourself
> > to the api you write; that isn't necessarily bad, however.
> 
> How would this be used? A call in every component? 
> 
> > What is your wish list for this?
> 
> I didn't think much about it, so take the list only as that what it
> is: some ideas/wishes.
> 
> - Roles/Groups
> - URL/scope based settings for a whole subtree of URLs (in Zope through
>   akquisition)
> - exceptions/override of inherited settings
> - different component output for different Roles/Groups
> - settings fixed (no change possible during runtime)
> 
> > In a few months I'm going to shift
> > my focus to skunk4, and maybe it should make this sort of concern more
> > central than it has been heretofore.
> 
> This sounds good, I hope to get some insight into skunkweb again and
> possibly Zope3 also. I would like to help - even with some stupid
> questions :)
> 
> Regards, Frank
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you
> shotput
> a projector? How fast can you ride your desk chair down the office luge
> track?
> If you want to score the big prize, get to know the little guy.  
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> Skunkweb-list mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/skunkweb-list


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20