Hi folks,

we are currently changes our web-application to use ACEGI-Security 1.0.0 RC2 
as our authentication mechanism. So far it is working great and thanks for
this great job. 

Due to the nature of our application, we have some special requirements.
Our application supports several client-installations, i.e. we have different
customers which are essentially using the same web-application, but use 
diffent databases, different user repositories etc. So one example of 
such a requirement is that we have to change the defaultTargetUrl dynamically:

http://host1/defaultTargetUrl&client=1 or
http://host1/defaultTargetUrl&client=2 etc.

With that setting we stumbled over some minor implementation-issues of the
current version. Most of them are about using instance-variables directy 
in the classes so that a subclass cannot change the value dynamically. 
I'd like to discuss these request because I think it would greatly simplify
the adaption for us and I think others as well.


i.) org.acegisecurity.ui.AbstractProcessingFilter

Use getter-methods in already implemented methods for instance variables: 

    private String defaultTargetUrl;
    private String filterProcessesUrl = getDefaultFilterProcessesUrl();
    private boolean alwaysUseDefaultTargetUrl = false;
    private boolean continueChainBeforeSuccessfulAuthentication = false;
    

The reason for this recommondation is that I had to write subclasses of 
AbstractProcessingFilters and I had to change dynamically these values, i.e.
the decision what value the defaultTargetUrl exactly has, has been deferred to
a subclass. 


ii.) org.acegisecurity.ui.webapp.AuthenticationProcessingFilterEntryPoint

User getter-method for instance variable loginFormUrl, so that subclasses
just can override the method getLoginFormUrl().


iii.) Creation of WebAuthenticationDetails instances via Factory

Although it is possible to override some methods to change the creation
of WebAuthenticationDetails I think a better solution was to introduce some
kind of factory for the creation of WebAuth instances. If used correctly
one could specify the concrete implementation in a spring bean and just 
create that class.


So what do you think about these changes? I think they could be realized
quite easily and would enhance the ACEGI-Package. 

With regards
Tino

