Forum Moderators: phranque
I am using the following .htaccess file:
rewriteengine on
rewritecond %{request_uri} !^/index.php
rewriterule ^. /index.php [R,L]
This causes the following:
www.abc.com/index.php --goes to--> www.mylocalserver.com/index.php "Address bar shows www.abc.com/index.php"
www.bcd.com/test.php --goes to --> www.mylocalserver.com/index.php "address bar www.bcd.com/index.php"
I need to change this to work as follows
www.abc.com/index.php --goes to--> www.mylocalserver.com/index.php?URL=www.abc.com/index.php "Address bar shows www.mylocalserver.com/index.php"
www.bcd.com/test.php --goes to --> www.mylocalserver.com/index.php?URL=www.bcd.com/test.php "Address bar shows www.mylocalserver.com/index.php"
Thanks
See the Apache mod_rewrite documentation, cited in our Apache Forum Charter.
This assumes that both sub-subdomains abc and bcd are mapped to your localserver via DNS or your local 'hosts' file.
As an aside, the leading "www." is unnecessary, makes the URL longer for no benefit, and makes abc and bcd into sub-subdomains instead of subdomains. I'd get rid of it if this were my site.
Jim
RewriteEngine on
RewriteRule !^index\.php$ http://localserver.com/index.php?url=%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
I also eliminated the unnecessary RewriteCond, moving the "NOT index.php" test into the rule itself.
Jim
The original problem was.
The once a request came in the users was redirected to a page where he agrees to a policy and when he accepts he gets redirected to the page he initially requested.
The problem is that the redirect is always going to the pause/block/initial redirect index.php page.
Example scenario
User requests www.abc.com/test.php
His requests is read by mod_rewrite
He gets redirected to www.mylocalhost.com/index.php?url=http://www.abc.com/test.php
After displaying a short policy notice, he gets redirected to [abc.com...] However the browser immediately displays. www.mylocalhost.com/index.php?url=http://www.abc.com/test.php instead of displaying [abc.com...]
As if the page itself was cached.
This is kind of a captive portal on my network, where users traffic is intercepted and once they agree to the network traffic policy their Internet is unlocked and they are redirected to the page they initially requested.
User requests www.abc.com/test.php (and gets redirected)
(User) gets redirected to [abc.com...] (and gets redirected)
From server abc.com's point of view, those two user requests are identical, and your server is doing what you've asked it to do - redirect to mylocalhost.com
As if the page itself was cached.
No, you've set up your server to always redirect X to Y.
You **haven't** told your server that if someone's already been redirected to Y once, and is now returning to X, that they don't need redirecting to Y again.
Remember, HTTP is a stateless protocol [en.wikipedia.org]...
The usual method is to set a cookie on the policy-accepted-thank-you page, and test for that cookie either in the mod_rewrite code, or in the script that it rewrites to.
mod_rewrite in Apache 2.x can set and test cookies. In Apache 1.3x, it can only test cookies. But in this case, that should be sufficient.
However, two side effects of this method are that visitors with cookies disabled will never be able to reach your content, and you will need to update your privacy policy to reflect the use of cookies if it does not already acknowledge their use.
Jim
my iptables redirect all requests to the localhost of my network www.mylocalserver.com. Once a user accepts the policy his traffic is not redirected anymore to my local server. So whatever page he does open he will go through to the real Internet web server.
For example a user tries to open www.google.com, the server intercepts the traffic and redirects it to my localhost on the same debian server using iptables. Once the user accepts the policy an iptable rule is added and his ip status is changed to valid in the database mysql ..and he traffic is not intercepted anymore. When the user clicks submit he submits to the same index page and the $_GET['url'] value is taken and after 5 seconds the user is redirected to that page.
At this instance there is nothing preventing the users browser from going directly to Google. However, instead of Google I get mylocalserver.com?url=www.google.com, this happens also if I do open a new tab and type in www.google.com however if I open IE or close and reopen firefox it works right away.
That is why I am suspicious of some caching process.
Any more thoughts after this ?
THanks for the efforts so far.
After the user state is marked as valid, this header should be replaces with one that allows normal local and/or network caching.
See Apache mod_headers for directives and syntax, and search for "HTTP Cache-control header(s)" to see the appropriate values for cache control headers.
Be aware that IP-address-based methods will fail with users of AOL, Earthlink, and many similar ISPs which use caching proxies in their networks; Each of their HTTP requests can appear to come from a different IP address within the ISP's allocated range and therefore, IP-based methods won't work. For this reason, a client-side cookie is needed; it's the only way you can be sure it's the same browser making a subsequent request.
Jim
My LAN <--My GW with iptables and .htaccess --> My ISL
The GW redirects all requests to local webserver, local webserver sends all requests to index.php?url=www.google.com for example. User unblocks and get's thank you page and get's redirected to www.google.com.
As said at this point there is nothing preventing the browser from going to www.google.com opening www.google.com in IE will open it right away. Because the policy page was openened in FF. However, opening in FF will cause it to display the accept policy page. As if the browser did cache that page for www.google.com.
In this scenario I would need to tell the browser that all requests related to my server need to be revalidated.
I did try:
header("Cache-Control: no-cache, must-revalidate"); // HTTP/1.1
header("Expires: Sat, 26 Jul 1997 05:00:00 GMT"); // Date in the past
header( "Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT" );
#header( "Cache-Control: no-cache, must-revalidate" );
header( "Pragma: no-cache" );
but that did not help.
Thanks
I would advise the use of "Cache-Control: no-store" instead of must-revalidate, because the request, if revalidated, would be re-validated from the google page. Also, completely flush your browser cache between tests, as forcing a page reload often doesn't work as expected.
It may turn out that it's impossible to retain the user state at a point in your network where it can be used for your purpose. If this turns out to be true, then your only solution might be to reverse-proxy all requests to the controlled resource (e.g. google in this case) through your server. Depending on your "policy" terms, you might be able to proxy only "pages" and let requests for included objects (e.g. graphics, multimedia, external JavaScript and CSS files, etc.) route directly to the controlled URL in order to avoid the huge traffic that might result otherwise.
Jim