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]
