Announcement Announcement Module
No announcement yet.
Better subclassing in ACEGI Page Title Module
Move Remove Collapse
This topic is closed
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Better subclassing in ACEGI

    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.AuthenticationProcessi ngFilterEntryPoint

    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

  • #2
    Could (i) and (ii) be addressed by referring to a URL that you have a standard MVC controller serve, depending on the customer?

    In relation to (iii), what sort of different information would you like to see in WebAuthenticationDetails that is user-dependent and could not be expressed via the object returned from UserDetailsService?