Re: [OT] Authorization and Authentication Question
HiThanks for the suggestion, this application which i need to do this is developed using Struts 1.2.6, can i add Spring Security to this, just as a drop in, is there any how to documents to add spring support to struts web application Ashish On Tue, Mar 10, 2009 at 7:43 PM, Jim Kiley jhki...@summa-tech.com wrote: I'd agree. Have your UserDetailsService implementation hit LDAP for authentication, and pass GrantedAuthorities[] on to the returned object by asking DB2 about that info if the user is authenticated. jk On Tue, Mar 10, 2009 at 6:44 PM, Wes Wannemacher w...@wantii.com wrote: On Tuesday 10 March 2009 17:56:30 Ashish Kulkarni wrote: HiIs it possible to Authenticate user using LDAP, but authorize using a DB2 database, I have situation where i need to authenticate and authorize some web pages. I want to authenticate users against LDAP, but have to maintain authorization list, roles etc in DB2 database Has anyone done anything like this before, i am using Weblogic and tomcat application servers I would suggest using Spring Security. I think what you'll need to do is create a bean that implements the org.springframework.security.userdetails.UserDetailsService interface, then wire it into your configuration. -- Wes Wannemacher Author - Struts 2 In Practice Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more http://www.manning.com/wannemacher - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org -- Jim Kiley Technical Consultant | Summa [p] 412.258.3346 [m] 412.445.1729 http://www.summa-tech.com
Re: [OT] Authorization and Authentication Question
Spring Security is it's own filter, and my experience is that it is pretty easy to integrate with just about any type of web-app. As far as existing tutorials, I'd say to check google. -Wes On Wed, Mar 11, 2009 at 9:52 AM, Ashish Kulkarni ashish.kulkarn...@gmail.com wrote: HiThanks for the suggestion, this application which i need to do this is developed using Struts 1.2.6, can i add Spring Security to this, just as a drop in, is there any how to documents to add spring support to struts web application Ashish On Tue, Mar 10, 2009 at 7:43 PM, Jim Kiley jhki...@summa-tech.com wrote: -- Wes Wannemacher Author - Struts 2 In Practice Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more http://www.manning.com/wannemacher - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
RE: [OT] Authorization and Authentication Question
I got it working in less than a day using the docs. The petshop tutorial page got me going. -Original Message- From: Ashish Kulkarni [mailto:ashish.kulkarn...@gmail.com] Sent: Wednesday, March 11, 2009 9:53 AM To: Struts Users Mailing List Subject: Re: [OT] Authorization and Authentication Question HiThanks for the suggestion, this application which i need to do this is developed using Struts 1.2.6, can i add Spring Security to this, just as a drop in, is there any how to documents to add spring support to struts web application Ashish On Tue, Mar 10, 2009 at 7:43 PM, Jim Kiley jhki...@summa-tech.com wrote: I'd agree. Have your UserDetailsService implementation hit LDAP for authentication, and pass GrantedAuthorities[] on to the returned object by asking DB2 about that info if the user is authenticated. jk On Tue, Mar 10, 2009 at 6:44 PM, Wes Wannemacher w...@wantii.com wrote: On Tuesday 10 March 2009 17:56:30 Ashish Kulkarni wrote: HiIs it possible to Authenticate user using LDAP, but authorize using a DB2 database, I have situation where i need to authenticate and authorize some web pages. I want to authenticate users against LDAP, but have to maintain authorization list, roles etc in DB2 database Has anyone done anything like this before, i am using Weblogic and tomcat application servers I would suggest using Spring Security. I think what you'll need to do is create a bean that implements the org.springframework.security.userdetails.UserDetailsService interface, then wire it into your configuration. -- Wes Wannemacher Author - Struts 2 In Practice Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more http://www.manning.com/wannemacher - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org -- Jim Kiley Technical Consultant | Summa [p] 412.258.3346 [m] 412.445.1729 http://www.summa-tech.com - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: [OT] Authorization and Authentication Question
HiThanks for the help, i will check and get back to this mail with the results On Wed, Mar 11, 2009 at 10:11 AM, Security Management list-subscripti...@secmgmt.com wrote: I got it working in less than a day using the docs. The petshop tutorial page got me going. -Original Message- From: Ashish Kulkarni [mailto:ashish.kulkarn...@gmail.com] Sent: Wednesday, March 11, 2009 9:53 AM To: Struts Users Mailing List Subject: Re: [OT] Authorization and Authentication Question HiThanks for the suggestion, this application which i need to do this is developed using Struts 1.2.6, can i add Spring Security to this, just as a drop in, is there any how to documents to add spring support to struts web application Ashish On Tue, Mar 10, 2009 at 7:43 PM, Jim Kiley jhki...@summa-tech.com wrote: I'd agree. Have your UserDetailsService implementation hit LDAP for authentication, and pass GrantedAuthorities[] on to the returned object by asking DB2 about that info if the user is authenticated. jk On Tue, Mar 10, 2009 at 6:44 PM, Wes Wannemacher w...@wantii.com wrote: On Tuesday 10 March 2009 17:56:30 Ashish Kulkarni wrote: HiIs it possible to Authenticate user using LDAP, but authorize using a DB2 database, I have situation where i need to authenticate and authorize some web pages. I want to authenticate users against LDAP, but have to maintain authorization list, roles etc in DB2 database Has anyone done anything like this before, i am using Weblogic and tomcat application servers I would suggest using Spring Security. I think what you'll need to do is create a bean that implements the org.springframework.security.userdetails.UserDetailsService interface, then wire it into your configuration. -- Wes Wannemacher Author - Struts 2 In Practice Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more http://www.manning.com/wannemacher - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org -- Jim Kiley Technical Consultant | Summa [p] 412.258.3346 [m] 412.445.1729 http://www.summa-tech.com - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: [OT] Authorization and Authentication Question
HiI was able to configure LDAP to do authentication, but how do i use UserDetailsService, is there any example of how to use this and implement it in my project to get user and role from DB2 database On Wed, Mar 11, 2009 at 10:50 AM, Ashish Kulkarni ashish.kulkarn...@gmail.com wrote: HiThanks for the help, i will check and get back to this mail with the results On Wed, Mar 11, 2009 at 10:11 AM, Security Management list-subscripti...@secmgmt.com wrote: I got it working in less than a day using the docs. The petshop tutorial page got me going. -Original Message- From: Ashish Kulkarni [mailto:ashish.kulkarn...@gmail.com] Sent: Wednesday, March 11, 2009 9:53 AM To: Struts Users Mailing List Subject: Re: [OT] Authorization and Authentication Question HiThanks for the suggestion, this application which i need to do this is developed using Struts 1.2.6, can i add Spring Security to this, just as a drop in, is there any how to documents to add spring support to struts web application Ashish On Tue, Mar 10, 2009 at 7:43 PM, Jim Kiley jhki...@summa-tech.com wrote: I'd agree. Have your UserDetailsService implementation hit LDAP for authentication, and pass GrantedAuthorities[] on to the returned object by asking DB2 about that info if the user is authenticated. jk On Tue, Mar 10, 2009 at 6:44 PM, Wes Wannemacher w...@wantii.com wrote: On Tuesday 10 March 2009 17:56:30 Ashish Kulkarni wrote: HiIs it possible to Authenticate user using LDAP, but authorize using a DB2 database, I have situation where i need to authenticate and authorize some web pages. I want to authenticate users against LDAP, but have to maintain authorization list, roles etc in DB2 database Has anyone done anything like this before, i am using Weblogic and tomcat application servers I would suggest using Spring Security. I think what you'll need to do is create a bean that implements the org.springframework.security.userdetails.UserDetailsService interface, then wire it into your configuration. -- Wes Wannemacher Author - Struts 2 In Practice Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more http://www.manning.com/wannemacher - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org -- Jim Kiley Technical Consultant | Summa [p] 412.258.3346 [m] 412.445.1729 http://www.summa-tech.com - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: [OT] Authorization and Authentication Question
On Wed, Mar 11, 2009 at 3:23 PM, Ashish Kulkarni ashish.kulkarn...@gmail.com wrote: HiI was able to configure LDAP to do authentication, but how do i use UserDetailsService, is there any example of how to use this and implement it in my project to get user and role from DB2 database UserDetailsService is an interface... You have to write an implementation. In your implementation, you can bounce the username / password against LDAP, then pull roles for the user out of DB2. Since Spring Security is open source, check the source for their LDAP implementation to see how to authorize against LDAP. As far as DB2 goes, since it is a database, you'll have to decide how you're going to talk to it (JPA, Hibernate, JDBC, iBatis, raw socket), then google for some examples. As for wiring your implementation, check the Spring docs. Past that, you may start to get flamed, this no longer has anything to do with Struts. -Wes -- Wes Wannemacher Author - Struts 2 In Practice Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more http://www.manning.com/wannemacher - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: [OT] Authorization and Authentication Question
2009/3/11 Ashish Kulkarni ashish.kulkarn...@gmail.com:
HiI was able to configure LDAP to do authentication, but how do i use
UserDetailsService,
is there any example of how to use this and implement it in my project to
get user and role from DB2 database
I did that like this, extended DefaultLdapAuthoritiesPopulator and
overrided getAdditionalRoles() method, in such case you can mix roles
from LDAP and from DB. In my case, access to applications was assigned
by LDAP group, but exact roles in application was specified in DB
public class LdapAuthoritiesPopulator extends DefaultLdapAuthoritiesPopulator {
private UserService userSvc;
public LdapAuthoritiesPopulator(InitialDirContextFactory
initialDirContextFactory, String groupSearchBase) {
super(initialDirContextFactory, groupSearchBase);
}
@Override
protected Set getAdditionalRoles(LdapUserDetails ldapUser) {
SetGrantedAuthority roles = new HashSetGrantedAuthority();
User user = userSvc.getUser(ldapUser.getUsername());
if(user != null) {
for (Role role : user.getRoles())
roles.add(new GrantedAuthorityImpl(role.getName()));
}
return roles;
}
public void setUserSvc(UserService userSvc) {
this.userSvc = userSvc;
}
}
applicationContext.xml (I've been using Acegi, but it should be the
same for Spring Security)
bean id=ldapAuthProvider
class=org.acegisecurity.providers.ldap.LdapAuthenticationProvider
constructor-arg
bean
class=org.acegisecurity.providers.ldap.authenticator.BindAuthenticator
constructor-arg
ref local=initialDirContextFactory /
/constructor-arg
property name=userSearch
ref local=userSearch /
/property
/bean
/constructor-arg
constructor-arg
bean class=com.company.LdapAuthoritiesPopulator !-- HERE IS
MY CLASS --
constructor-arg
ref local=initialDirContextFactory /
/constructor-arg
constructor-arg
valueOU=Company,OU=Access Control Groups,OU=Data/value
/constructor-arg
property name=convertToUpperCase
valuetrue/value
/property
property name=rolePrefix
value/value
/property
property name=searchSubtree
valuetrue/value
/property
property name=groupSearchFilter
valuemember={0}/value
/property
property name=groupRoleAttribute
valuecn/value
/property
property name=userSvc ref=userSvc/ !-- REFERENCE TO
USER SERVICE NEEDED TO ACCESS DB--
/bean
/constructor-arg
/bean
Regards
--
Lukasz
http://www.lenart.org.pl/
-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
[OT] Authorization and Authentication Question
HiIs it possible to Authenticate user using LDAP, but authorize using a DB2 database, I have situation where i need to authenticate and authorize some web pages. I want to authenticate users against LDAP, but have to maintain authorization list, roles etc in DB2 database Has anyone done anything like this before, i am using Weblogic and tomcat application servers Ash
Re: [OT] Authorization and Authentication Question
On Tuesday 10 March 2009 17:56:30 Ashish Kulkarni wrote: HiIs it possible to Authenticate user using LDAP, but authorize using a DB2 database, I have situation where i need to authenticate and authorize some web pages. I want to authenticate users against LDAP, but have to maintain authorization list, roles etc in DB2 database Has anyone done anything like this before, i am using Weblogic and tomcat application servers I would suggest using Spring Security. I think what you'll need to do is create a bean that implements the org.springframework.security.userdetails.UserDetailsService interface, then wire it into your configuration. -- Wes Wannemacher Author - Struts 2 In Practice Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more http://www.manning.com/wannemacher - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: [OT] Authorization and Authentication Question
I'd agree. Have your UserDetailsService implementation hit LDAP for authentication, and pass GrantedAuthorities[] on to the returned object by asking DB2 about that info if the user is authenticated. jk On Tue, Mar 10, 2009 at 6:44 PM, Wes Wannemacher w...@wantii.com wrote: On Tuesday 10 March 2009 17:56:30 Ashish Kulkarni wrote: HiIs it possible to Authenticate user using LDAP, but authorize using a DB2 database, I have situation where i need to authenticate and authorize some web pages. I want to authenticate users against LDAP, but have to maintain authorization list, roles etc in DB2 database Has anyone done anything like this before, i am using Weblogic and tomcat application servers I would suggest using Spring Security. I think what you'll need to do is create a bean that implements the org.springframework.security.userdetails.UserDetailsService interface, then wire it into your configuration. -- Wes Wannemacher Author - Struts 2 In Practice Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more http://www.manning.com/wannemacher - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org -- Jim Kiley Technical Consultant | Summa [p] 412.258.3346 [m] 412.445.1729 http://www.summa-tech.com
Re: authentication question
I have moved all JSP's under WEB-INF directory (e.g. /WEB-INF/pages/login.jsp), and this solution seems to work perfectly on my local environment with exploded directory structure. However, Struts seems to not be working at all when we package and deploy an ear file (before I moved the jsp's it had been working with ear deployment)...I am still troubleshooting, but any ideas what could be the issue here? Thanks John Jeromy Evans - Blue Sky Minds wrote: I've been told that some older containers don't allow you to forward to JSP's behind /WEB-INF. It wouldn't surprise me. Other than that I've found Ian's suggestion to be the most effective way to ensure users can't access JSPs directly, IMO a must for Tiles, html fragments and any page using struts tags. The only issue I've experienced is when (bad) scriptets within the JSP manipulate the request object directly, which is assumed to use the /xxx.jsp URI but is actually /WEB-INF/results/xxx.jsp. Many would argue that best practice is to not use JSPs at all. Another group would argue that Acegi should be used rather than rolling your own filter. Hope that helps. mojoRising wrote: Is this considered the Best Practice: Keeping all JSP's under the WEB-INF directory? We have not done that on my project, I am curious if there are plus' and minus' to this? Thanks, John The easiest way is to always have the user call an action to get a JSP, even if it is a simple page. You then also ensure that all data necessary for that page has been obtained. The, by placing the JSP's in the WEB-INF directory you will prevent access directly from a browser (only from the s2 dispatcher). -- View this message in context: http://www.nabble.com/authentication-question-tp16006710p16198339.html Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: authentication question
mojoRising wrote: Thanks. That's interesting. I am using Weblogic9.2, and I seem to have no problem using the request object in the jsp( for getParameter at least). I am wondering what type of request object manipulation, as you are referring to, may cause issues? I don't recall specifics any more, but it resulted in anchors like this: a href=/WEB-INF/anotherjsp.jsp instead of a href=/anotherjsp.jsp because of the way the path was constructed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: authentication question
Is this considered the Best Practice: Keeping all JSP's under the WEB-INF directory? We have not done that on my project, I am curious if there are plus' and minus' to this? Thanks, John The easiest way is to always have the user call an action to get a JSP, even if it is a simple page. You then also ensure that all data necessary for that page has been obtained. The, by placing the JSP's in the WEB-INF directory you will prevent access directly from a browser (only from the s2 dispatcher). Otherwise, I would suggest a servlet filter or header code for all JSPs that make the necessary checks. /Ian -- View this message in context: http://www.nabble.com/authentication-question-tp16006710p16121577.html Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: authentication question
I've been told that some older containers don't allow you to forward to JSP's behind /WEB-INF. It wouldn't surprise me. Other than that I've found Ian's suggestion to be the most effective way to ensure users can't access JSPs directly, IMO a must for Tiles, html fragments and any page using struts tags. The only issue I've experienced is when (bad) scriptets within the JSP manipulate the request object directly, which is assumed to use the /xxx.jsp URI but is actually /WEB-INF/results/xxx.jsp. Many would argue that best practice is to not use JSPs at all. Another group would argue that Acegi should be used rather than rolling your own filter. Hope that helps. mojoRising wrote: Is this considered the Best Practice: Keeping all JSP's under the WEB-INF directory? We have not done that on my project, I am curious if there are plus' and minus' to this? Thanks, John The easiest way is to always have the user call an action to get a JSP, even if it is a simple page. You then also ensure that all data necessary for that page has been obtained. The, by placing the JSP's in the WEB-INF directory you will prevent access directly from a browser (only from the s2 dispatcher). Otherwise, I would suggest a servlet filter or header code for all JSPs that make the necessary checks. /Ian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: authentication question
Plus: nothing under WEB-INF can be referenced by a browser, so JSPs stored there can't be called directly. Minus: nothing under WEB-INF can be referenced by a browser, so JSPs stored there can't be called directly... :-) It depends on your requirements. But generally you will want to route requests for all but the simplest of pages through an action. By placing the corresponding JSP under WEB-INF, you ensure it can never be accessed *except* through an action. L. mojoRising wrote: Is this considered the Best Practice: Keeping all JSP's under the WEB-INF directory? We have not done that on my project, I am curious if there are plus' and minus' to this? Thanks, John The easiest way is to always have the user call an action to get a JSP, even if it is a simple page. You then also ensure that all data necessary for that page has been obtained. The, by placing the JSP's in the WEB-INF directory you will prevent access directly from a browser (only from the s2 dispatcher). Otherwise, I would suggest a servlet filter or header code for all JSPs that make the necessary checks. /Ian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: authentication question
I use Acegi security to make sure that all of my pages are secure. I find it very flexiable, but not always easy to configure. If you are already using spring as you IoC, then you might as well take advantage of Acegi. Jeromy Evans wrote: I've been told that some older containers don't allow you to forward to JSP's behind /WEB-INF. It wouldn't surprise me. Other than that I've found Ian's suggestion to be the most effective way to ensure users can't access JSPs directly, IMO a must for Tiles, html fragments and any page using struts tags. The only issue I've experienced is when (bad) scriptets within the JSP manipulate the request object directly, which is assumed to use the /xxx.jsp URI but is actually /WEB-INF/results/xxx.jsp. Many would argue that best practice is to not use JSPs at all. Another group would argue that Acegi should be used rather than rolling your own filter. Hope that helps. mojoRising wrote: Is this considered the Best Practice: Keeping all JSP's under the WEB-INF directory? We have not done that on my project, I am curious if there are plus' and minus' to this? Thanks, John The easiest way is to always have the user call an action to get a JSP, even if it is a simple page. You then also ensure that all data necessary for that page has been obtained. The, by placing the JSP's in the WEB-INF directory you will prevent access directly from a browser (only from the s2 dispatcher). Otherwise, I would suggest a servlet filter or header code for all JSPs that make the necessary checks. /Ian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Spam/Virus scanning by CanIt Pro For more information see http://www.kgbinternet.com/SpamFilter.htm To control your spam filter, log in at http://filter.kgbinternet.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: authentication question
Thanks. That's interesting. I am using Weblogic9.2, and I seem to have no problem using the request object in the jsp( for getParameter at least). I am wondering what type of request object manipulation, as you are referring to, may cause issues? Jeromy Evans - Blue Sky Minds wrote: The only issue I've experienced is when (bad) scriptets within the JSP manipulate the request object directly, which is assumed to use the /xxx.jsp URI but is actually /WEB-INF/results/xxx.jsp. Many would argue that best practice is to not use JSPs at all. Another group would argue that Acegi should be used rather than rolling your own filter. Hope that helps. mojoRising wrote: Is this considered the Best Practice: Keeping all JSP's under the WEB-INF directory? We have not done that on my project, I am curious if there are plus' and minus' to this? Thanks, John The easiest way is to always have the user call an action to get a JSP, even if it is a simple page. You then also ensure that all data necessary for that page has been obtained. The, by placing the JSP's in the WEB-INF directory you will prevent access directly from a browser (only from the s2 dispatcher). Otherwise, I would suggest a servlet filter or header code for all JSPs that make the necessary checks. /Ian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/authentication-question-tp16006710p16123101.html Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
authentication question
struts 2 - java - jsp Hi. I am trying to configure an authentication/login interceptor. The idea being of course being to prevent someone from accessing a page unless they are logged in. We can assume that means they have a user object stored in the session. Now I understand how to plug in an interceptor to check for this, but what I am missing is: How do I prevent someone from accessing a jsp page if they DO NOT CALL an action, but type in the url themselves? E.g. If someone types in http://www.mysite.com/pages/main.jsp how do I intercept that? -- View this message in context: http://www.nabble.com/authentication-question-tp16006710p16006710.html Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: authentication question
The easiest way is to always have the user call an action to get a JSP, even if it is a simple page. You then also ensure that all data necessary for that page has been obtained. The, by placing the JSP's in the WEB-INF directory you will prevent access directly from a browser (only from the s2 dispatcher). Otherwise, I would suggest a servlet filter or header code for all JSPs that make the necessary checks. /Ian -- Ian Roughley From Down Around, Inc. Consulting * Training / Mentoring * Agile Process * Open Source web: http://www.fdar.com - email: [EMAIL PROTECTED] mojoRising wrote: struts 2 - java - jsp Hi. I am trying to configure an authentication/login interceptor. The idea being of course being to prevent someone from accessing a page unless they are logged in. We can assume that means they have a user object stored in the session. Now I understand how to plug in an interceptor to check for this, but what I am missing is: How do I prevent someone from accessing a jsp page if they DO NOT CALL an action, but type in the url themselves? E.g. If someone types in http://www.mysite.com/pages/main.jsp how do I intercept that? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: authentication question
The easiest way is to always have the user call an action to get a JSP, even if it is a simple page. You then also ensure that all data necessary for that page has been obtained. The, by placing the JSP's in the WEB-INF directory you will prevent access directly from a browser (only from the s2 dispatcher). Otherwise, I would suggest a servlet filter or header code for all JSPs that make the necessary checks. /Ian -- Ian Roughley From Down Around, Inc. Consulting * Training / Mentoring * Agile Process * Open Source web: http://www.fdar.com - email: [EMAIL PROTECTED] mojoRising wrote: struts 2 - java - jsp Hi. I am trying to configure an authentication/login interceptor. The idea being of course being to prevent someone from accessing a page unless they are logged in. We can assume that means they have a user object stored in the session. Now I understand how to plug in an interceptor to check for this, but what I am missing is: How do I prevent someone from accessing a jsp page if they DO NOT CALL an action, but type in the url themselves? E.g. If someone types in http://www.mysite.com/pages/main.jsp how do I intercept that? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts] JAAS and Struts Re-authentication Question
So I think I have it working and I didn't have to redirect the user, which is good because that wasn't working anyway. I don't know if it was JAAS or Struts, or what, but the login parameters were being stripped from the request so they never got to the login page. How I got it to work was this: I added a filter that looked for the login parameters on the request and if the login was different from the login of the currently authenticated user I retrieved the user's instance of their LoginModule (which I set on the user principal in the login() method in the LoginModule instance), called the logout method, which cleared the user's information from the session (though it's not exactly clear how), and then invalidate the session. For whatever reason, invalidating the session wasn't sufficient to actually invalidate the session. The user's information was still being persisted in the LoginModule instance so my guess is that when the user tried to log in as another user, it was still using the old user information bean. The result of this is that if user A is logged in and authenticated and this user attempts to log in as user B, we log out user A but since B's login parameters are lost, user B is dumped to the login page where they have to log in again. We can live with this for now since the only reason we're implementing this fix is to prevent our CSR's and sales team from accidentally forgetting to log out as one user and then try to log in as another and do something to the first user's account when they are thinking it's the second user's account. I think ultimately, the solution is going to be to not use JAAS and implement our own authentication solution since it's pretty clear that either we're not using JAAS correctly, or it's just not capable of doing what we need it to do. Thanks for all the feedback. --adam Dale Newfield wrote: Adam Gordon wrote: I think the solution is going to be to redirect the user to the default main page manually w/ the login parameters and JAAS should take over from there...hopefully. Except a redirect must be to a GET, not a POST, and it would be unfortunate to include the login credentials in a GET as they would then appear in history/logfiles... ...there's no way to do in code in your filter right where the problem case is detected the same stuff you do in a script on your login form page? -Dale - 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]
Re: [struts] JAAS and Struts Re-authentication Question
Adam Gordon wrote: I think the solution is going to be to redirect the user to the default main page manually w/ the login parameters and JAAS should take over from there...hopefully. Except a redirect must be to a GET, not a POST, and it would be unfortunate to include the login credentials in a GET as they would then appear in history/logfiles... ...there's no way to do in code in your filter right where the problem case is detected the same stuff you do in a script on your login form page? -Dale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts] JAAS and Struts Re-authentication Question
Let me get this straight: All pages in your webapp are protected (not available to non-logged in users), so when someone who is logged in on the company's main site tries to get to a page in your webapp, JAAS catches it and sends them to your webapp's login page, which might be able to glean enough details to log them in automagically and then redirect them to the originally requested page in your webapp. So you're relying on JAAS's restriction non-logged in users can't get to these pages to insert your webapp's login logic, but if the user *is* already logged in, there's noplace to catch this, so your webapp's login logic gets sidestepped. Correct. We do have some pages which are accessible by non-logged in users, but I don't believe that's relevant here. We have two security constraints: the first locks everything down and says the webapp is only accessible by users w/ the the role X (we only have one role and either you're in that role or your not) and the second opens up specific URIs to everyone (help docs, etc...). If a user is logged in as A and continues (using the site-wide login form) to log in as B, once in your webapp does request.getRemoteUser() return A or B? If it returns A then you have enough information to detect this case. We have a request listener set up in web.xml that is hit for every request. We use it to setup the user's navigation menus and stash some static account information on their session for easier accessibility. When user A logs in, for debugging, I'm printing out the full URL and it has user A's login parameters and the value of getRemoteUser() returns user A's username. With A's session still authenticated, I navigate back to our main website and log in as user B and the full URL contains user B's login parameters, but getRemoteUser() returns user A's username. Detecting the case wasn't the issue. We could also do this by looking for the account information on the session - if it's present the session is authenticated, if not, it's not. Since you know how to detect the login parameters from the request, you could put in an interceptor that checks if the login parameter is present, and if it differs from request.getRemoteUser() then you have just detected the problematic case. Invalidate the session and then JAAS will catch that the user is no longer logged in, which will trigger the display of your webapp's login page, which will result in correct behavior. This is the crux of the problem. In this request listener, I've placed code that looks for the case above, i.e., user B's login parameters but user A's authenticated session and in the case where B logs in over the top of A, I've invalidated the session. I believe what's happening is that JAAS correctly detects that the session is no longer authenticated and redirects the user to the login page. However, this creates 2 problems: 1) I already have the user's credentials and don't need the login form (which actually makes me think there's another issue as the login parameters aren't getting passed to that login form) and 2) when I try to log in via the form w/ B's credentials, I still get A's account. Looking at the logs, I can see the login() method from the LoginModule being called for B. I believe the wrong account problem is occurring because the logout() method is never being called on the LoginModule for user A. And as we've already discussed in this thread, there's not really any way to call the logout() method. I think the solution is going to be to redirect the user to the default main page manually w/ the login parameters and JAAS should take over from there...hopefully. Only, you can't redirect a request from a RequestListener so I'm going to see if I can set up a Filter since it has the required Response object to do the redirect. Thanks for all the info. If you have any other epiphanies please let me know and I'll let you know how this turns out. --adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts] JAAS and Struts Re-authentication Question
Yea, but in this case, it may be something we need to live with. The login page scriptlet code looks for the login credentials in the request and sets the appropriate form fields as well as a flag we use to indicate whether the form should be submitted immediately upon loading and in either case, it's a POST to j_security_check. I'm not sure I'll be able to even configure a filter for what we need to do. Am testing it now. We may need to forgo JAAS entirely and use an action servlet instead. --adam Dale Newfield wrote: Except a redirect must be to a GET, not a POST, and it would be unfortunate to include the login credentials in a GET as they would then appear in history/logfiles... ...there's no way to do in code in your filter right where the problem case is detected the same stuff you do in a script on your login form page? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts] JAAS and Struts Re-authentication Question
Laurie Harper wrote: If you have a separate 'login' page (as opposed to having a login form on each page) you might be able to get away with invalidating the session when that page is shown, with the caveat that logged in users would implicitly be logged out if they visit that page. And in the case where there's not a separate login page you could add an interceptor that's only in the stack of your login form, which invalidates the session. That way it's impossible for someone to get to the point where they'll be logging in while already logged in. -Dale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts] JAAS and Struts Re-authentication Question
I believe you are absolutely correct Laurie, because I've not yet seen a way to get a handle to the LoginContext to call logout(). All we can do is invalidate the session - which we do when the user logs out. This removes the user principal from the request and indicates to JAAS that the user is no longer authenticated meaning if they try to access a protected resource they are prompted to log in again. Additionally, while the core Request object has a setUserPrincipal(...) method, it is not exposed by the HttpServletRequest Interface (and nor by the Wrapper or Facade classes) so I can't even do it manually. For background, we actually have two login pages: on is the login page that is running inside our webapp that is running JAAS and POSTs to j_security_check at form submission time. The other page is our company's main website (Apache) and users can log in here too. What we do is perform a GET (either Struts or JAAS does not like doing POSTS w/ parameters - it strips them off) to the default protected resource inside our webapp. What I believe to happen is that JAAS detects that the requested URI is protected so it redirects the user to the login page. I have a large scriptlet block at the top of the JSP page which looks for the login parameters (from the main website page) and uses them to try and authenticate. If it fails, JAAS dumps the user back at the webapp login page with the appropriate error message. If it succeeds, the user is placed at the default (protected) webapp page (or whatever page they originally requested). All this works great and as designed. We have a LoginModule implementation that is called implicitly by JAAS to authenticate the user (the implementation ultimately uses database calls). The problem occurs when someone goes back to our main website and tries to log in again as user B when they are already authenticated as user A (i.e., they've not logged out). I believe JAAS takes a look at the request and says Ah! I see you're already authenticated and dumps the user back at the default webapp page but with user A's credentials, not user B. In this second case, the login page is never hit the second time which mean I can't check to see if the session is already authenticated and force a logout before logging in as the different user. In my perusing of JAAS on the web I found the following comment: Although it is possible to use JAAS within Tomcat as an authentication mechanism (JAASRealm), the flexibility of the JAAS framework is lost once the user is authenticated. This is because the principals are used to denote the concepts of user and role, and are no longer available in the security context in which the webapp is executed. The result of the authentication is available only through request.getRemoteUser() and request.isUserInRole(). Hope that was clear. --adam Laurie Harper wrote: I don't think Container Managed Security has provisions for logging users out, other than by expiring the session (and not even then if you're relying on HTTP authentication rather than form-based). If you have a separate 'login' page (as opposed to having a login form on each page) you might be able to get away with invalidating the session when that page is shown, with the caveat that logged in users would implicitly be logged out if they visit that page. Perhaps it would help to more fully describe the use case (i.e. 'user is logged in and tries to log in...' and how it is failing (i.e. 'user stays logged in as old user'), along with specific details of how you have authentication configured. L. Adam Gordon wrote: If you mean protecting the page w/ a security constraint, I think that would be a problem in that JAAS would detect that it's a protected resource and prompt the user to log in before hitting the login page and upon a successful login would redirect the user to the login page after they've already logged in. And even if I modified the login page to redirect to the default home page in the webapp, the problem is when they try logging in as someone else without logging out - JAAS/Tomcat detects that they are already logged in (have an authenticated session) and so would bypass any authentication mechanism. --adam Dale Newfield wrote: Adam Gordon wrote: We're using JAAS for webapp authentication and we've discovered an issue: If user A is logged in and tries to log in as user B, they stay logged in as user A. Couldn't you protect the login form page and action so that they're only accessible by a session without any valid login credentials? That way the only way to log in as B would be to first log out as A (or in some other way start a new session w/o A's credentials). -Dale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts] JAAS and Struts Re-authentication Question
See my comments in my response to Laurie. We're basically using dual login pages, one on our main website (Apache) and the other in our webapp. I'm currently toying with the idea of a Filter to detect the subsequent logins against an already authenticated session. --adam Dale Newfield wrote: Laurie Harper wrote: If you have a separate 'login' page (as opposed to having a login form on each page) you might be able to get away with invalidating the session when that page is shown, with the caveat that logged in users would implicitly be logged out if they visit that page. And in the case where there's not a separate login page you could add an interceptor that's only in the stack of your login form, which invalidates the session. That way it's impossible for someone to get to the point where they'll be logging in while already logged in. -Dale - 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]
Re: [struts] JAAS and Struts Re-authentication Question
Adam Gordon wrote: For background, we actually have two login pages: on is the login page that is running inside our webapp that is running JAAS and POSTs to j_security_check at form submission time. The other page is our company's main website (Apache) and users can log in here too. What we do is perform a GET (either Struts or JAAS does not like doing POSTS w/ parameters - it strips them off) to the default protected resource inside our webapp. What I believe to happen is that JAAS detects that the requested URI is protected so it redirects the user to the login page. I have a large scriptlet block at the top of the JSP page which looks for the login parameters (from the main website page) and uses them to try and authenticate. If it fails, JAAS dumps the user back at the webapp login page with the appropriate error message. If it succeeds, the user is placed at the default (protected) webapp page (or whatever page they originally requested). Let me get this straight: All pages in your webapp are protected (not available to non-logged in users), so when someone who is logged in on the company's main site tries to get to a page in your webapp, JAAS catches it and sends them to your webapp's login page, which might be able to glean enough details to log them in automagically and then redirect them to the originally requested page in your webapp. So you're relying on JAAS's restriction non-logged in users can't get to these pages to insert your webapp's login logic, but if the user *is* already logged in, there's noplace to catch this, so your webapp's login logic gets sidestepped. If a user is logged in as A and continues (using the site-wide login form) to log in as B, once in your webapp does request.getRemoteUser() return A or B? If it returns A then you have enough information to detect this case. Since you know how to detect the login parameters from the request, you could put in an interceptor that checks if the login parameter is present, and if it differs from request.getRemoteUser() then you have just detected the problematic case. Invalidate the session and then JAAS will catch that the user is no longer logged in, which will trigger the display of your webapp's login page, which will result in correct behavior. -Dale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts] JAAS and Struts Re-authentication Question
If you mean protecting the page w/ a security constraint, I think that would be a problem in that JAAS would detect that it's a protected resource and prompt the user to log in before hitting the login page and upon a successful login would redirect the user to the login page after they've already logged in. And even if I modified the login page to redirect to the default home page in the webapp, the problem is when they try logging in as someone else without logging out - JAAS/Tomcat detects that they are already logged in (have an authenticated session) and so would bypass any authentication mechanism. --adam Dale Newfield wrote: Adam Gordon wrote: We're using JAAS for webapp authentication and we've discovered an issue: If user A is logged in and tries to log in as user B, they stay logged in as user A. Couldn't you protect the login form page and action so that they're only accessible by a session without any valid login credentials? That way the only way to log in as B would be to first log out as A (or in some other way start a new session w/o A's credentials). -Dale - 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]
Re: [struts] JAAS and Struts Re-authentication Question
I don't think Container Managed Security has provisions for logging users out, other than by expiring the session (and not even then if you're relying on HTTP authentication rather than form-based). If you have a separate 'login' page (as opposed to having a login form on each page) you might be able to get away with invalidating the session when that page is shown, with the caveat that logged in users would implicitly be logged out if they visit that page. Perhaps it would help to more fully describe the use case (i.e. 'user is logged in and tries to log in...' and how it is failing (i.e. 'user stays logged in as old user'), along with specific details of how you have authentication configured. L. Adam Gordon wrote: If you mean protecting the page w/ a security constraint, I think that would be a problem in that JAAS would detect that it's a protected resource and prompt the user to log in before hitting the login page and upon a successful login would redirect the user to the login page after they've already logged in. And even if I modified the login page to redirect to the default home page in the webapp, the problem is when they try logging in as someone else without logging out - JAAS/Tomcat detects that they are already logged in (have an authenticated session) and so would bypass any authentication mechanism. --adam Dale Newfield wrote: Adam Gordon wrote: We're using JAAS for webapp authentication and we've discovered an issue: If user A is logged in and tries to log in as user B, they stay logged in as user A. Couldn't you protect the login form page and action so that they're only accessible by a session without any valid login credentials? That way the only way to log in as B would be to first log out as A (or in some other way start a new session w/o A's credentials). -Dale - 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]
JAAS and Struts Re-authentication Question
Hi- We're using JAAS for webapp authentication and we've discovered an issue: If user A is logged in and tries to log in as user B, they stay logged in as user A. We know how to detect if a user's already authenticated (we have some static objects stored on the session) but we're not sure where to put the code that would detect whether user A had an authenticated session and invalidate it before allowing them to log in as user B. I've tooled around with the LoginAction but am getting various Tomcat errors (invalid reference to login page, attempt to post to j_security_check and the servlet isn't available, etc...). Any ideas? --adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts] JAAS and Struts Re-authentication Question
Adam Gordon wrote: We're using JAAS for webapp authentication and we've discovered an issue: If user A is logged in and tries to log in as user B, they stay logged in as user A. Couldn't you protect the login form page and action so that they're only accessible by a session without any valid login credentials? That way the only way to log in as B would be to first log out as A (or in some other way start a new session w/o A's credentials). -Dale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
tomcat 5.5 authentication question
I'm very new to struts (and java for that matter) so my question might be stupid but here goes: I have an application that is based on companies and employees. Each employee may have a single company. Also each employee has a user (which is used by tomcat for authentication/authorization) and i want to set some session values after a login (like current company and current employee). Since I can't intercept the login form (which goes to j_security_check) where should i put the code for setting those session values? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] tomcat 5.5 authentication question
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eugen,
Eugen Stoianovici wrote:
Since I can't intercept the login form (which goes to j_security_check)
where should i put the code for setting those session values?
Ah, but you can intercept it!
You just need to think outside the container. Or, inside, rather. Use a
filter with logic like this:
public void doFilter(...)
{
Principal p = request.getPrincipal();
HttpSession session = request.getSession();
Object mySessionObj = session.getAttribute(my_session_key);
if(null != p null == mySessionObj)
{
// There is a Principal (valid login) who has not been set up.
// TODO: retrieve whatever objects you need to stick in
// the session.
mySessionObj = ...;
session.setAttribute(my_session_key, mySessionObj);
}
}
I myself use a filter like this, and it works just fine.
I hope that helps,
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGwdLj9CaO5/Lv0PARAtUKAJ49aG9OFCmlLfiwElOIqilRWgxLWACgmAph
QrsIbkd6e1CykySOfx+sfPQ=
=WzPF
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Authentication question
Hi everybody. I've just started working on an application using Struts. In my previous projects my actions that needed authentication always had some common class that they extended. Now I am wondering whether it would be feasible to authenticate using AOP - writing interceptors for each method. Any thoughts? Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Authentication question
Hi, I wouldn't do authentication via Aop and interceptors, but authorisation is perfectly feasible, that's what we do in our project using Spring and aop. Greetings Jimmy -Original Message- From: Tom Ziemer [mailto:[EMAIL PROTECTED] Sent: donderdag 7 april 2005 16:58 To: Struts Users Mailing List Subject: Authentication question Hi everybody. I've just started working on an application using Struts. In my previous projects my actions that needed authentication always had some common class that they extended. Now I am wondering whether it would be feasible to authenticate using AOP - writing interceptors for each method. Any thoughts? Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] STRICTLY PERSONAL AND CONFIDENTIAL This message may contain confidential and proprietary material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. Dit bericht is enkel bestemd voor de aangeduide ontvangers en kan vertrouwelijke informatie bevatten. Als u niet de ontvanger bent, dan mag u de inhoud van dit bericht niet bekendmaken noch kopiren. Als u dit bericht per vergissing ontvangen heeft, gelieve er de afzender of De Post onmiddellijk van op de hoogte te brengen en het bericht vervolgens te verwijderen. Ce message est uniquement destin aux destinitaires indiqus et peut contenir des informations confidentielles. Si vous n'tes pas le destinataire, vous ne devez pas rvler le contenu de ce message ou en prendre copie. Si vous avez reu ce message par erreur, veuillez en informer l'expditeur, ou La Poste immdiatement, avant de le supprimer.
RE: Authentication question
It is certainly possible, however your old methodology could just as
easily be used by creating a baseAction class and then extending that
class. {
Al
-Original Message-
From: Tom Ziemer [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 07, 2005 9:58 AM
To: Struts Users Mailing List
Subject: Authentication question
Hi everybody.
I've just started working on an application using Struts. In my previous
projects my actions that needed authentication always had some common
class that they extended. Now I am wondering whether it would be
feasible to authenticate using AOP - writing interceptors for each
method.
Any thoughts?
Tom
-
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]
Re: Authentication question
Hi, thanks for the input - I actually meant authorisation and not authentication. I'll give it a try. Tom VAN BROECK Jimmy wrote: Hi, I wouldn't do authentication via Aop and interceptors, but authorisation is perfectly feasible, that's what we do in our project using Spring and aop. Greetings Jimmy -Original Message- From: Tom Ziemer [mailto:[EMAIL PROTECTED] Sent: donderdag 7 april 2005 16:58 To: Struts Users Mailing List Subject: Authentication question Hi everybody. I've just started working on an application using Struts. In my previous projects my actions that needed authentication always had some common class that they extended. Now I am wondering whether it would be feasible to authenticate using AOP - writing interceptors for each method. Any thoughts? Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] STRICTLY PERSONAL AND CONFIDENTIAL This message may contain confidential and proprietary material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. Dit bericht is enkel bestemd voor de aangeduide ontvangers en kan vertrouwelijke informatie bevatten. Als u niet de ontvanger bent, dan mag u de inhoud van dit bericht niet bekendmaken noch kopiren. Als u dit bericht per vergissing ontvangen heeft, gelieve er de afzender of De Post onmiddellijk van op de hoogte te brengen en het bericht vervolgens te verwijderen. Ce message est uniquement destin aux destinitaires indiqus et peut contenir des informations confidentielles. Si vous n'tes pas le destinataire, vous ne devez pas rvler le contenu de ce message ou en prendre copie. Si vous avez reu ce message par erreur, veuillez en informer l'expditeur, ou La Poste immdiatement, avant de le supprimer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Container Managed authentication question
hi Using container managed authentication, can i relay request parameters(i.e. username password) to loginAction after successful authentication? Because I want to construct a User bean and add it to Session after successful authentication but request parameters seem to get lost. Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Container Managed authentication question
struts Dude wrote: hi Using container managed authentication, can i relay request parameters(i.e. username password) to loginAction after successful authentication? Because I want to construct a User bean and add it to Session after successful authentication but request parameters seem to get lost. Thanks You can get the user's name using request.getUserPrincipal().getName(); however, for security reasons, you cannot get the user's password. If you must have the password, then you may need to use application-managed security (or SecurityFilter). Bill Siggelkow - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
