Forum Discussion

Dave_Hatfield_2's avatar
Dave_Hatfield_2
Icon for Nimbostratus rankNimbostratus
Dec 08, 2010

after login 2nd redirect causing problems

We have a primary site called "eschool.oursite.org" that we want to auto redirect to another site "portal.oursite.org/eschool". From this site the users can click on a link to take them back to the login page "eschool.oursite.org/webapps/login".

 

 

The irule below works for the first part (redirect to our portal site). Clicking on the login link takes them correctly back to the login page "eschool.oursite.org/webapps/login" but when they put in their credentials they are redirected again to our portal and if they click on the login link again they are already authenticated and go fully into our "eschool.oursite.org" site.

 

 

The login form uses the following code:

 

form onsubmit="return validate_form(this,false)" method="post" action="https://eschool.mysite.org/webapps/login" name="login"

 

 

 

when CLIENT_ACCEPTED {

 

Set a variable to track whether this is an HTTPS request

 

set https 0

 

}

 

when CLIENTSSL_HANDSHAKE {

 

There was a client side SSL handshake, so update the variable

 

set https 1

 

}

 

when HTTP_REQUEST {

 

If there is no URI redirect to portal

 

if {[HTTP::path] eq "/" }{

 

HTTP::redirect "https://portal.oursite.org/eschool"

 

}

 

if {not ($https)}{

 

If it's not an HTTPS connection, send a redirect

 

HTTP::redirect https://[HTTP::host][HTTP::uri]

 

}

 

}

 

 

 

We are in dire straights till we get this resolved.

6 Replies

  • Hi Dave,

     

     

    Can you clarify what the actual failure is? Do you have an idea of what you want to do to fix the issue?

     

     

    Can you use a browser plugin like HttpFox for Firefox or Fiddler for FF and IE to trace the issue? Can you also post the full iRule(s) you're testing with? I assume the snippet you've provided isn't the full iRule as you haven't defined $https.

     

     

    Also, you left your actual domain in the Javascript code. Based on that, it looks like portal.oursite.org and eschool.oursite.org resolve to different IP addresses and are probably on different virtual servers. I assume you're not applying the same iRule to both virtual servers.

     

     

    Thanks, Aaron
  • I updated my original post with the full irule and it is only being used on the vip for eschool.mysite.org and thanks for catching my live site info.

     

     

    Yes both virtuals are on different hosts and ip addresses.

     

     

    The only issue we are having is that the redirect is happening again when we do not want it to when the user posts their login credentials on the login page. I have captured a tcpdump on the bigip and then decrypt it using ssldump but I do not see why they get redirected back to the portal. Maybe the post action is only sending the host url and no uri or it has to do with the way the responce back to "eschool.mysite.org/webacc/login" is formatted.
  • Can you use a browser plugin to capture the HTTP requests/responses unencrypted? You can also use logging within the iRule to see what's being executed there. You can also add debug logging for redirects in HTTP_RESPONSE to see what the app is sending back:

    
    when HTTP_RESPONSE {
    
        Check for redirects from the pool member
       if {[HTTP::is_redirect]}{
          log local0. "[IP::client_addr]:[TCP::client_port]: Redirect to [HTTP::header Location] from [IP::server_addr]:[TCP::server_port]"
       }
    }
    

    Aaron
  • Here are lines from the log:

     

     

    When I first browse to http://eschool.mysite.org, I get redirected to https://portal.mysite.com/eschool this appears in the log:

     

    Dec 8 11:39:15 tmm tmm[21333]: 01220001:3: TCL error: Rule eschool_http_redirect - Operation not supported. Multiple redirect/respond invocations not allowed (line 7) invoked from within "HTTP::redirect https://[HTTP::host][HTTP::uri] "

     

     

    After I click on the link to take me to the login page http://eschool.mysite.org/webapp/login I enter my credentials and hit submit the log shows:

     

    Dec 8 11:40:23 tmm tmm[21333]: Rule eschool_http_redirect : 171.167.62.268:34123: Redirect to https://eschool.mysite.org/ from 10.100.50.35:443

     

    (This is where the problem is occuring because I am being redirected to the site I first browsed to above making a loop)

     

     

    Then if I click on the same link to login (I have already authenticated and set the cookie) I am taken to the page I should have gone to in the last step.

     

    Dec 8 11:40:30 tmm tmm[21333]: Rule eschool_http_redirect : 171.167.62.268:34173: Redirect to https://eschool.mysite.org/webapps/portal/frameset.jsp from 10.100.50.35:443

     

     

    I hope this makes sense.

     

  • Resolved the issue with re working the irule to examine the referrer:

     

     

    when CLIENT_ACCEPTED {

     

    Set a variable to track whether this is an HTTPS request

     

    set https 0

     

    }

     

    when CLIENTSSL_HANDSHAKE {

     

    There was a client side SSL handshake, so update the variable

     

    set https 1

     

    }

     

     

    when HTTP_REQUEST {

     

    Check if referrer is eschool

     

    if {!([HTTP::header "Referer"] starts_with "https://eschool.mysite.org/webapps/")}{

     

    If there is no URI redirect to portal

     

    if {[HTTP::path] eq "/" }{

     

    HTTP::redirect "https://portal.mysite.org/eschool"

     

    }

     

    }

     

    if {not ($https)}{

     

    If it's not an HTTPS connection, send a redirect

     

    HTTP::redirect https://[HTTP::host][HTTP::uri]

     

    }

     

    }

     

     

    So simple when it works. Thanks for your help!
  • Hi Dave,

     

     

    Glad you found a solution.

     

     

    Out of curiosity, do you have this iRule applied to multiple virtual servers or a port 0 virtual server? It would probably be simpler to create a separate iRule for HTTP and one for HTTPS. Then you wouldn't need to track whether the request is not HTTPS. You'd also potentially be able to avoid checking the Referer header if the host/URI redirect is only needed on HTTP requests.

     

     

    Aaron