1.
I have a .haccess file that requires you do be accessing from a certain IP address:
<RequireAll>
Require ip XX.XX.XX.XX.XX YY.YY.YY.YY.YY ZZ.ZZ.ZZ.ZZ.ZZ
</RequireAll>
If someone tries to access the website from a IP other then X, Y, or Z then they get an error 403 Forbidden page. I have customized it using the following:
ErrorDocument 403 /.forbidden.php
2.
If someone tries to access a restricted file in the same directory (even if they are from ip addresses X, Y, or Z) then again they prompted with the SAME custom 403 Forbidden page.
My Question
How can I have two different custom 403 Forbidden pages based on why they are forbidden from accessing? In example 1 the forbidden page would /.wrongip.php and in example 2 the forbidden page would /.restricted.php
If this is about the extent of what you are doing then it is fine but if you are going to be doing a lot of redirecting I would consider doing this in PHP, but I digress. You are going to have to use Apache (2.4) module mod_rewrite to rewrite rules and conditions for the IP restriction portion. I would leave your custom 403 Forbidden as is for handling the other cases of that status code. If you are on shared hosting this module is usually enabled by most hosting providers by default.
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^111.222.333.444$
RewriteRule ^(.*)$ /.wrongip.php [L]
You will likely avoid confusion if you keep rule rewrites up near the top of your .htaccess file. You only need the RewriteEngine On line once in your file. RewriteCond is one of the conditions for the rule immediately following. You could have multiple conditions mapped to a single rule (using [OR] flag; AND behavior is by default).
In this solution, the ^ character indicates the start of a string. Likewise, $ indicates the end. So, ^(.*)$ is a wildcard and would match any file accessed on your server. Preceded by a single space separator, the /.wrongip.php portion indicates your custom error page to be redirected to. [L] is the flag to indicate the Apache server should stop processing other rules once it matches that one. Use this unless you are using multiple rules to construct a single URL, otherwise you may cause yourself a headache.
There is an additional flag, [R], that I would suggest being aware of and trying to use when possible for easier use in maintaining good practice with HTTP response codes. These help with search rankings and I would recommend specifying a 403 response because by default it will throw a 302 error which can negatively effect ranking over time. Changing the rule to RewriteRule ^(.*)$ /.wrongip.php [R=403,L] would cause the Apache server to issue an HTTP redirect to the browser (to /.wrongip.php) and communicate a 403 Forbidden error in the header. Since my example has all pages redirecting to /.wrongip.php for non-whitelisted IPs, most likely even /.wrongip.php itself, I think in your specific case the [R] flag would result in an HTTP redirect loop where they would keep requesting /.wrongip.php. In this case you should omit the [R] flag, this will cause the Apache server to do an internal redirect.
Without the [R] flag, the client won't have any idea that this redirect went on (hence internal), so you should still emulate the error code in the header of your /.wrongip.php file using PHP.
I have not tested it, but I assume something like
<Directory /var/www/mysite>
ErrorDocument 403 /.restricted.php
<RequireAll>
Require ip XX.XX.XX.XX.XX YY.YY.YY.YY.YY ZZ.ZZ.ZZ.ZZ.ZZ
ErrorDocument 403 /.wrongip.php
</RequireAll>
</Directory>
could do the trick.
Have a look at
https://httpd.apache.org/docs/trunk/custom-error.html and https://httpd.apache.org/docs/trunk/mod/core.html#errordocument for more information on how such configurations work.
Related
weird one but the referer policy is currently creating issues on my website if the domain has a . on the end, for example:
domain.uk - works fine
domain.uk. - has CORS errors
It seems the . on the end os being treated as part of the domain so considered a different origin. Seems to only be a problem in Chrome. Possibly a Chrome bug?
Thought perhaps I could fix this in my .htaccess by setting up a redirect, but the .htaccess cannot do it as it can only match after the domain, and the . is being treated as part of the domain.
Any suggestions?
It seems the . on the end os being treated as part of the domain so considered a different origin. Seems to only be a problem in Chrome. Possibly a Chrome bug?
It is part of the domain. The trailing dot indicates a fully qualified domain name. If you are only seeing different behaviour in Chrome then maybe Chrome is just being more strict - it's not a bug.
Try https://stackoverflow.com./ (for instance) - you'll probably appear logged out (as the cookies are not passed).
Thought perhaps I could fix this in my .htaccess by setting up a redirect, but the .htaccess cannot do it as it can only match after the domain, and the . is being treated as part of the domain.
You can do it in .htaccess. The dot is sent as part of the Host header (since it is part of the domain) - which is available in the HTTP_HOST server variable. Ordinarily, you'd do this as part of your canonical (www vs non-www / HTTP to HTTPS) redirect, but you could do something like the following using mod_rewrite to remove the trailing dot on the requested hostname:
RewriteEngine On
RewriteCond %{HTTP_HOST} (.+)\.$
RewriteRule ^ https://%1%{REQUEST_URI} [R=301,L]
The %1 backreference contains the hostname, less the trailing dot, that is captured in the preceding condition.
UPDATE:
I am using Wordpress so it already has some rewrite rules in the htaccess, ... can you advise on how to add your rewrites
You need to place this redirect before the existing WordPress directives (ie. before the # BEGIN WordPress section), near the top of the file.
You do not need to repeat the RewriteEngine On directive since that already occurs later in the WordPress section. (If there are multiple RewriteEngine directives then the last instance wins and controls the entire file.)
I like to simplify code if possible but I am not to familiar with .htaccess, I had error documents redirect rule hard coded
ErrorDocument 403 http://example.com/error/404
Then I made it
ErrorDocument 403 http://%{HTTP_HOST}/error/404
my question is so that the .htaccess does not have to be manually modified is there a way to tell it if its https or http? because the above example if i use https ill have to hard code https I would like to check automatically.
Don't use an absolute URL in the ErrorDocument directive
ErrorDocument 403 http://example.com/error/404
You shouldn't be using an absolute URL in the ErrorDocument directive to begin with! This will trigger a 302 response (ie. a 302 temporary redirect) to the target URL. So, this won't send a 403 (or 404) response back to the user-agent on the first response.
(This format of the ErrorDocument directive should only be used in very exceptional circumstances since you also lose a lot of information about the URL that triggered the response in the first place.)
To internally serve a custom error document on the same server, this should be a root-relative URL, starting with a slash (no scheme or hostname). For example:
ErrorDocument 403 /error/404
However, /error/404 is unlikely to be a valid end-point. This should represent a valid resource that can be served. eg. /error/404.html.
(And this naturally gets round the issue of having to specifying HTTP vs HTTPS.)
To answer your specific question...
because the above example if i use https ill have to hard code https
(Although, arguably, you should be HTTPS everywhere these days.)
However, to do what you are asking, you could do something like the following using the REQUEST_SCHEME server variable, for example:
ErrorDocument 403 %{REQUEST_SCHEME}://%{HTTP_HOST}/error/404
Or, if the REQUEST_SCHEME server variable is not available then you can construct this from the HTTPS server variable using mod_rewrite and assign this to an environment variable. For example:
RewriteEngine On
RewriteCond %{HTTPS}s ^on(s)|
RewriteRule ^ - [E=PROTO:http%1]
ErrorDocument 403 %{reqenv:PROTO}://%{HTTP_HOST}/error/404
The %1 backreference contains s when HTTPS is on and is empty otherwise. So the PROTO environment variable is set to either http or https.
This does assume that the SSL is managed by the application server and not a front-end proxy (like Cloudflare Flexible SSL etc.).
I've been using a set of redirect rules for a while that have been working perfectly.
I've recently expanded a part of my website and need to change the ending of a certain URL.
Old URL: /clan/{query-string}/tracking/war
New URL: /clan/{query-string}/tracking/warlog
I've changed my .htaccess file so the new URL works, but I need the old URL to redirect to the new one.
Currently, this is how I'm redirecting in .htaccess:
# Rewrite Clan Tracking-Warlog URL
RewriteEngine On
RewriteCond %{THE_REQUEST} /clanTracking_main.php\?name=([^\s]+) [NC]
RewriteRule ^.+$ /clan/%1/tracking/warlog [L,R]
RewriteRule ^clan/([^/]+)/tracking/warlog clanTracking_main.php?name=$1 [L]
It works perfectly but I just need help with the redirection.
Thanks for your help in advance!
I'd say the first rule below is what you ask...
I also made some other modifications which appeared to make sense to me...
# Rewrite Clan Tracking-Warlog URL
RewriteEngine On
# redirect old to new
RewriteRule ^/?clan/([^/]+)/tracking/war$ /clan/$1/tracking/warlog [R=301]
# pick name from get argument and redirect
RewriteCond %{QUERY_STRING} (?:^|&)name=([^\s]+)(?:&) [NC]
RewriteRule ^/?clanTracking_main\.php$ /clan/%1/tracking/warlog [R=301]
# rewrite to php
RewriteRule ^/?clan/([^/]+)/tracking/warlog$ clanTracking_main.php?name=$1 [END]
It is a good idea to start out with a 302 temporary redirection and only change that to a 301 permanent redirection later, once you are certain everything is correctly set up. That prevents caching issues while trying things out...
In case you receive an internal server error (http status 500) using the rule above then chances are that you operate a very old version of the apache http server. You will see a definite hint to an unsupported [END] flag in your http servers error log file in that case. You can either try to upgrade or use the older [L] flag, it probably will work the same in this situation, though that depends a bit on your setup.
This implementation will work likewise in the http servers host configuration or inside a distributed configuration file (".htaccess" file). Obviously the rewriting module needs to be loaded inside the http server and enabled in the http host. In case you use a distributed configuration file you need to take care that it's interpretation is enabled at all in the host configuration and that it is located in the host's DOCUMENT_ROOT folder.
And a general remark: you should always prefer to place such rules in the http servers host configuration instead of using distributed configuration files (".htaccess"). Those distributed configuration files add complexity, are often a cause of unexpected behavior, hard to debug and they really slow down the http server. They are only provided as a last option for situations where you do not have access to the real http servers host configuration (read: really cheap service providers) or for applications insisting on writing their own rules (which is an obvious security nightmare).
I am a web developer. I have developed a news portal for my client. But the URLs of the articles are dynamic and I need to redirect it to a static URL for SEO purpose.
The current URL : https://example.com/single-post.php?id=1&category=news&title=this-is-a-title
Desired URL : https://example.com/news/this-is-a-title
Someone please help me.
I have wrote this :
RewriteCond %{QUERY_STRING} (?:^|&)id=(\d+)(?:&|$)
RewriteCond %{QUERY_STRING} (?:^|&)title=([^&]+)(?:&|$)
RewriteRule ^/?single-post\.php$ /%2/%1 [R=301]
RewriteRule ^/?(.*)/(\d+)$ single-post.php?title=$1&id=$2 [END]
But the URL output is not what I expected. It is like :
https://example.com/this-is-title/?id=1&title=this-is-title
The only title came first without the id and then the old format came again after the slash. I can't understand what is going on here.
What you ask actually is not possible. There is no way for the rewriting module to somehow magically guess the numerical ID of that object you request. What you can actually do is publish URL in the style of https://example.com/news/1/this-is-a-title. Notice the ID in there, that is what is usally done. For that his should point you into the right direction:
RewriteEngine on
RewriteRule ^/?news/(\d+)/(.*)/?$ /single-post.php?id=$1&category=news&title=$2 [END]
Typically your application logic will only need the numerical ID of the requested object to fetch it from your database. So you typically can silently drop the title in the internal rewriting which makes things even more simple:
RewriteEngine on
RewriteRule ^/?news/(\d+) /single-post.php?id=$1&category=news [END]
In case you receive an internal server error (http status 500) using the rule above then chances are that you operate a very old version of the apache http server. You will see a definite hint to an unsupported [END] flag in your http servers error log file in that case. You can either try to upgrade or use the older [L] flag, it probably will work the same in this situation, though that depends a bit on your setup.
This rule will work likewise in the http servers host configuration or inside a dynamic configuration file (".htaccess" file). Obviously the rewriting module needs to be loaded inside the http server and enabled in the http host. In case you use a dynamic configuration file you need to take care that it's interpretation is enabled at all in the host configuration and that it is located in the host's DOCUMENT_ROOT folder.
And a general remark: you should always prefer to place such rules in the http servers host configuration instead of using dynamic configuration files (".htaccess"). Those dynamic configuration files add complexity, are often a cause of unexpected behavior, hard to debug and they really slow down the http server. They are only provided as a last option for situations where you do not have access to the real http servers host configuration (read: really cheap service providers) or for applications insisting on writing their own rules (which is an obvious security nightmare).
UPDATE:
in your comment to this answer you suggest to also do an explit redirection in case the target URL is used on the client side. Here is a variant of version 2 above which adds that redirection:
RewriteEngine on
RewriteCond %{QUERY_STRING} (?:^|&)id=(\d+)(?:&|$)
RewriteRule ^/?single-post\.php$ /news/%1 [R=301]
RewriteRule ^/?news/(\d+) /single-post.php?id=$1&category=news [END]
A variant of version 1 would look similar:
RewriteEngine on
RewriteCond %{QUERY_STRING} (?:^|&)id=(\d+)(?:&|$)
RewriteCond %{QUERY_STRING} (?:^|&)title=([^&]+)(?:&|$)
RewriteRule ^/?single-post\.php$ /news/%1/%2 [R=301]
RewriteRule ^/?news/(\d+) /single-post.php?id=$1&category=news [END]
Is is a good idea to start with a 302 redirection first. And only change that to a 301 redirection once everything works fine. That saves you from hassles with client side caching while you are still trying things out.
We have a http > https redirect on our 'top' level:
example.com/top/
Now for a sub-directory of /top/:
example.com/top/sub/
I want to preserve whatever protocol is requested there.
So if it's http://example.com/top/sub/this.php I want it to stay as 'http'
And if it's https://example.com/top/sub/this.php I want it to stay as 'https'
Currently I have an .htaccess file in the /top/sub/ directory with:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,END]
Which is doing exactly what I need it to be doing, so in terms of all the requests being sent to the sub-directory it's perfect.
The issue is I'm getting an error message in the error_log reporting this:
[REWRITE] detected external loop redirection with target URL: http://example.com/top/sub/this.php, skip.
I understand why I'm getting this message, because every time a HTTP request is made it's matching this condition, I just don't know how to stop it. I tried using the 'END' parameter to force only one redirect - but this doesn't seem to be working, or at least not working the way I expected it to.
All I want is for the protocol to remain the same as requested for /top/sub/ - the issue is the /top/ redirect sending everything to HTTPS.
Is this possible?
I would be interested to know if there is actually a way to preserve a protocol without creating a loop, however I was able to achieve what I was after by just adjusting the redirect in /top/ to only redirect pages that didn't match /top/sub/ - I really should have thought of that as a solution earlier.
Hope that can help someone.