I want to redirect entire site from one domain to other.
I works when i declare
RewriteRule with R=301 but user can easy notice that
he is redirected to other url in his navi bar.
The result i want to achieve is using remote server to display content
with url keeped from local server.
For example:
User types example1.com, the htaccess gets content from example2.com
(for main page and every subpage in example1.com). Server does not
redirect his browser but just loads remote data from example1.com.
It works when i just use file_get_contentes('example2.com... but
problem comes if there is some $_POST data.
The clean solution is to have the server that handles example2.com respond to requests sent to example1.com. This is usually done by configuring an Apache virtual host to use ServerName example2.com and ServerAlias example1.com.
If you cannot afford to do this, you should rely on an actual proxy-and-reverse-proxy instead of doing it yourself with PHP: it's faster, and it handles absolute URLs correctly (what happens if example2.com returns HTML that contains an <a href="http://example2.com/xxx"> ?). Apache has a correct proxy and reverse proxy implementation.
Not an answer to your question, but this solution is not optimal for a number of reasons:
It depends on two servers being up.
It is slower as the request has to be made twice.
It takes up double the bandwidth, and if you use a PHP script, additional resources on the proxying server.
Are you sure you have to do this?
If you really do, look into Apache's proxying capabilities instead of a PHP script that can deal with the problem you describe (and several others, for example session management, and passing through the HTTP_REFERER and HTTP_USER_AGENT variables). Here is a tutorial for it.
Note that this requires root access to the server.
I don't believe this is possible with .htaccess.
Could you not add example1.com as an alias in the httpd.conf for example2.com and change the DNS records for example1.com to point to the same machine as example2.com ?
That'll achieve what you are after and cuts out the middleman (example1.com's server).
You can't do such a redirect across domains using only mod_rewrite. A rewriterule that writes to an address on another server will always behave as if it has an R flag.
You'll probably have to use some server-side scripting, not sure how though.
I solved it by using:
$opts = array('http' =>
array(
'method' => 'POST',
'header' => 'Content-type: application/x-www-form-urlencoded',
'content' => (isset($_POST)) ? http_build_query($_POST) : '',
)
);
$context = stream_context_create($opts);
$result = file_get_contents('http://example2.com/'.$_SERVER['REQUEST_URI'], false, $context);
I realise that is quite lame solution but it works well.
Related
This is a relatively recent behavioral change and appears to be related only to requests which include a "Upgrade-Insecure-Requests: 1" request header.
Apache has started rewriting such requests for sites which are HTTP-only to an HTTPS URL using the default site name instead of just adding the / at the end of the requested URL.
Example: URL submitted in browser: http://www.example.com/blah
Intended redirect: 301 to http://www.example.com/blah/
Instead redirects: 301 to https://default.site.configured/blah/
This happens whether it's a named virtual on the same address as the default server or a virtual using a separate address with separate Listen directives.
I understand all the arguments in favor of the idea that everything should always be encrypted and I don't want to get into a debate about that. This site doesn't consider the tradeoffs desirable at this time.
The default site does have SSL and is configured to redirect HTTP->HTTPS, but the www.foo.com site is not configured that way and does not wish to implement SSL at this time.
Is there any way to get Apache 2.4 to disregard that "Upgrade" header and simply rewrite the URL as desired rather than altering the domain name?
After banging on this some more, I finally found the source of my woes.
This happens when you have IP based virtual hosts and did not configure a name for them using the "ServerName" directive.
tl;dr: If you are having this problem, try adding a "ServerName www.example.com" directive within the VirtualHost definition for the site and that should resolve it.
Details:
It does not happen until you encounter a URL that requires a rewrite other than adding a trailing /. (i.e. if you get a request that doesn't contain the "Upgrade-Insecure-Requests: 1" header, it only gets the trailing / added, but if you get one with that header, it also tries to rewrite the protocol to https which triggers the full URL rewrite).
In my case, the default host name had an SSL configuration, so it didn't fall back to HTTP after the rewrite or reject the rewrite as invalid.
YMMV, I did not continue to do an exhaustive test of all permutations once I found the solution.
I have a server server.example.com which serves Tomcat on port 80 via a ProxyPass/ProxyPassReverse to 8080 and a Drupal site on the same box at server.example.com:8001. If I enter in the port 8001 explicitly, the Drupal site behaves properly, but I need to make it accessible via server.example.com/blog so I created a ProxyPass/ProxyPassReverse for /blog http://server.example.com:8001 which serves the initial page for the Drupal site correctly, but once the form on the home page of Drupal is filled out and submitted, which POSTs to /, the site changes to the Tomcat site, presumably because the / is not relative to the current host on post :8001. How can I get the ProxyPass for /blog to remain persistent so that all subsequent requests remain within the :8001 VirtualHost (Drupal site)?
One thing I tried was with mod_rewrite:
RewriteCond %{HTTP_REFERER} /^blog/.*$
RewriteRule (.*) %{HTTP_HOST}:8001/$1 [L,P,NC]
But that did nothing at all as far as I can tell. I was hoping that if the initial request was for /blog then the referrer would be as well and I could keep requests on the :8001 virtualhost. Perhaps someone can explain why that is flawed.
The problem you are very likely running into is that the documents returned by Drupal include generated links that all reference / instead of /blog. mod_rewrite and proxypass don't do anything to the contents of documents -- they only act upon the request (or, in the case of ProxyPassReverse, on links such as Location: headers in returned content).
To make an application that normally expects to be installed as / operate on a different URL, you need either to :
(a) Configure the application to be aware of the proper base URL. Many applications include such a setting in order to support exactly the situation you have described.
(b) Install some sort of filtering proxy that can modify the content of returned documents. For Apache, mod_proxy_html is made to do exactly this. This is included natively in Apache 2.4 but may need to be installed separately for 2.2.
Our local development setup requires a box in the DMZ, and each developer has a line in its apache config for proxying. Looks something like:
ProxyPreserveHost on
ProxyPass /user1/ {user1's IP}
ProxyPassReverse /user1/ {user1's IP}
ProxyPass /user2/ {user2's IP}
ProxyPassReverse /user2/ {user2's IP}
#etc
Our public URLs become {DMZ server}/user1, {DMZ server}/user2, etc. The problem is that on the dev's boxes, the value of $_SERVER['HTTP_HOST'] is just {DMZ server}, without the user's subdirectory. The desired behavior is to have /user%/ as the real host name.
I've tried overriding the HOST var, and some rewrite rules, but nothing has worked.
Creating subdomains is not an option.
thank you for any help!
http://httpd.apache.org/docs/2.0/mod/mod_proxy.html#proxypreservehost seems to be the answer.
Im going to take a stab and suggest this:
SetEnvIf Host (.*) custom_host=$1
RequestHeader set X-Custom-Host-Header "%{custom_host}e/%{REQUEST_URI}e/%{QUERY_STRING}e"
That should hopefully set a request header called X-Custom-Host-Header that you can then pickup in PHP. If you want, you can try to override the Host Header, but I'm not sure on the implications of that. The Host header is a special HTTP header and generally only contains the host portion of an HTTP request, not the full request url.
Untested unfortunately, but it would help if you could clarify in a bit more detail what you are looking for.
EDIT, THIRD ANSWER:
Looks like Apache has heard this complaint before and the solution is mod_substitute. You need to use it to rewrite all the URLs returned in the document to insert /user1/.
EDIT, SECOND ANSWER:
Based on the additional information in your comments, I'd say your Apache config on your DMZ server is correct. What you are asking for is to have the developer machines generate URLs that include their context path (which is the J2EE term for something analogous to your /user1/ bit). I don't have any experience with PHP so I don't know if it has such a facility, but a quick search suggests it does not.
Otherwise, you'd have to roll your own function that converts a relative URL to an absolute URL, make that configurable so you can have it add something to the host name, and then force everyone to use that function exclusively for generating URLs. See, for some guidance, "Making your application location independent" in this old (outdated?) PHP best practices article for a solution to the related problem of finding local files.
PREVIOUS ANSWER: (doesn't work, causes redirect loop)
I'm still not clear what you are trying to do or what you mean by "Running on the dev apps are apache and PHP mainly, for hosting various applications", but as an educated guess, have you tried:
ProxyPass /user1/ {user1's IP}/user1/
ProxyPassReverse /user1/ {user1's IP}/user1/
If I were setting up the sort of environment you seem to be wanting to have, I'd want $_SERVER['HTTP_HOST'] to be {DMZ server} on every dev machine so that the dev machine's environment looks just like (or at least more like) production to the code running on it.
I am running freeNAS7 / lighttpd with some perl scripts that run on various ports localhost:5000, or localhost:8080 for example.
Now i tried to add cross-domian policy to the header but i cant get it to work, because most likley I am doing it incorrectly.I am not familiar with perl, if it were PHP then its pretty easy adding a header.(in terms of me understaning where to put it)
I was just thinking is there a way to rewrite for example something like
localhost/sabnzdb to display localhost:8080/ so that i can use client side to manipulate the iframe.
In lighttpd it's possible through mod_redirect. You can read about it here.
url.redirect = ( "^/sabnzdb$" => "http://localhost:8080" )
and put that in your localhost vhost (if you use vhosts) otherwise any place in your config should be ok.
I use apache as a proxy to my application web server and would like to on the fly, change the domain name associated with a sessionid cookie.
The cookie has a .company.com domain associated with it, and I would like using apache mod rewrite (or some similar module), transparently change the domain to app.company.com. Is this possible ? and if so, how would one go about it ?
You can only change the domain of a cookie on the client, or when it's being set on the server. Once a cookie has been set, the path and domain information for it only exists on the client. So existing cookies can't have their domain changed on the server, because that information isn't sent from the client to the server.
For example, if you have a cookie that looks like this on your local machine:
MYCOOKIE:123, domain:www.test.com, path:/
Your server will only receive:
MYCOOKIE:123
on the server. Why isn't the path and domain sent? Because the browser keeps that information on the client, and doesnt bother sending it along, since it only sends this cookie to your server if the page is at www.test.com and at the path /.
Since it's your server, you should be able to change your code that creates new cookies. If you felt you needed to do it outside of your code for some reason, you could do so with something like the following, but you'd have to look exactly at how your cookie is being written in the header to match it exactly. The following is an untested guess at a workable solution for this, using Apache's mod_headers:
<IfModule mod_headers.c>
Header edit Set-Cookie (.*)(domain=.company.com;)(.*) $1 domain=app.company.com; $2
</IfModule>
You can also use mod_headers to change the cookie received from the client, like so, if need be:
<IfModule mod_headers.c>
RequestHeader edit Cookie "OLD_COOKIE=([0-9a-zA-Z\-]*);" "NEW_COOKIE_NAME=$1;"
</IfModule>
This would only rename cookies you receive in the request.
ProxyPassReverseCookieDomain company.com app.company.com
or interchanging domains (as you are not clearly defining which is internal/external).
ref: https://httpd.apache.org/docs/2.4/en/mod/mod_proxy.html#ProxyPassReverseCookieDomain
I don’t know any module that provides such feature. So I guess you will need to write your own output filter using mod_ext_filter that does this for you.
But if you have control over the other server, it might suffice to just omit the cookie’s domain value so that the client will automatically choose the requested domain as the cookie’s domain.
I ended up just creating an intermediate page that via javascript changed the cookie domain to the proxy server (by omitting the domain value) and then re-directed user to the target page. That seemed to resolve the issue. Thanks for your answers.
If your web-app is capturing the Host: header and using that to determine the domain= portion of the cookie, you might also consider the Apache directive
ProxyPreserveHost On
which relays the Host: header from the client.
This only works if your app is designed to assume that its domain name is whatever the client suggests with the Host header. If your app is one of these, this will not only fix your cookies, but also any absolute URLs that the application generates, which can save you the overhead of otherwise needing to enable mod_substitute
ProxyPass "/" "http://company.com/"
ProxyPassReverse "/" "http://company.com/"
ProxyPassReverseCookieDomain "company.com" "app.company.com"
Note: If it comes second in ProxyPass it should be first in ProxyPassReverseCookieDomain... I spent half a day or more figuring this out :-/
Also see: https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypassreversecookiedomain