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 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
>
-------------------------------------------------------
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
