I have a rewrite rule which is looking for a particular URI. When it matches the particular URL it rewrites it with a proper file path so the required content can be found. It then changes the protocol to HTTPS and allows the request to pass through.
I have two problems;
I don't want the rewritten path to appear in the users browser - i want to maintain the vanity url
I do want the HTTPS protocol to appear indicating to the user that they are accessing the site over a secured conection.
I have tried a couple of options but no success. If i include the [R] flag the URL and protocol remain unchanged but that is not the desired effect
Any suggestions on how i can achieve this?
This is my rule;
RewriteMap redirectsIfSecure txt:/myserver/content/secure_urls.txt
RewriteCond ${lowercase:%{REQUEST_URI}} ^/(.+)$
RewriteCond ${redirectsIfSecure:%1|NOT_FOUND} !NOT_FOUND
RewriteRule ^(.*)$ https://myserver.com${redirectsIfSecure:%1} [PT]
From the mod_rewrite documentation:
If an absolute URL is specified, mod_rewrite checks to see whether the
hostname matches the current host. If it does, the scheme and hostname
are stripped out and the resulting path is treated as a URL-path.
Otherwise, an external redirect is performed for the given URL. To
force an external redirect back to the current host, see the [R] flag
below.
If you rewrite the request to a fully qualified URL (that is, anything starting with http://, https://, etc) that doesn't match your ServerName, then mod_rewrite will issue an HTTP redirect, which will cause the client browser to request the resource from the new location.
If you're not trying to switch between http and https you can use a proxy rule (the P flag) to have Apache make the request on behalf of the client and return the result, thus masking the rewritten URL.
However, if you're trying to upgrade from http to https (or the other way around), this will always require a client redirect.
Related
I registered a expired domain to forward all incoming links to another domain. The problem is: many inlinks are placed on subdomains, for example: axa-art.cdn.contento-v41.eu/axa-art/0eee9cec-58cb-45b2-a4e2-b5f73920068e_091216_axa+art_classic+car+study_de_rz.pdf
I am looking for a 301 redirect rule in htaccess that forward any url (no matter on main domain or subdomain) to "new-url.tld"
axa-art.cdn.contento-v41.eu
axa-art.cdn.contento-v41.eu/slug
any-subdomain.contento-v41.eu
any-subdomain.contento-v41.eu/slug
all of this example above should
forward to this exact URL: new-domain.tld
Question 1:
Is it possible to create a "general" rule and place it into htaccess of the main directory?
Question 2:
Or do i have to write a specific rule for each subdomain?
Question 3:
Do I have to create a sub-directory and create a separate htaccess in every sub-directory for each subdomain I want to add redirection-rules?
Help or suggestions are highly appreciated. Thank you very much for your help in advance.
This isn't just a .htaccess question. In order for your server to receive requests to <any-subdomain>.example.com the necessary DNS and server config directives need to be in place. If the request doesn't reach your server then you can't implement a redirect in .htaccess.
So, I suspect that these subdomains are not even resolving?
You either need to create the necessary DNS A records and ServerAlias directives one by one for each hostname (ie. subdomain) or create a "wildcard" DNS A record (and ServerAlias *.example.com directive in the vHost). But then you still have an issue with these hostnames being covered by an SSL cert if you need to redirect from HTTPS.
You can then create the necessary redirect in .htaccess. Although, since you need access to the server config (or a using a control panel that does this for you) to implement the directives above, you should also implement this redirect in the server config also.
For example, at the top of your .htaccess file, before the existing directives (or in your vHost):
RewriteEngine On
RewriteCond %{HTTP_HOST} !^new\.example$
RewriteRule ^ https://new.example%{REQUEST_URI} [R=301,L]
The above states... for any request that is not for new.example then 301 redirect to https://new.example/<same-url>.
However, if you have access to the server config and this other domain is configured in its own vHost container then the redirect can be simplified:
Redirect 301 / https://new.example/
UPDATE#1:
this rule does forward any URL form the main domain to the new domain.
# Permanent URL redirect- by netgrade
RewriteEngine on
RewriteCond %{REQUEST_URI} !https://www.marco-mahling.de/$
RewriteRule $ https://www.marco-mahling.de/ [R=302,L]
The rule I posted above should probably replace your existing rule entirely.
Yes, your rule does redirect every URL to the root of the new domain, but it is arguably incorrect. The RewriteCond directive is superflous and isn't actually doing anything. The REQUEST_URI server variable contains the URL-path, it never contains the scheme + hostname. So, the RewriteCond directive you've posted will always be successful.
If that is the rule you currently have then it would already redirect everything. In which case your problem would seem to the necessary DNS and server config directives as mentioned above.
From your directives, I assume that the other domain actually points to a different server (or different vHost on the same server). Otherwise, this would have resulted in a redirect-loop. In which case, you only need the much simpler Redirect directive that I posted above.
UPDATE#2: That works fine BUT the incoming links are still not forwarded cuz of a "%" in the url: https://axa-art.cdn.contento-v41.eu/axa-art%2F0eee9cec-58cb-45b2-a4e2-b5f73920068e_091216_axa+art_classic+car+study_de_rz.pdf
It's actually because of the %2F - an encoded slash (/) in the URL-path. By default, Apache will reject such URLs with a 404 (for security reasons).
To allow encoded slashes in the URL you would need to set AllowEncodedSlashes On in the server config (or vHost container). You cannot set this in .htaccess. (The server generated 404 occurs before .htaccess is even processed.)
However, I would express caution about enabling this feature. (Is there a specific requirement here? Are you recreating these documents on the new server?)
If this request was intended to map directly to a PDF file on disk then this actually looks like an incorrectly URL encoded request, since a slash / is not a permitted filename character on either Windows or Linux.
If you enable AllowEncodedSlashes then the above RewriteRule will redirect the request to /axa-art/0eee9cec....pdf - note the %-decoded / in the resulting URL. You would need to take additional steps to maintain the URL-encoding (if that was required), but as I say, that looks like a mistake to begin with.
Currently, I'm working with some guys that love short URLs for marketing purposes when posting to social media.
They have https://www.example.com/folder/subfolder
For their marketing, they would like https://www.example.com/mysuperbuzzword which would point to the first URL but in the browser, you would still see the shorter URL.
My first thought was "I'll just add a rewrite rule in the .htaccess"
Something like Redirect 301 /mysuperbuzzword /folder/subfolder/ which would work but then the URL changes.
I did some reading and discovered the [P] flag. Then I tried this:
RewriteCond %{REQUEST_URI} ^/vanityurl
RewriteRule ^(.*)$ /folder/subfolder [P]
The issue I have now is that because /vanityurl doesn't exist, instead of rewriting, I just get a 404 error.
I've been testing my rule using a .htaccess rule checking tool and the URL it spits out looks correct, but again, I just get a 404.
Also, if you use the flag [PT] the resource is found but the URL is changed in the address bar.
You tested with a permanent redirect. Never do that. It is cached by the browser, and the browser will no longer do requests to the server. This is possible, because such a redirect is supposed to be... well... permanent. If you must test redirects, test them with a temporary redirect (302) and change them later if everything turns out to be fine.
With mod_rewrite you can do three things:
Do an internal rewrite. If you internally rewrite url a to url b, then the user sees url a, but url b is being executed on the server.
Do an external redirect. If you externally redirect url a to url b you send back a response: "Please request url b instead.". The browser then sends another request to the server with url b and changes the url in the address bar accordingly.
Do a proxy request. If you proxy url a to url b, the user requests url a. The server then opens a http connection and requests url b. It then waits for the response and channels that back to the client. It is very expensive to do such a thing via mod_rewrite.
What you simply want to do is:
RewriteRule ^vanityurl$ /folder/subfolder [L]
It as a simple internal rewrite.
On my website, I would rename the URL on address bar, from
domain.com/economy/article.php?id=00
to
domain.com/economy/id-name-article.html
I wrote this .htaccess file:
RewriteEngine On
RewriteRule ^([0-9]+)-([^\.]*)\.html$ http://domain.com/economy/article.php?id=$1 [L]
I have an anchor with this href: href="economy/id-name-article.html" and when I click on it, the server is redirected on article.php, it runs the script in the correct way and I can view the article, but on the address bar is still written domain.com/economy/article.php?id=00 instead domain.com/economy/id-name-article.html. Why?
This happens only on my online server, while locally it's all right.
The mod_rewrite module is issuing a redirect to your browser rather than transparently rewriting the url, causing you to see the new url in your browser.
Try removing the http://domain.com portion from your RewriteRule to see if it avoids the redirect to your browser by changing the rule to:
RewriteRule ^([0-9]+)-([^\.]*)\.html$ /economy/article.php?id=$1 [L]
If that fails, you could also use the proxy flag [P] to force apache to transparently fetch the page and return it to your users without the redirect. I don't recommend this approach since it can have security implications but it should work if the above doesn't.
EDIT: To clarify, rewriting the url with a fully-qualified domain rather than a relative uri tells apache that the redirect is on a different server, and therefore it doesn't know that the new url is accessible on the same host without redirecting the client.
Is the following possible?
A user requests the url http://example1.com/example.php and the apache opens http:// example1.com/example.php?id=1
A user requests the url http://example2.com/example.php and the apache opens http:// example2.com/example.php?id=2
But the user should not see the id in his browser adress bar (the user should only see http://example1.com/example.php or http://example2.com/example.php).
You can say the id is invisible for the user but transfered to the example.php.
How can I implement this?
Is that the correct solution?
RewriteEngine On
RewriteRule ^/example.php http://example1.com/example.php$1 [P]
ProxyPassReverse /example.php?id=1 http:// example1.com/example.php
RewriteEngine On
RewriteRule ^/example.php http://example2.com/example.php$1 [P]
ProxyPassReverse /example.php?id=2 http:// example2.com/example.php
You have to understand several concept.
Once the server received the user requested url he can do several things
Take the requested path from the url and use it without modifications. That's the default solution
Map the requested path to any other physical path, things that can be done via Alias, AliasMatch or RewriteRules.
Map the requested path to another website while hiding the fact thtat another website is requested. That's the proxy solution, thta mod_proxy or mod_rewrite could handle (but you do not need that)
Redirect the user to another path, sending him a new url to use, making another client/server roundtrip, with Redirect instructions or mod_rewrite (the swiss knife). But you do no need that.
So you want a server-side only remapping of the requested path.
Let,s say we will use mod rewrite to make this mapping. If you check all tags available in RewriteRule (summary here) the interesting ones are:
passthrough|PT : Forces the resulting URI to be passed back to the URL mapping engine for processing of other URI-to-filename translators, such as Alias or Redirect.
qsappend|QSA: Appends any query string from the original request URL to any query string created in the rewrite target
last|L: Stop the rewriting process immediately and don't apply any more rules. Especially note caveats for per-directory and .htaccess context (see also the END flag)
nocase|NC: Makes the pattern comparison case-insensitive.
details on the PT flag shows that:
The target (or substitution string) in a RewriteRule is assumed to be a file path, by default.
Well, that,s maybe enough for you. But using PT is a good thing, if you have other apache configusation elements you should try to let them apply after mod_rewrite job.
So... assuming you may need to handle some query strings arguments and that this id argument is based on the domain name in the request, and that only the example.php script needs this behavior; you should start your research with such rules (untested):
RewriteEngine On
RewriteCond %{HTTP_HOST} ^example1.com$ [nocase]
RewriteRule ^example\.php$ example.php?id=1 [passthrough,qsappend,last]
RewriteCond %{HTTP_HOST} ^example2.com$ [nocase]
RewriteRule ^example\.php$ example.php?id=2 [passthrough,qsappend,last]
To achieve a single layer of content delivery security, I'm looking into the possibility of obscuring a resource URL via an .htaccess RewriteRule:
RewriteEngine on
RewriteBase /js/
RewriteRule obscure-alias\.js http://example.com/sensitive.js
It would of course be implemented as:
<script type="text/javascript" src="obscure-alias.js"></script>
Because this is not a 301 redirect, but rather a routing scenario similar to that of many of our frameworks we used today, would it be safe to say that this RewriteRule adequately obfuscates the actual URL where this resource is located, or:
Can the destination URL still be found out via some HTTP header sniffing utility
Might a web browser be able to reveal the "Download URL"
I'm going to pre-answer my own questions by saying no to both since the "internal proxy" is taking place on the server-side and not on the client side if I understand it correctly: http://httpd.apache.org/docs/current/mod/mod_rewrite.html. I just wanted to confirm that when Apache goes to serve the destination URL, that it also isn't passing along information to the user agent what the URL was that it rewrote the original request as.
It depends on how you specify the redirect target.
If your http://example.com/ is running on the same server, there will be an internal redirect that is invisible to the client. From the manual:
Absolute URL
If an absolute URL is specified, mod_rewrite checks to see whether the hostname matches the current host. If it does, the scheme and hostname are stripped out and the resulting path is treated as a URL-path. Otherwise, an external redirect is performed for the given URL. To force an external redirect back to the current host, see the [R] flag below.
if the absolute URL points to a remote domain, a header redirect will be performed. A header redirect is visible to the client and will reveal the sensitive location.
To make sure no external redirect takes place, specify a relative URL like
RewriteRule obscure-alias\.js sensitive.js
Note that the sensitive JS file's URL can still be guessed.
To find out whether a request results in a header redirect, log in onto a terminal (eg. on a Linux server) and do
wget --server-response http://www.example.com
If the first HTTP/.... line (there may be more than one) is something that begins with a 3xx, like
HTTP request sent, awaiting response...
HTTP/1.1 302 Moved Temporarily
you are looking at a header redirect.
Possible using proxy throughput.
See http://httpd.apache.org/docs/2.4/rewrite/proxy.html
Also alluded to here as well: mod_rewrite not working as internal proxy