Announcement Announcement Module
Collapse
No announcement yet.
Acegi - Login Tapestry Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Acegi - Login Tapestry

    Ben,
    Has this been implemented in the SecurityEnforcementFilter to ignore if the same page has been requested, (login in secure filter). I notice that there are some other approaches being followed:
    1. Extending ChannelProcessor as in Hispacta
    http://www.mail-archive.com/acegisec.../msg00289.html
    2. Excluding URLS using PathBasedFilterInvocationDefinitionMap as in Appfuse.
    I guess the SecurityEnforcementFilter approach feels the most intuitive to me and want to know on when it would be implemented if isnt already or if which of the other two approaches above you suggest is better.
    Thanks,
    John

    [Acegisecurity-developer] SecurityEnforcementFilter always executing, even if for login page
    Ben Alex
    Thu, 02 Sep 2004 22:56:39 -0700

    Karel Miarka wrote:

    Ben,

    You are completely right, but my filter solves one important problem
    regarding
    Tapestry: The current SecurityEnforcementFilter doens't allow the login page
    to be at the same place as the protected pages and because in Tapestry all
    the pages are accessed using app?service=page/PageName, so it is a problem.
    My filter is suitable for applications where all the pages should be
    protected except the login page.
    That would be nice If the SecurityEnforementFilter could be made to run only
    once and solve the cyclic
    problem when the login page is inside the protected area. But because it
    sends the redirect it is not enough to use the FILTER_APPLIED flag



    (cc: Developer list so there's some history)

    How about this for an approach....
    We change the AuthenticationEntryPoint.commence argument to also take a FilterChain. ie not just ServletRequest and ServletResponse. Then SecurityEnforcementFilter can be configured to secure all requests (ie *). It will delegate to FilterSecurityInterceptor, which in turn delegates to its superclass, AbstractSecurityInterceptor, which then finds nothing in the ContextHolder and throws AuthenticationCredentialsNotFoundException, which is then caught by SecurityEnforcementFilter (being a subclass of AuthenticationException) and it delegates to the revised AuthenticationEntryPoint. We could then modify AuthenticationProcessingFilterEntryPoint to detect if the request is for itself. Thus it will perform a FilterChain.doFilter rather than redirect again to the login page. This should not only work for Tapestry applications, but also any other situation whereby the user has secured * (including the login page). Do you (or anyone else) see any problems with this approach?


    Ben

  • #2
    Re: Acegi - Login Tapestry

    Originally posted by john017
    1. Extending ChannelProcessor as in Hispacta
    http://www.mail-archive.com/acegisec.../msg00289.html
    2. Excluding URLS using PathBasedFilterInvocationDefinitionMap as in Appfuse.
    I'd definitely do #2 these days.

    When I get some more time (I have been really snowed under since October and one project after the next) I will be providing a fuller solution to the anonymous user issue. Ideally every single request to the webapp will be "authenticated" - either by a real user or the automatic anonymous user - and SecurityEnforcementFilter will be adapted to differentiate between these two classes of Authentication. It will then know whether to commence a "real" login via AuthenticationEntryPoint, or return an access denied message.

    Comment

    Working...
    X