Help save net neutrality! Learn more.
Close

Redirects - why are they used

flintdk
2011-04-11
2013-05-08
  • flintdk

    flintdk - 2011-04-11

    Hi folks,

    Not sure if this is a support or a design question.  I'm using jGuard 1.0.3 in a web application for a while.  One thing jGuard does, which is now causing me problems, is redirects.

    Is there a reason jGuard uses redirects and not forwards?  I'd like to understand your rationale behind using them to better understand the best way forward for my present situation.

    The problem I have is that my site is "multi-tenant."  I.e. one web application, but treated by my clients as multiple separate applications.

    The root application url is:
      www.example.com
    Client one access his site using:
      www.example.com/client1/
    Client two accesses his site using:
      www.example.com/client2/
    … etc. etc..

    I have a central set of permissions based on the "root application".  I run a filter **outside jguard** so that jguard only ever sees/considers requests as if they are to the "root application" and this setup works well in most regards except when jGuard does a redirect.

    A redirect tells the clients browser that he is being moved… but I absolutely don't want this!  An example might be the best way to explain.

    If a user opens a fresh browser session and browses to:
      www.example.com/client1
    I intercept that request in my filter and do a 'server side forward' (i.e. invisible to the clients browser) to www.example.com
    JGuard then grabs the request and performs a guest authentication (correctly) but then **redirects** the user to www.example.com
    The redirect updates the clients browser and they end up on  www.example.com and not on  www.example.com/client1 where they expected to be.

    Is the above clear?  I appreciate it's an unusual configuration but in my case jGuards use of redirect and not forward is causing me significant problems, so I wondered was there a reason for it.

    Regards,

    Tom.

     
  • flintdk

    flintdk - 2011-04-12

    If I might refine this a little bit - it's the use of one redirect in particular that seems incorrect:

    When a client opens a fresh browser session, and browses to an application managed by jGuard for the first time:
    jGuard intercepts the request
    jGuard authenticates the user as a 'guest'
    jGuard checks the uri accessed is permissable for the guest user
    if the permissions are correct, jGuard redirects the user to the desired uri.

    It is this redirection that seems genuinely wrong to me.

    I've no problem with redirection for access denied, for authentication failed, etc.as in those cases 'redirection' is in fact what is happening.

    But for the first case, 'forward' is really the correct action, no?

    Regards,

    Tom.

     
  • flintdk

    flintdk - 2011-04-15

    Hey Charles,

    Thanks for that.
    Well - I agonized about it for a while and then decided to edit the accessFilter class.  I really don't like tinkering with third party libraries but in this case it just seemed the best approach.

    So I did the following:

          // 13/04/11 TK,  Replaced...
          //AuditManager.addEvent(subject," user is authenticated "," redirect to "+redirectURI);
          //if(!res.isCommitted()){
          //  res.sendRedirect(res.encodeRedirectURL(req.getContextPath()+redirectURI));
          //}
          AuditManager.addEvent(subject," user is authenticated "," forward to "+redirectURI);
          if(!res.isCommitted()){
            // The difference between req.getRequestDispatcher(redirectURI) and
            // ServletContext.getRequestDispatcher(redirectURI) is that the former
            // can take a relative path, the latter CAN NOT
            RequestDispatcher request_Dispatcher;
            //request_Dispatcher=filterConfig.getServletContext().getRequestDispatcher(redirectURI);
            request_Dispatcher=req.getRequestDispatcher(redirectURI);
            request_Dispatcher.forward(req,res);
          }
    

    … in the postAuthenticationProcess method.  It seems to work just fine.

    Thanks for the heads up.  Looking forward to version 2 final now!

    Any idea if the feature "the user of jguard should choose between a redirect and a forward action" will be included in version 2 (fingers crossed!!)

    Thanks and regards,

    Tomás.

     
  • Charles Lescot

    Charles Lescot - 2011-04-16

    Hi Tomás.
    thanks to  share your patch!
    the 2.0 will try to not contains too many new features, to have a reasonable shipping date..(according to the last stable release, this rewriting is very slow, i'm agree).
    but this feature seems crucial for performance and usability.
    we will try to add it to the final 2.0 release.

    best regards,

    Charles.

     
  • Charles Lescot

    Charles Lescot - 2011-10-26

    Hi,
    just a feedback on your proposal:
    i've added on the git trunk ,the 'dispatch' choice of redirect/foward, for actions done by jguard.
    this mechanism is controlled  with urlpermission, in the actions field (separated with ',') .

    now, if no dispatch value is specified, the forward way is used, but you can define a DISPATCH or FORWARD value in the actions field of any URLPermission in your jguardFilter.xml file, used by jguard to react (logonURI, accessDeniedURI and so on…).

    here is a configuration file example used in a junit test, to validate this feature:

    <?xml version="1.0" encoding="UTF-8"?>
    <callbackHandler xmlns="http://jguard.sourceforge.net/xsd/jGuardFilter_2.0.0.xsd"
                     xmlns:xs="http://www.w3.org/2001/XMLSchema-instance"
                     xs:schemaLocation="http://jguard.sourceforge.net/xsd/jGuardFilter_2.0.0.xsd jGuardFilter_2.0.0.xsd">
        <authenticationSchemeHandler
                className="net.sf.jguard.jee.authentication.schemes.HttpServletLoginPasswordFormSchemeHandler">
            <!-- Uri to access to the authentication form -->
            <parameter key="logonURI" value="/Logon.do,REDIRECT"/>
            <!--  uri to be authenticated. The action property of the authentication form MUST NOT be set to j_security_check. -->
            <parameter key="logonProcessURI" value="/LogonProcess.do*"/>
            <!-- uri to to be unauthenticated -->
            <parameter key="logoffURI" value="/Logoff.do*"/>
            <parameter key="loginField" value="login"/>
            <!-- Parameter's name of the form's field which holds the password. All values are accepted except j_password. -->
            <parameter key="passwordField" value="password"/>
            <parameter key="goToLastAccessDeniedUriOnSuccess" value="true"/>
            <!-- Uri when the user authentication failed. -->
            <parameter key="authenticationFailedURI" value="/AuthenticationFailed.do*,REDIRECT"/>
            <!-- Index uri of your web application. -->
            <parameter key="authenticationSucceedURI" value="/index.jsp,,REDIRECT"/>
            <!-- uri when access to a ressource is denied -->
            <parameter key="accessDeniedURI" value="/AccessDenied.do*,REDIRECT"/>
        </authenticationSchemeHandler>
    </callbackHandler>
    

    hope it helps,

    Charles.

     

Log in to post a comment.