[Acegisecurity-developer] Re: CasAuthenticationProvider taking advantage
> Hi Mike > > Just checked into CVS HEAD option one. Please let me know if further > changes are required, or if this meets you needs. > > Best regards > Ben Work great. Thanks Ben. --- [This E-mail scanned for viruses by Declude Virus] --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Newbie Questions...
[EMAIL PROTECTED] wrote: Ben, You were right. It was a problem with my securityEnforcementFilter bean configuration. I see it now. Once I changed to the basicProcessingFilterEntryPoint bean reference it worked. I also needed your great explaination about SOAP authorization. I will be giving a presentation about Spring at AJUG (Atlanta User Group) next Tuesday. I will definitely mention this security plugin for Spring. My next challenge will be to get SSL Basic authentication configured with Acegi. Thank you so much for your attention about this problem. Mark Hi Mark Pleased it was resolved. With your next challenge, do you meaning using BASIC authentication over HTTPS? If so, there's no reason it shouldn't simply work by using https:// as the target URL rather than http://. Best regards Ben --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Newbie Questions...
Ben, You were right. It was a problem with my securityEnforcementFilter bean configuration. I see it now. Once I changed to the basicProcessingFilterEntryPoint bean reference it worked. I also needed your great explaination about SOAP authorization. I will be giving a presentation about Spring at AJUG (Atlanta User Group) next Tuesday. I will definitely mention this security plugin for Spring. My next challenge will be to get SSL Basic authentication configured with Acegi. Thank you so much for your attention about this problem. Mark > [EMAIL PROTECTED] wrote: > >>Ben, >> >>I had to force Basic authentication by modifying the >> BasicProcessingFilter >>class so that the doFilter method sets the header field is set to "Basic >> " >>if header is null. I know this is ugly, but the SOAP client (Flash >>component) is not sending this value when the request is made. I do not >>understand this. >> >>Anyways, here is what I had to code to force this to happen. If you know >>a better way then I would like to know about it. I think that the Flash >>client is not setting this header field correctly to indicate that it is >>Basic auth, but I am not sure. If I do not use this code then a >>subsequent Acegi filter will try to redirect to a login page. Please >>advise. >> >> >> >> > Mark > > What is supposed to happen is: > > 1. SOAP request received, and attempted to be executed. > 2. MethodSecurityInterceptor throws AuthenticationException. > 3. Wrapping SecurityEnforcementFilter detects AuthenticationException > and calls AuthenticationEntryPoint (which must be > BasicProcessingFilterEntryPoint). > 4. BasicProcessingFilterEntryPoint responds with a challenge like this: > WWW-Authenticate: Basic realm="WallyWorld" > 5. SOAP client reads challenge, and retries request but this time with a > header like this: Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== > 6. SOAP request received, and attempted to be executed. > 7. BasicProcessingFilter detects header and attempts authentication, > placing successful Authentication into the HttpSession. > 8. AutoIntegrationFilter grabs Authentication from HttpSession and onto > ContextHolder. > 9. MethodSecurityInterceptor successful this time, as an Authentication > object on ContextHolder. > > Your code change seems to suggest to me your SecurityEnforcementFilter > isn't configured properly. It seems as if your BasicProcessingFilter is > being used to simulate an attempted authentication, which will cause > BasicProcessingFilter to launch BasicProcessingFilterEntryPoint right > away (it's designed to do this, as the user might have presented invalid > credentials, so they're given a chance to try again). Would you mind > copying your application context XML into an email showing the > configuration of the security objects? It should look something like this: > > class="net.sf.acegisecurity.intercept.web.SecurityEnforcementFilter"> > bean="filterInvocationInterceptor"/> > bean="basicProcessingFilterEntryPoint"/> <-- NB this > line ---> > > > class="net.sf.acegisecurity.ui.basicauth.BasicProcessingFilter"> > bean="authenticationManager"/> > bean="basicProcessingFilterEntryPoint"/> > > > class="net.sf.acegisecurity.ui.basicauth.BasicProcessingFilterEntryPoint"> > My Company's > Realm > > > Thanks > Ben > > > > --- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > ___ > Acegisecurity-developer mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer > --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Newbie Questions...
[EMAIL PROTECTED] wrote: Ben, I had to force Basic authentication by modifying the BasicProcessingFilter class so that the doFilter method sets the header field is set to "Basic " if header is null. I know this is ugly, but the SOAP client (Flash component) is not sending this value when the request is made. I do not understand this. Anyways, here is what I had to code to force this to happen. If you know a better way then I would like to know about it. I think that the Flash client is not setting this header field correctly to indicate that it is Basic auth, but I am not sure. If I do not use this code then a subsequent Acegi filter will try to redirect to a login page. Please advise. Mark What is supposed to happen is: 1. SOAP request received, and attempted to be executed. 2. MethodSecurityInterceptor throws AuthenticationException. 3. Wrapping SecurityEnforcementFilter detects AuthenticationException and calls AuthenticationEntryPoint (which must be BasicProcessingFilterEntryPoint). 4. BasicProcessingFilterEntryPoint responds with a challenge like this: WWW-Authenticate: Basic realm="WallyWorld" 5. SOAP client reads challenge, and retries request but this time with a header like this: Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== 6. SOAP request received, and attempted to be executed. 7. BasicProcessingFilter detects header and attempts authentication, placing successful Authentication into the HttpSession. 8. AutoIntegrationFilter grabs Authentication from HttpSession and onto ContextHolder. 9. MethodSecurityInterceptor successful this time, as an Authentication object on ContextHolder. Your code change seems to suggest to me your SecurityEnforcementFilter isn't configured properly. It seems as if your BasicProcessingFilter is being used to simulate an attempted authentication, which will cause BasicProcessingFilter to launch BasicProcessingFilterEntryPoint right away (it's designed to do this, as the user might have presented invalid credentials, so they're given a chance to try again). Would you mind copying your application context XML into an email showing the configuration of the security objects? It should look something like this: <-- NB this line ---> My Company's Realm Thanks Ben --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Followup: Why am I getting extra requests with Sitemesh?
Travis wrote: Patrick and Ben, This patch fixed the BEA issues I had with my application as well as the sample contacts application. Thanks! Travis Travis, I'm pleased this fixed your problem. Patrick, thanks very much for your patch and help. I've applied it to CVS HEAD. Thanks again Ben --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
RE: Re: [Acegisecurity-developer] Followup: Why am I getting extra requests with Sitemesh?
Patrick and Ben, This patch fixed the BEA issues I had with my application as well as the sample contacts application. Thanks! Travis -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Patrick Burleson Sent: Thursday, July 15, 2004 10:00 AM To: [EMAIL PROTECTED] Subject: Re: Re: [Acegisecurity-developer] Followup: Why am I getting extra requests with Sitemesh? On Thu, 15 Jul 2004 15:49:56 +1000, Ben Alex <[EMAIL PROTECTED]> wrote: > > Hi Patrick > > Thanks for the info. > > People should only be running one AbstractIntegrationFilter subclass, > although they might run more than one processing filter, such as > BasicProcessingFilter and AuthenticationProcessingFilter (for form-based > authentication) in the same web application. > > If you wouldn't mind submitting a patch, I'd be happy to apply it to > CVS. I'd write it myself, but don't have access to Weblogic to give it a > full test. > > Best regards > Ben Ben, Ok, I've got it fixed I think. It passes all the Junit Tests (you'll see that I had to add in a check for request != null since some of the tests pass in a null request) and my app now works as expected. Attached is the patch. I borrrowed the idea from the WebWork project (including the Variable name ) and wanted to give them full credit. Let me know if this isn't going to work or if it needs adjustments. As a side note, as a developer, you can get a 1 year free use of Weblogic just by downloading the server. That's how I'm able to test on it. Thanks, Patrick --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Newbie Questions...
Ben,
I am still having troubles getting messages to the developer list. My
messages keep bouncing back. Hopefully, you can put this into the list.
However...
I had to force Basic authentication by modifying the BasicProcessingFilter
class so that the doFilter method sets the header field is set to "Basic "
if header is null. I know this is ugly, but the SOAP client (Flash
component) is not sending this value when the request is made. I do not
understand this.
Anyways, here is what I had to code to force this to happen. If you know
a better way then I would like to know about it. I think that the Flash
client is not setting this header field correctly to indicate that it is
Basic auth, but I am not sure. If I do not use this code then a
subsequent Acegi filter will try to redirect to a login page. Please
advise.
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain)
throws IOException, ServletException {
if (!(request instanceof HttpServletRequest)) {
throw new ServletException("Can only process
HttpServletRequest");
}
if (!(response instanceof HttpServletResponse)) {
throw new ServletException("Can only process
HttpServletResponse");
}
HttpServletRequest httpRequest = (HttpServletRequest) request;
HttpServletResponse httpResponse = (HttpServletResponse) response;
String header = httpRequest.getHeader("Authorization");
if (logger.isDebugEnabled()) {
logger.debug("Authorization header: " + header);
}
// ADDED CODE START - YUCK
//if ((header != null) && header.startsWith("Basic ")) {
if(header == null){
header = "Basic ";
}
// ADDED CODE END - YUCK
String base64Token = header.substring(6);
String token = new
String(Base64.decodeBase64(base64Token.getBytes()));
String username = "";
String password = "";
int delim = token.indexOf(":");
if (delim != -1) {
username = token.substring(0, delim);
password = token.substring(delim + 1);
}
UsernamePasswordAuthenticationToken authRequest = new
UsernamePasswordAuthenticationToken(username,
password);
authRequest.setDetails(httpRequest.getRemoteAddr());
Authentication authResult;
try {
authResult = authenticationManager.authenticate(authRequest);
} catch (AuthenticationException failed) {
// Authentication failed
if (logger.isDebugEnabled()) {
logger
.debug("Authentication request for user: " +
username + " failed: "
+ failed.toString());
}
authenticationEntryPoint.commence(request, response);
return;
}
// Authentication success
if (logger.isDebugEnabled()) {
logger.debug("Authentication success: " + authResult.toString());
}
httpRequest.getSession().setAttribute(HttpSessionIntegrationFilter.ACEGI_SECURITY_AUTHENTICATION_KEY,
authResult);
// if }
chain.doFilter(request, response);
}
Thanks,
Mark Eagle
> [EMAIL PROTECTED] wrote:
>
>>First, thanks to Ben for helping me understand some of the Acegi
>> internals.
>>My question revolves around using BASIC authentication with Acegi.
>> First,
>>let me start by stating that I am not using HTML. I am using Flex which
>>uses a Flash client with SOAP requests. What I want to know is if I use
>>BASIC authentication will Acegi still be able to use the notion of a
>>ContextHolder to store authentication credentials such as roles? I want
>> to
>>use the roles for my Spring managed business objects of course.
>>Furthermore, is there a filter that I should be using that will not
>>redirect to a page if authentication fails? Instead of the filter
>>redirecting to a JSP, or other page, I would like to just send a
>>response.sendError(HttpServlet.SC_UNAUTHORIZED) back to the client.
>> Should
>>I just write my own filter that is similar to the BasicProcessingFilter
>> and
>>append it in the chain of filters? The Flash client is expecting a 401
>>HTTP error to notice a Client.Authentication fault/exception. The
>> current
>>filter tries to redirect to the custom login form which does not apply in
>>my context.
>>
>>
>>
> Hi Mark
>
> The normal approach to BASIC authentication is to use
> SecurityEnforcementFilter, which detects any Acegi Security related
> exceptions. If the user is not logged in, the AuthenticationEntryPoint
> implementation will be called, which is usually
> BasicProcessingFilterEntryPoint in this case. If the user is logged in,
> a straight 403 (access denied) will be thrown.
> BasicProcessingFilterEntryPoint will throw a 401 (unauthorised) which
> will cause the calling browser to attempt login.
>
> Whilst Secu
Re: [Acegisecurity-developer] Newbie Questions...
Ben,
I had to force Basic authentication by modifying the BasicProcessingFilter
class so that the doFilter method sets the header field is set to "Basic "
if header is null. I know this is ugly, but the SOAP client (Flash
component) is not sending this value when the request is made. I do not
understand this.
Anyways, here is what I had to code to force this to happen. If you know
a better way then I would like to know about it. I think that the Flash
client is not setting this header field correctly to indicate that it is
Basic auth, but I am not sure. If I do not use this code then a
subsequent Acegi filter will try to redirect to a login page. Please
advise.
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain)
throws IOException, ServletException {
if (!(request instanceof HttpServletRequest)) {
throw new ServletException("Can only process
HttpServletRequest");
}
if (!(response instanceof HttpServletResponse)) {
throw new ServletException("Can only process
HttpServletResponse");
}
HttpServletRequest httpRequest = (HttpServletRequest) request;
HttpServletResponse httpResponse = (HttpServletResponse) response;
String header = httpRequest.getHeader("Authorization");
if (logger.isDebugEnabled()) {
logger.debug("Authorization header: " + header);
}
// ADDED CODE START - YUCK
//if ((header != null) && header.startsWith("Basic ")) {
if(header == null){
header = "Basic ";
}
// ADDED CODE END - YUCK
String base64Token = header.substring(6);
String token = new
String(Base64.decodeBase64(base64Token.getBytes()));
String username = "";
String password = "";
int delim = token.indexOf(":");
if (delim != -1) {
username = token.substring(0, delim);
password = token.substring(delim + 1);
}
UsernamePasswordAuthenticationToken authRequest = new
UsernamePasswordAuthenticationToken(username,
password);
authRequest.setDetails(httpRequest.getRemoteAddr());
Authentication authResult;
try {
authResult = authenticationManager.authenticate(authRequest);
} catch (AuthenticationException failed) {
// Authentication failed
if (logger.isDebugEnabled()) {
logger
.debug("Authentication request for user: " +
username + " failed: "
+ failed.toString());
}
authenticationEntryPoint.commence(request, response);
return;
}
// Authentication success
if (logger.isDebugEnabled()) {
logger.debug("Authentication success: " + authResult.toString());
}
httpRequest.getSession().setAttribute(HttpSessionIntegrationFilter.ACEGI_SECURITY_AUTHENTICATION_KEY,
authResult);
// if }
chain.doFilter(request, response);
}
Thanks,
Mark Eagle
> [EMAIL PROTECTED] wrote:
>
>>First, thanks to Ben for helping me understand some of the Acegi
>> internals.
>>My question revolves around using BASIC authentication with Acegi.
>> First,
>>let me start by stating that I am not using HTML. I am using Flex which
>>uses a Flash client with SOAP requests. What I want to know is if I use
>>BASIC authentication will Acegi still be able to use the notion of a
>>ContextHolder to store authentication credentials such as roles? I want
>> to
>>use the roles for my Spring managed business objects of course.
>>Furthermore, is there a filter that I should be using that will not
>>redirect to a page if authentication fails? Instead of the filter
>>redirecting to a JSP, or other page, I would like to just send a
>>response.sendError(HttpServlet.SC_UNAUTHORIZED) back to the client.
>> Should
>>I just write my own filter that is similar to the BasicProcessingFilter
>> and
>>append it in the chain of filters? The Flash client is expecting a 401
>>HTTP error to notice a Client.Authentication fault/exception. The
>> current
>>filter tries to redirect to the custom login form which does not apply in
>>my context.
>>
>>
>>
> Hi Mark
>
> The normal approach to BASIC authentication is to use
> SecurityEnforcementFilter, which detects any Acegi Security related
> exceptions. If the user is not logged in, the AuthenticationEntryPoint
> implementation will be called, which is usually
> BasicProcessingFilterEntryPoint in this case. If the user is logged in,
> a straight 403 (access denied) will be thrown.
> BasicProcessingFilterEntryPoint will throw a 401 (unauthorised) which
> will cause the calling browser to attempt login.
>
> Whilst SecurityEnforcementFilter can provide HTTP URL security, you
> don't _have_ to use it for this. The main value in your case is it
> detects security exceptions t
Re: Re: [Acegisecurity-developer] Followup: Why am I getting extra requests with Sitemesh?
On Thu, 15 Jul 2004 15:49:56 +1000, Ben Alex <[EMAIL PROTECTED]> wrote: > > Hi Patrick > > Thanks for the info. > > People should only be running one AbstractIntegrationFilter subclass, > although they might run more than one processing filter, such as > BasicProcessingFilter and AuthenticationProcessingFilter (for form-based > authentication) in the same web application. > > If you wouldn't mind submitting a patch, I'd be happy to apply it to > CVS. I'd write it myself, but don't have access to Weblogic to give it a > full test. > > Best regards > Ben Ben, Ok, I've got it fixed I think. It passes all the Junit Tests (you'll see that I had to add in a check for request != null since some of the tests pass in a null request) and my app now works as expected. Attached is the patch. I borrrowed the idea from the WebWork project (including the Variable name ) and wanted to give them full credit. Let me know if this isn't going to work or if it needs adjustments. As a side note, as a developer, you can get a 1 year free use of Weblogic just by downloading the server. That's how I'm able to test on it. Thanks, Patrick AbstractIntegrationFilter.java.patch Description: Binary data
RE: [Acegisecurity-developer] WebLogic 8 and Acegi
Hi Patrick, Using the ContextLoaderServlet with a load value of 1 works fine on Weblogic. I guess I got it in my head that it wouldn't work because it doesn't in Tomcat. I think Tomcat loads the filters which need the spring context before it loads the servlets. I am using Spring MVC (as does the Acegi contacts sample app) which makes the RequestDispatcher calls. I look forward to seeing your fix for this. Thanks, Travis -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Patrick Burleson Sent: Thursday, July 15, 2004 8:44 AM To: [EMAIL PROTECTED] Subject: Re: [Acegisecurity-developer] WebLogic 8 and Acegi On Wed, 14 Jul 2004 14:41:23 -0500, Travis Gregg <[EMAIL PROTECTED]> wrote: > > I am having problems getting Acegi to work in BEA Weblogic > 8.1 (perhaps the same problem Patrick is having). Any help or advice > would be appreciated. > > My first problem is this: Bea doesn't seem to > load the Spring ContextLoader Listener correctly. To get around this, I'm > using the Spring ContextLoaderServlet. Since Filters get loaded before > the ContextLoaderServlet, they throw an exception since the Spring context is > not loaded. I get around this with a modified version of the > FilterToBeanProxy that swallows exceptions in the init() method, and attempts > to re-init in the doFilter method if the filter delegate is null. > > I would appreciate it if anyone can tell me a way to get Bea > to load the filters correctly without modified code. > Travis, I have Spring Setup to load via the Servlet and have the servlet set to LoadOnStartUp with a value of 1. My only thought as to why Acegi can't find the context is that maybe the Context isn't named? Do you have something like the following in your web.xml: webAppRootKey testing.root contextConfigLocation /WEB-INF/testingContext.xml I only had problems with Acegi not getting the Context in WLS 8.1 when the webAppRootKey Param wasn't set. As for your second problem, do any of your servlets or filters call RequestDispatcher.include() or RequestDispatcher.forward()? If they do, then WLS applies the filters again on the same thread and Acegi inadvertantly blows away the Authenication object. I'm working on a fix for that. Thanks, Patrick --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] WebLogic 8 and Acegi
On Wed, 14 Jul 2004 14:41:23 -0500, Travis Gregg <[EMAIL PROTECTED]> wrote: > > I am having problems getting Acegi to work in BEA Weblogic > 8.1 (perhaps the same problem Patrick is having). Any help or advice > would be appreciated. > > My first problem is this: Bea doesn't seem to > load the Spring ContextLoader Listener correctly. To get around this, I'm > using the Spring ContextLoaderServlet. Since Filters get loaded before > the ContextLoaderServlet, they throw an exception since the Spring context is > not loaded. I get around this with a modified version of the > FilterToBeanProxy that swallows exceptions in the init() method, and attempts > to re-init in the doFilter method if the filter delegate is null. > > I would appreciate it if anyone can tell me a way to get Bea > to load the filters correctly without modified code. > Travis, I have Spring Setup to load via the Servlet and have the servlet set to LoadOnStartUp with a value of 1. My only thought as to why Acegi can't find the context is that maybe the Context isn't named? Do you have something like the following in your web.xml: webAppRootKey testing.root contextConfigLocation /WEB-INF/testingContext.xml I only had problems with Acegi not getting the Context in WLS 8.1 when the webAppRootKey Param wasn't set. As for your second problem, do any of your servlets or filters call RequestDispatcher.include() or RequestDispatcher.forward()? If they do, then WLS applies the filters again on the same thread and Acegi inadvertantly blows away the Authenication object. I'm working on a fix for that. Thanks, Patrick --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] WebLogic 8 and Acegi
Travis Gregg wrote: I am having problems getting Acegi to work in BEA Weblogic 8.1 (perhaps the same problem Patrick is having). Any help or advice would be appreciated. My first problem is this: Bea doesn’t seem to load the Spring ContextLoader Listener correctly. To get around this, I'm using the Spring ContextLoaderServlet. Since Filters get loaded before the ContextLoaderServlet, they throw an exception since the Spring context is not loaded. I get around this with a modified version of the FilterToBeanProxy that swallows exceptions in the init() method, and attempts to re-init in the doFilter method if the filter delegate is null. I would appreciate it if anyone can tell me a way to get Bea to load the filters correctly without modified code. My next problem (after getting around the Listener issue) is that after successfully logging in and viewing a secured page, a subsequent request for a secured url redirects me to the login page. Below is a debug log using the sample contacts.war. This is from version .51. I built the latest from CVS the other day and get the same issue. Thanks in advance, Travis Hi Travis You're probably best off posting to the Spring Users list regarding the ContextLoaderListener problem under Weblogic. Regarding the repeated authentication attempt, it's quite odd. To help work through it, would you mind deploying an unmodified contacts.war built using a current CVS HEAD snapshot, and email me off-list the full log? Thanks Ben --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Newbie Questions...
[EMAIL PROTECTED] wrote: First, thanks to Ben for helping me understand some of the Acegi internals. My question revolves around using BASIC authentication with Acegi. First, let me start by stating that I am not using HTML. I am using Flex which uses a Flash client with SOAP requests. What I want to know is if I use BASIC authentication will Acegi still be able to use the notion of a ContextHolder to store authentication credentials such as roles? I want to use the roles for my Spring managed business objects of course. Furthermore, is there a filter that I should be using that will not redirect to a page if authentication fails? Instead of the filter redirecting to a JSP, or other page, I would like to just send a response.sendError(HttpServlet.SC_UNAUTHORIZED) back to the client. Should I just write my own filter that is similar to the BasicProcessingFilter and append it in the chain of filters? The Flash client is expecting a 401 HTTP error to notice a Client.Authentication fault/exception. The current filter tries to redirect to the custom login form which does not apply in my context. Hi Mark The normal approach to BASIC authentication is to use SecurityEnforcementFilter, which detects any Acegi Security related exceptions. If the user is not logged in, the AuthenticationEntryPoint implementation will be called, which is usually BasicProcessingFilterEntryPoint in this case. If the user is logged in, a straight 403 (access denied) will be thrown. BasicProcessingFilterEntryPoint will throw a 401 (unauthorised) which will cause the calling browser to attempt login. Whilst SecurityEnforcementFilter can provide HTTP URL security, you don't _have_ to use it for this. The main value in your case is it detects security exceptions thrown by later executed code (namely the MethodSecurityInterceptor), meaning it can send the 403 or redirect to the AuthenticationEntryPoint accordingly. Does that answer your questions, as I think these classes will provide the behaviour you need? Best regards Ben --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
