Setting up security biz rules in the managers makes a lot of sense. Thanks for the perspective. This would be a great sample for the 2.0 wiki.
regards, Jason melinate wrote: > > Hello All, > > I have a slightly different take on this topic... > > I like the URL based security as much as I like client side validation. > It is convenient, but not trustworthy. In an application where users of > different permission levels [roles] access the same pages, it is generally > very difficult to plug every security hole based on URL authorization. > > Acegi's ACL has recently been re-written [see: > http://acegisecurity.org/docbook/acegi.html#after-invocation-acl-aware ]. > So I'm not sure if the scaling problems that existed before still apply, > but I know there at least used to be problems when the number of objects > being controlled got into the ten thousands range. ACL can also be very > complicated and is often overkill for most [not all!] applications. > > The approach I advocate is to secure the managers. The managers have > defined points of entry [methods] so it is easier to lock them down. Also > managers can be exposed in a number of ways--presentation layer(s), AJAX > [DWR typically calls the managers], services [XFire]. If you secure the > manager you only have to worry about getting your security right once. > AppFuse puts security on the UserManager for example [in addition to URL > security]. Another method to do the same thing was detailed for AppFuse > 1.x here: > > http://raibledesigns.com/wiki/Wiki.jsp?page=AppFuseSecurityMethods > > I haven't had the need/time to apply this method to AppFuse 2.x yet, but I > still think it is a good approach for many applications. > > Hope that helps, > Nathan > > > > > ----- Original Message ----- > From: "thrasher" <[EMAIL PROTECTED]> > To: [email protected] > Sent: Tuesday, May 29, 2007 3:16:19 AM (GMT-0800) America/Los_Angeles > Subject: Re: [appfuse-user] Table Record Security in S2 > > > I used a Struts interceptor to do the same. > > I've got a similar security constraint, but I want to apply it at the URL > level. I started with an Acegi solution, but scrapped it because Acegi's > normal security mechanism (as implemented in AppFuse) doesn't have access > to > the URL information, so there was no way to see what page was being > accessed > via Acegi. I also wanted to send the user to a specific page if they were > not allowed to access the page. > > Per your database ID security-constraint, my logged in user would access a > url like: > http://myserver/somePage.html?id=1 > > and I want to make sure that the currently logged in user has permissions > to > access id=1 before rendering the page. > > I used a Struts interceptor, since the security was a function of the > currently logged in user, and the URL id. I figure that Struts is meant > to > deal with request level stuff, so this is the right place for security > checking like this. AppFuse has sample code if you check the struts.xml > file for: > <interceptor name="adminOnly" class="adminInterceptor"/> > And check the java sources out. > > I'd be curious to hear how an ACL solution turns out. > > -Jason > > > > Michael Horwitz wrote: >> >> Acegi can handle this kind of security using Access Control Lists (ACL). >> See >> http://www.acegisecurity.org/docbook/acegi.html#domain-acls. >> >> Mike >> On 5/27/07, Ömer Başar <[EMAIL PROTECTED]> wrote: >> >>> >>> Hi all, >>> >>> Lets think about two records with ids 1 and 2. One user has the >>> permission >>> only to view record with id 1 and another user can only view record with >>> id=2. Here is the question - How do you manage this type of security? Is >>> this type of security can be defined with acegi? >>> >>> Thanks. >>> -- >>> View this message in context: >>> http://www.nabble.com/Table-Record-Security-in-S2-tf3825144s2369.html#a10828854 >>> Sent from the AppFuse - User mailing list archive at Nabble.com. >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> > > -- > View this message in context: > http://www.nabble.com/Table-Record-Security-in-S2-tf3825144s2369.html#a10851276 > Sent from the AppFuse - User mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Table-Record-Security-in-S2-tf3825144s2369.html#a10867473 Sent from the AppFuse - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
