Announcement Announcement Module
Collapse
No announcement yet.
Changed implementation of AuthenticationProcessingFilter Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Changed implementation of AuthenticationProcessingFilter

    Hi all,
    After updating from acegi 1.0.0 RC2 to 1.0.0 final we recognized a change of the implementation of AuthenticationProcessingFilter.

    What happend:
    We wanted to have a different start page for special users after logging into the system. We wrote an extension of the AuthenticationProcessingFilter which overwrites the successfulAuthentication method. Here is the implementation...

    Code:
    protected void successfulAuthentication(HttpServletRequest request,
    		HttpServletResponse response, Authentication authResult) throws IOException
    {
    	String targetUrl;
    	if (authResult != null && authResult.getPrincipal() instanceof WlcClient)
    	{
    		WlcClient client = (WlcClient) authResult.getPrincipal();
    		if (client.isUserInRole(WlcConstants.WlcRoles.ADMIN_USER))
    		{
    			targetUrl = request.getContextPath() + getDefaultAdminTargetUrl();
    			logger
    						.info("Authenticated user is an administrator... redirect to admin page ["
    								+ targetUrl + "]...");
    			request.getSession().setAttribute(ACEGI_SAVED_REQUEST_KEY, targetUrl);
    		}
    		else if (client.isUserInRole(WlcConstants.WlcRoles.WL_ADMIN_USER))
    		{
    			targetUrl = request.getContextPath() + getDefaultWlAdminTargetUrl();
    			logger
    						.info("Authenticated user is an wl-administrator... redirect to admin page ["
    								+ targetUrl + "]...");
    			request.getSession().setAttribute(ACEGI_SAVED_REQUEST_KEY, targetUrl);
    		}
    	}
    	super.successfulAuthentication(request, response, authResult);
    }
    In acegi 1.0.0 final there was a change in the constants. The ACEGI_SECURITY_TARGET_URL_KEY no longer exists in 1.0.0 final. After reviewing we changed it to ACEGI_SAVED_REQUEST_KEY and compilation was successful.

    Now we have the following exception:
    Code:
    java.lang.ClassCastException: java.lang.String
    	org.acegisecurity.wrapper.SavedRequestAwareWrapper.<init>(SavedRequestAwareWrapper.java:88)
    	sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    	sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
    	sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
    	java.lang.reflect.Constructor.newInstance(Constructor.java:494)
    	org.acegisecurity.wrapper.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:75)
    	org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
    	org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:216)
    	org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
    	org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:195)
    	org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
    	org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
    	org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:90)
    	com.namics.publiconnect.wlc.web.filter.SiteContextFilter.doFilter(SiteContextFilter.java:91)
    	org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:137)
    	org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:75)
    	org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:77)
    Can someone explain the change or give an alternativ to implement the described requirement (different start pages depending on the user's role)?

    Thanks and kind regard,
    Sandro

  • #2
    I think the best option for your situation would be if we provided a protected getter method for the defaultTargetUrl and you overrode this to return a different value for your different roles (making sure that the alwaysUseDefaultTargetUrl property is set of the filter).

    This seems like a reasonably small change and could provide a userful option for similar scenarios where multiple default Urls are required.

    Comment


    • #3
      http://opensource.atlassian.com/proj...browse/SEC-295

      Comment


      • #4
        I've made the changes to the class (in fact the accessor was already there, but I just had to make sure it was used internally).

        so you should be able to use:

        Code:
        public String getDefaultTargetUrl() {
           Authentication authResult = SecurityContextHolder.getContext().getAuthentication();
        
           if (authResult != null && authResult.getPrincipal() instanceof WlcClient)
           {
              WlcClient client = (WlcClient) authResult.getPrincipal();
              if (client.isUserInRole(WlcConstants.WlcRoles.ADMIN_USER)) {
                 return request.getContextPath() +getDefaultAdminTargetUrl();
              }
              
              // other cases
           }
        
           return super.getDefaultTargetUrl();
        
        }
        The subversion tag is 1538 so if you pick up a nightly build snapshot with this number or later this should work Ok.

        Comment


        • #5
          Hi Luke,

          That would be great and very helpful! I've taken the 1.0.0 tag in subversion and patched the one file with the current version in the trunk. Is this ok or do i need other dependencies?

          Thank very much and best regards,
          Sandro

          Comment


          • #6
            Hi Luke,

            I've seen in your code that you access the request object but you don't provide it in the method-signature... so it is probably better to provide a general hook-method than using the getter of an instance variable...

            Bye,
            Sandro

            Comment


            • #7
              Hi,

              That's actually a mistake, as I just copied the code from your earlier post. The default target Url should be relative to the context. The context is prepended here:

              http://www.acegisecurity.org/multipr...ilter.html#389

              So you only need to return "getDefaultAdminTargetUrl()" or whatever.

              Luke.

              Comment


              • #8
                Hi Luke,

                I see... thats fine...

                Now i have another question (Just to be sure i we use it correctly)?
                In the prev implementation we could access the saved target url in the session as a string. Is this correct anymore? Or do we need to cast it always into a SavedRequest and therefor integrate it with the org.acegisecurity.wrapper.SecurityContextHolderAwa reRequestFilter?

                Thanks and regards,
                Sandro

                Comment


                • #9
                  You can get the Url from the saved request - see the method obtainFullRequestUrl:

                  http://acegisecurity.org/multiprojec...ilter.html#276

                  Comment


                  • #10
                    Originally posted by Luke
                    I think the best option for your situation would be if we provided a protected getter method for the defaultTargetUrl and you overrode this to return a different value for your different roles (making sure that the alwaysUseDefaultTargetUrl property is set of the filter).

                    This seems like a reasonably small change and could provide a userful option for similar scenarios where multiple default Urls are required.
                    Luke, I was wondering if the same could be done with alwaysUseDefaultTargetUrl, so AbstractProcessingFilter could use the isAlwaysUseDefaultTargetUrl() method instead of the variable directly.

                    In my case, I want the first time a user logs in to be redirected to a welcome page, but all others should follow their target urls. In this case, my idea was to override isAlwaysUserDefaultTargetUrl() method (which is not currently called by succesfullAuthentication() in AbstractProcessingFilter) that would decide if the the filter should use the default target always (in case of first-time users) or not (in case of other users). In the former case, my getDefaultTargetUrl() would decide which welcome page is appropriate.

                    What do you think?

                    Thanks,

                    Rodrigo

                    Comment


                    • #11
                      We have also developed a similar solution in order to redirect our users based on their roles when they enter to our system to different start pages. We have also created a PageRedirectDefinition concept in order to to specify which page will be redirect to for which roles. We define them in spring beans xml file like below;

                      <property name="pageRedirectDefinitionSource">
                      <value>
                      ROLE_ADMIN,ROLE_DATA_PROCESSOR=create.jsp
                      ROLE_DATA_READER=search.jsp
                      </value>
                      </property>

                      You can read my article explaining our solution's detail here: http://jroller.com/page/ksevindik?en...ifferent_start

                      Cheers.

                      Comment

                      Working...
                      X