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