[Acegisecurity-developer] Unsubscribe me please
Unsubscribe me please --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
[Acegisecurity-developer] Acegi Container Adapte
Hello all, i have developed a webapp that uses acegi for authentication i am deploying my application on JBoss, and thus i am using the JBoss adapter developed by acegi because in my webapp, that uses strutsmenu, i wanted certain menu options to be disabled for users that don't have enough rights.. So i'll need to get the proper UserInrole, and for that reason i was suggested to use a container adapter somewhere in the acegi admin guide, if i remember correctly, it is mentioned that using adapter isnot a good approach... anyone could suggest me then what could be a good approach if i plan to deploy my application in different application servers? thanks in advance and regards marco
Re: [Acegisecurity-developer] Acegi Container Adapte
Marco, You're right to be very careful about coupling yourself to a server based on the needs of a presentation-tier tool. How about discarding Struts menu and using Acegi's tags instead? Scott Quoting Marco Mistroni <[EMAIL PROTECTED]>: Hello all, i have developed a webapp that uses acegi for authentication i am deploying my application on JBoss, and thus i am using the JBoss adapter developed by acegi because in my webapp, that uses strutsmenu, i wanted certain menu options to be disabled for users that don't have enough rights.. So i'll need to get the proper UserInrole, and for that reason i was suggested to use a container adapter somewhere in the acegi admin guide, if i remember correctly, it is mentioned that using adapter isnot a good approach... anyone could suggest me then what could be a good approach if i plan to deploy my application in different application servers? thanks in advance and regards marco --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=click ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
[Acegisecurity-developer] Proposal: Rename AuthenticationDao interface
Hi all, I chatted with Ben briefly about this last night and he suggested I bring it up on the list for others to chime in... I'd like to propose renaming the AuthenticationDao interface to AuthenticationService prior to 1.0.0. Why? It's ultimately just a naming thing, but my feelings are that Acegi shouldn't delegate authentication to an interface that encourages developers to bypass the business service layer and go straight for the data access layer. And generally, an application's DAOs shouldn't be executing business logic (like role construction) or tapping multiple DB connections, web services and other potential authentication & authorization stores. For example, the app I'm currently working on needs to reference three different DAOs during authentication to build the user's ultimate list of roles. Clearly this multiple-datasource operation needs to occur within the boundaries of a distributed transaction, so I did just that by building an AuthenticationServiceImpl that implements AuthenticationDao. This is all well and good, but when I first approached this problem I had to get over the fact that my *service* needed to implement a *dao* interface. This may not be so obvious to newcomers already in close combat with Acegi's sophisticated terminology and design. The downside of changing AuthenticationDao to AuthenticationService (sorry, "AuthenticationManager" may be consistent with Spring's nomenclature but it's already taken) is that a lot of API code, documentation and example XML files will need to be changed. Users will also have to do the same. Would it be worth it? I don't really know, but the argument could be made for making this change now, before 1.0.0 is out, since it's such a core part of Acegi's API. I also believe that it will make the class heirarchy easier to understand and explain, which I think is a challenge that Acegi already faces. I'd be willing to make these changes - Eclipse can easily handle the renaming and dependancy changes, and updating the JavaDoc, reference guide, XML files, etc. is mostly just search-and-replace and validation. But I want to know what everyone thinks first. Thanks, Scott --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Proposal: Rename AuthenticationDao interface
Hi Scott, From my perspective, I always saw the AuthenticationDao as just that... a pluggable interface for authentication data access (i.e. in-memory, jdbc, ldap, etc.) I personally dont see this interface at a Service Layer level? The AuthenticationProvider err.. provides a layer ontop of the actual authenticatonDao, so maybe I am missing something. I am all for refactoring / renaming, however I would be a little careful since 0.8.3 to 0.9 was a little API change for Acegi users... albeit minor changes. I would think that renaming the AuthenticationDao would be less of a change, compared to the ContextHolder changes. I think the API needs to stabilize... its less shocking for users :) I do kinda see what you mean Scott... having a service layer implement a DAO... normally doesnt sit well with developers ;) Although I am not sure if your situation is common (3 authentication dao's to build up the user's roles?) Just curious why? So if its a vote... mine would be 'no' ** Although I do like that we are all trying to keep the code clean and concise. Good stuff. Cheers, Mark On 11/15/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Hi all, I chatted with Ben briefly about this last night and he suggested Ibring it up on the list for others to chime in... I'd like to propose renaming the AuthenticationDao interface toAuthenticationService prior to 1.0.0. Why? It's ultimately just a naming thing, but my feelings are thatAcegi shouldn't delegate authentication to an interface that encourages developers to bypass the business service layer and go straight for the dataaccess layer. And generally, an application's DAOs shouldn't be executingbusiness logic (like role construction) or tapping multiple DB connections, web services and other potential authentication & authorization stores. For example, the app I'm currently working on needs to referencethree different DAOs during authentication to build the user's ultimate list of roles. Clearly this multiple-datasource operation needs to occur withinthe boundaries of a distributed transaction, so I did just that by buildingan AuthenticationServiceImpl that implements AuthenticationDao. This is all well and good, but when I first approached this problem I had to get overthe fact that my *service* needed to implement a *dao* interface. This maynot be so obvious to newcomers already in close combat with Acegi's sophisticated terminology and design. The downside of changing AuthenticationDao to AuthenticationService(sorry, "AuthenticationManager" may be consistent with Spring's nomenclaturebut it's already taken) is that a lot of API code, documentation and example XML files will need to be changed. Users will also have to do the same. Would it be worth it? I don't really know, but the argument couldbe made for making this change now, before 1.0.0 is out, since it's such a core part of Acegi's API. I also believe that it will make the classheirarchy easier to understand and explain, which I think is a challengethat Acegi already faces. I'd be willing to make these changes - Eclipse can easily handle the renaming and dependancy changes, and updating the JavaDoc, reference guide,XML files, etc. is mostly just search-and-replace and validation. But Iwant to know what everyone thinks first. Thanks, Scott---This SF.Net email is sponsored by the JBoss Inc. Get Certified TodayRegister for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit:http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___Home: http://acegisecurity.orgAcegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
RE: [Acegisecurity-developer] Proposal: Rename AuthenticationDao interface
> -Original Message- > From: Mark St.Godard [mailto:[EMAIL PROTECTED] > ... > The AuthenticationProvider err.. provides a layer ontop of > the actual authenticatonDao, so maybe I am missing something. Hi Mark! Hmmm, it could be me that's been missing it. In my case where I need to hit several DBs, it sounds like I should have instead turned my AuthenticationServiceImpl into AuthenticationProviderImpl (implementing AuthenticationProvider) and get away from Acegi's DaoAuthenticationProvider & AuthenticationDao interfaces altogether. Am I close? To answer your curiosity, our first data source is a reference DB for a user's identity, like whether they're active or terminated, an employee or non-employee, if they're hourly or exempt from overtime, etc. The second DB contains a person's access roles that make sense to couple with the lifecycle of DB #2's records. The third DB contains area management responsibilities and the app's audit log (which we insert into upon every authentication event). A fourth DB will be connected soon that is our fingerprint and background check reference DB. Who knows how many more we may add in the future... :-) Scott --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
