On 2/8/06, Ben Alex <[EMAIL PROTECTED]> wrote: > BasicProcessingFilter proactively attempts authentication (via > AuthenticationManager) whenever it sees a BASIC authentication header, > which is consistent with the contract for an authentication mechanism > and the others included with Acegi Security. The reason they all attempt > authentication is to give the user early advice there is a problem with > presented credentials, even in the case the user isn't actually > requesting a secure object. For example, someone may present a BASIC > header but request a public home page. In that situation the > authentication mechanism would notify the user agent as early as > possible there has been an issue.
makes sense. > In your case we do have a few options: > > - Provide a "failedAuthentication" method in BasicProcessingFilter so > you could subclass and override the default behavior. You'd probably > like to leave the SecurityContextHolder null and allow the FilterChain > to proceed. Your "ticket" filter would then have a chance to process the > request. > > - Provide an "ignoreFailure" property, which essentially does the same > FilterChain continuation as the aforementioned option. i'd prefer being able to set a property rather than having to subclass and override a method. otherwise, your description of the behavior i want is spot on. > - Write your own authentication mechanism that reflects your particular > needs. You don't need to use the BasicProcessingFilter. i considered doing this, but i'd prefer to reuse your logic for extracting credentials from the Authorization header. > - Use BASIC authentication as a transport for your tickets. I'd probably > see this as the most elegant approach, if it were possible. Rather than > use a dedicated HTTP header, use a specific username to denote a ticket, > eg "TICKET". The password would be the actual ticket itself, > Base64-encoded as per standard BASIC authentication headers. Then you're > going to only need deal with all of this in your UserDetailsService > implementation. So you've also avoided needing to write an > AuthenticationProvider (and probably an Authentication implementation > and authentication mechanism as well). Plus you've picked up the benefit > of allowing migration (one day, if you like) to a form-based > authentication interface (debugging?), digest or similar authentication > that can also be carried in a simple username + ":" + password formatted > payload. this is a cool idea, but it won't work for me. the functionality i've implemented is a webdav extension (<http://www.sharemation.com/~milele/public/dav/draft-ito-dav-ticket-00.txt> which specifies the use of a "Ticket" header or a "ticket" parameter to contain the ticket credential. so, i'll work up a patch tomorrow that adds an "ignoreFailure" property to BasicAuthenticationFilter (or to its superclass, if appropriate) and send it in. thanks for the suggestion! ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ Home: http://acegisecurity.org Acegisecurity-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
