creating a web-app backdoor (utilising virtual server redirects) for internet users

Hi All,

 

 

I am trying to create a back door for a public web app to aid with troubleshooting for particular users.

 

 

We want them to enter the back door by adding a '-2' to the end of the request:

 

front door: abc.com/AA (used by all)

 

new back door: abc.com/AA-2

 

 

note: the application needs /AA in order to work (AA-2 will break the app), so we need to write it back to 'AA' when passing it through to the back-end.

 

 

We would like them to hit the default virtual server VS1, then swap over the the back door virtual server VS2 so no further VS1 rules are processed.

 

 

So our plan is to:

 

1. user hits abc.com/AA-2 which maps to VS1

 

2. iRule on VS1 redirects to VS2/AA (as stated, it NEEDS /AA for the webapp to work)

 

3. VS2 to accomodate the response

 

(repeat for every request, VS1 will always handle the request and then redirect to VS2)

 

 

PROBLEM! the intial request will have /AA-2 which will redirect fine, but subsequent requests will contain /AA in the URL Request (see step 2 above), hence the user will end up on VS1 after the initial 'AA-2' request.

 

 

In essence, I need a way to persist the 'AA-2'/backdoor state of the client.

 

 

Ideally it'd go something like this for subsequent requests:

 

1. user makes all requests via abc.com/AA which maps to VS1

 

2. iRule on VS1 redirects to VS2/AA using some PERSISTANT data sent by the client/stord by BIG-IP

 

3. VS2 to accomodate the response

 

 

Cookies appear not to work as they are only readable by the VS in which they are set, and due to the rule I have started on VS1 iRule:

 

 

when HTTP_REQUEST {

 

if { [HTTP::uri] ends_with "/AA-2" } {

 

HTTP::redirect https://VS2/AA

 

}

 

 

the HTTP_RESPONSE is handled by the VS2 which passes the cookies back to the client, it so it's cookies are not readable by VS1, so the next client request to VS1 will not be able to read the cookies set by VS2. Is there anyway around this in BIG-IP?

 

 

 

If not, I'm either going to look at using sessions/reverse proxy/something...that works. Unless I can get this cookie thing going. We'd also like to keep the 'abc.com' bit as any other URL/IP will cause a SSL cert security exception.

 

 

Any feedback/suggestions appreciated.

 

 

Regards,

 

 

Cam.