Announcement Announcement Module
Collapse
No announcement yet.
Integrating into existing Spring/Hibernate/Struts/Tiles app Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Integrating into existing Spring/Hibernate/Struts/Tiles app

    Hi all,

    I've installed acegi from CVS, installed the sample Contacts app into Tomcat, read the docs and read many posts in this forum. I have used JAAS before but prefer to skip it here. Hopefully I'm at the point I can ask decent questions. Our goal for the moment is to integrate acegi into our authentication for later authorization.

    1) We use Tiles everywhere. After Tiles validation of the user/password fields, we use 'extends TilesRequestProcessor' to control HTTP Session managment and if needed authenticate via a LoginAction like so:

    Code:
      public ActionForward doLogin(final ActionMapping mapping,
                final ActionForm form, final HttpServletRequest request,
                final HttpServletResponse response) throws Exception {
    
            LoginForm loginForm = (LoginForm) form;
            User user = loginForm.getTO(); 
            user = userService.verifyUser(user);
            if (user != null) {
                // session already controlled via TilesRequestProcessor
                HttpSession session = request.getSession(false);            
                session.setAttribute("PRINCIPAL_KEY", user);
                return mapping.findForward("homePage");
            }       
            return mapping.getInputForward();
    Question: Does it make sense to skip acegi Filters all together here and Authenticate programmatically, somewhat like so:

    Code:
            ...
            user = userService.verifyUser(user);
            if (user != null) {
                // session already controlled via TilesRequestProcessor
                HttpSession session = request.getSession(false);            
                session.setAttribute("PRINCIPAL_KEY", user);
                // PUT ACEGI HERE
                UsernamePasswordAuthenticationToken auth = new                   UsernamePasswordAuthenticationToken(user.getLogin(),user.getPassword());
                auth.setAuthenticated(true );
    session.setAttribute(HttpSessionIntegrationFilter.ACEGI_SECURITY_AUTHENTICATION_KEY, auth);
                return mapping.findForward("homePage");
            }
    The idea here is that doLogin() is called only when the Session is null from inside TilesRequestProcessor, we already have a an HttpListener that does cleanup on the PRINCIPAL_KEY above with potentially acegi as well, and we have an OpenSessionInView that caches our Hibernate Lazy objects between requests and we want to minimize the impact of acegi.

    Question: We have a logoutAction, and somehow between that and the HTTPListener, and also TilesRequestProcessor I need to set ContextHolder to null on session.invalidate(), right? Do I store ContextHolder in the HTTP session, also?

    Any guidance highly appreciated,
    iksrazal

  • #2
    To avoid filters, you need to merge the functionality represented by two Acegi Security classes: HttpSessionContextIntegrationFilter and AuthenticationProcessingFilter. Basicaly, the former will happen every single request, whilst the latter will happen only in response to an authentication action. You can have a logout action that simply sets the ContextHolder to null, and the wrapping HttpSessionContextIntegrationFilter-equivalent functionality will cause the HttpSession to be updated.

    I would ask, though, whether you could use the out-of-the-box classes with Tiles. I'm sure others have done so successfully.

    Comment


    • #3
      This thread might be of interest: http://forum.springframework.org/showthread.php?t=15671
      Last edited by robyn; May 16th, 2006, 03:37 AM.

      Comment

      Working...
      X