Redirect result within policy..

[rhymeturner]

Hi there!

I am relatively new to WinGate, and I am essentially testing it out for our small business network (15+ users). Almost everything thus far is working accordingly, and I am very pleased with the overall solution it provides our company. However, there is one aspect that I have been unable to achieve a successful result with. Whilst creating a policy, one can naturally add a result (allow, reject, disconnect, divert, auth) et cetera, and all of them work as expected, except, divert. When I utilize this option, I ALWAYS get a redirect loop result, no matter what policy I utilize. For example, let's say that I use the example policy (Web example proxy request handler) and I change the first flowchart boolean (Apply Restrictions -> No) from Allow to Divert and then I add a website local or remote i.e. (http://10.0.0.55 or http://www.yahoo.com) (Apache server within network and Yahoo! website respectively)... basically I get redirect loop error within the browser, which makes sense. So, therefore, any suggestions how to get this to work successfully?

If you require any further information, please do not hesitate to let me know. Thanks!

John

[adrien]

Hi John

the divert result, when it is diverting to a URL (rather than a local file/script to be served) sends a redirect response back to the client, and the client then makes another request for that URL.

So the new request comes back in, and you need to make sure this one is not itself diverted back to itself, or you get a redirect loop.

What this means basically is that you need a decision prior to the divert to not divert if the URL is the one you're diverting to.

Regards

Adrien

[rhymeturner]

Dear Adrien!

Many thanks for your fast response and guidance. Appreciated.

What you said made absolute sense to me, and I did try this using two different methods (List lookup check and Expression evaluator) on the symbol item: {{Request.URL.Contains(Text Search,Boolean CaseSensitive)}} This is placed directly prior to where the divert result was before.

Naturally, with the list lookup check, I did a non-case-sensitive pattern match (not that the former aspect matters with IP addresses, but still) and then added an item "10.0.0.55" (without quotations) to the list and that was it. I also tried adding more formal rules "http://10.0.0.1" et cetera.

On the yes channel, I experimented with a range of results - from allow through to reject.

On the no channel, I placed the divert result (through to URL "http://10.0.0.55"). But, it's still getting stuck within a feedback loop.

Forgive me, logic and programming is not my thing, therefore, I may be missing something very obvious here. Essentially, if I type something in the browser such as "http://www.google.com", "http://www.yahoo.com", it does get re-directed through to http://10.0.0.55 (which typically without this policy will display the business intranet page), but, right now it won't display due to the feedback loop. The method list lookup check looks correct to me and one would think that it would work, but, to no avail, thus far.

Finally, this is all placed within a policy of WWW Proxy Server: ProxyRequest (as I may have mentioned before), but wasn't sure if it made a difference at all.

Adrien, any thoughts?

Cheers!

John

[adrien]

Hi John

ok, a few things.

1. if you want the page you've diverted to to be readable, then the result would need to be allow for the decision used to bypass the divert.

2. How you match / what sort of decision element will affect how you need to implement it. If you use a list lookup, then the thing you match would be either {{Request.URL}} or {{Request.Server}}

{{Request.Server}} is probably more useful, and then you could match just the servername part of the URL, in your case 10.0.0.1 No quotes when entering the value in the list control.

if you were using an expression evaluator, it would be something like either

Request.Server == "10.0.0.1"

or

Request.URL.Contains("10.0.0.1")

Regards

Adrien