directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Wallace <rwall...@thewallacepack.net>
Subject Re: [authx] Help with complicated authorization
Date Mon, 20 Jun 2005 02:52:24 GMT
Vincent Tence wrote:

><snip/>
>
>  
>
>>I looked into Tapestry a while ago and it seemed overly complicated from 
>>the very outset.  I mean, it seemed to require a lot of work to get even 
>>a simple webapp up and running.  
>>    
>>
>
>It requires some time to learn it, but once you get it, putting up a
>webapp is
>pretty easy and fast. The catalog of web components is really cool.
>
>  
>
>>I'll do some more looking into Tapestry 
>>because there are some things about JSF I don't like.  For one thing, it 
>>seems like it will be impossible to add form elements in a dynamic 
>>fashion with DHTML and not doing form resubmits.
>>    
>>
>
>That's the real plus of Tapestry. It goesa along very well with
>traditional HTML development.
>
><snip/>
>
>  
>
>>It all sounds very cool.  Unfortunately, I need to start cranking some 
>>stuff out right away, so I think I'll need to go with Acegi for now. 
>>    
>>
>
>I can't blame you for that ;-) That's the wise choice for now
>
>  
>
>> As for where to start, it's hard to say since I'm not familiar enough with 
>>what's there.  I would say probably getting the policy stuff to be more 
>>dynamic (if it isn't already) would be the first thing to work on.
>>
>>    
>>
>
>Scripted rules are already dynamics. they get reloaded every time the
>script file change. XML rules doesn't support that, altough it could be
>done. 
>
>I'm curious. How do you make Acegi permissions dynamic? I've not find a
>way to fdo that without reloading the Spring Context.
>
>  
>
I pretty much plan to use the ACL system for assigning users permissions 
to domain objects.  Then the objects a user has permission to and what 
operations they can perform can change at runtime.  It's still a PITA 
for two reasons: 1) managing the ACLs and 2) possible overhead with 
checking the ACLs.  The first is really a matter of being able to have 
it be seemless from the users perspective.  Users will still have roles 
and those roles will have mappings to what permissions they should get 
to an object when they are assigned to it.  Changing what permissions a 
role has or adding new roles would be cumbersome tho.  The second is 
something I'm not entirely sure about with Acegi, but have had to deal 
with before in an ACL model like this.  Basically, when you want a user 
to be able to do a search on, for instance, all projects assigned to 
them or to someone else.  Of course, you only want to show them what 
they have access to.  Further, links in the HTML table will appear or 
not appear depending on the types of operations the user can perform on 
the object and any objects that may compose it.  So there is a potential 
for having several permissions checks when deciding to display a row in 
the list.  I know Acegi can cache permissions checks, but if there are 
10000 objects there's no way to be able to cache it all so there is 
likely going to be a significant performance hit.  The way I tried to 
mitigate that before was to basically say, if a user has role X then 
they have permissions Y on objects of type Z.  But because of the 
relationships between some of the objects it required writing some 
special case handling.

To be honest, at this point I'm not really sure how I'm going to handle 
permissions in this system.  Every way I try to approach the problem I 
wind up with a bad taste in my mouth because of inflexibility, 
performance and/or maintaince problems down the line.  Guess that's why 
I get the big bucks =P (if only heh)

Rich



Mime
View raw message