.htaccess rewrite returning Error 404 - apache

RewriteEngine on
RewriteCond %{QUERY_STRING} (^|&)public_url=([^&]+)($|&)
RewriteRule ^process\.php$ /api/%2/? [L,R=301]
Where domain.tld/app/process.php?public_url=abcd1234 is the actual location of the script.
But I am trying to get .htaccess to make the URL like this: domain.tld/app/api/acbd1234.
Essentially hides the process.php script and the get query ?public_url.
However the script above is returning error 404 not found.

I think this is what you are actually looking for:
RewriteEngine on
RewriteCond %{QUERY_STRING} (?:^|&)public_url=([^&]+)(?:$|&)
RewriteRule ^/?app/process\.php$ /app/api/%1 [R=301,QSD]
RewriteRule ^/?app/api/([^/]+)/?$ /app/process.php?public_url=$1 [END]
If you receive an internal server error (http status 500) for that then check your http servers error log file. Chances are that you operate a very old version of the apache http server, you may have to replace the [END] flag with the [L] flag which probably will work just fine in this scenario.
And a general hint: you should always prefer to place such rules inside the http servers (virtual) host configuration instead of using dynamic configuration files (.htaccess style files). Those files are notoriously error prone, hard to debug and they really slow down the server. They are only supported as a last option for situations where you do not have control over the host configuration (read: really cheap hosting service providers) or if you have an application that relies on writing its own rewrite rules (which is an obvious security nightmare).
UPDATE:
Based on your many questions in the comments below (we see again how important it is to be precise in the question itself ;-) ) I add this variant implementing a different handling of path components:
RewriteEngine on
RewriteCond %{QUERY_STRING} (?:^|&)public_url=([^&]+)(?:$|&)
RewriteRule ^/?app/process\.php$ /api/%1 [R=301,QSD]
RewriteRule ^/?api/([^/]+)/?$ /app/process.php?public_url=$1 [END]

I am trying to get .htaccess to make the URL like this: example.com/app/api/acbd1234.
You don't do this in .htaccess. You change the URL in your application and then rewrite the new URL to the actual/old URL. (You only need to redirect this, if the old URLs have been indexed by search engines - but you need to watch for redirect loops.)
So, change the URL in your application to /app/api/acbd1234 and then rewrite this in .htaccess (which I assume in in your /app subdirectory). For example:
RewriteEngine On
# Rewrite new URL back to old
RewriteRule ^api/([^/]+)$ process.php?public_url=$1 [L]
You included a trailing slash in your earlier directive, but you omitted this in your example URL, so I've omitted it here also.
If you then need to also redirect the old URL for the sake of SEO, then you can implement a redirect before the internal rewrite:
RewriteEngine On
# Redirect old URL to new (if request by search engines or external links)
RewriteCond %{ENV:REDIRECT_STATUS} ^$
RewriteCond %{QUERY_STRING} (?:^|&)public_url=([^&]+)(?:$|&)
RewriteRule ^process\.php$ /app/api/%1? [R=302,L]
# Rewrite new URL back to old
RewriteRule ^api/([^/]+)$ process.php?public_url=$1 [L]
The check against REDIRECT_STATUS is to avoid a rewrite loop. ?: inside the parenthesised subpattern avoids the group being captured as a backreference.
Change the 302 (temporary) to 301 (permanent) only when you are sure it's working OK, to avoid erroneous redirects being cached by the browser.

Related

Redirect Loop, Faraway so Close

Basically I need to let through requests to a specific path:
https://domainfoo.com/my-app?param1=ABC&paramY=123
Anything else, let's say,
https://domainfoo.com/aboutus
I need it redirected to
https://moodomain.io/aboutus
I need this last part to be generic.
So Far I have this two rules:
To address the first requirement:
RewriteCond %{HTTP_HOST} ^domainfoo.com$
RewriteCond %{REQUEST_URI} ^/my\-app
RewriteRule ^(my\-app)$ https://domainfoo.com/$1 [L,R=301]
Then as a second rule (if first rule is matched (the L) should redirect and stop right? The thing is apparently it doesn't and then goes into the second rule:
RewriteCond %{HTTP_HOST} ^domainfoo.com$ [OR]
RewriteCond %{HTTP_HOST} ^www.domainfoo.com$
RewriteCond %{REQUEST_URI} !^/my\-app$
RewriteRule (.*)$ https://moodomain.io/$1 [R=301,L]
But I have been dealing for hours with a looped redirect.
Ideas?
You first rule codes the rewriting loop, since you implemented an external redirection where none is required at all. Here is a simplified version:
RewriteEngine on
RewriteCond %{HTTP_HOST} ^domainfoo\.com$
RewriteRule ^/?my-app$ - [END]
RewriteCond %{HTTP_HOST} ^domainfoo\.com$
RewriteRule ^/?(.*)$ https://moodomain.io/$1 [R=301]
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 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).
And if you need to redirect clients "back" to the first domain, as you later stated in the comments to the question, then add an explicit redirection for that:
RewriteCond %{HTTP_HOST} !^domainfoo\.com$
RewriteRule ^/?my-app$ https://domainfoo.com/my-app [R=301]

.htaccess mask original url

I have this URL:
localhost:1001/project/index.html
And if I write this URL:
localhost:1001/project/index.html.twig
I want it to be masked to the first one (localhost:1001/project.index.html) but the URL processed must be the second one (don't know if it is possible).
I have tried all of this but I think all is wrong in my .htaccess in project folder root, because nothing worked as I want:
a)
RedirectMatch 302 /project/index.html.twig /project/index.html
b)
RedirectMatch 301 /project/index.html.twig /project/index.html
c)
RewriteCond %{HTTP_HOST} ^/project/index.html.twig$ [NC]
RewriteRule /project/index.html [R=301,L]
COMMENTS
Process I want to obtain:
I write in the browser: localhost:1001/project/index.html.twig
Somehow I want my .htaccess to convert that URL in the browser to localhost:1001/project/index.html and see that URL in the browser
Internally after that I want to process the original URL: localhost:1001/project/index.html.twig
This probably is what you are looking for if you want an external redirection:
RewriteEngine on
RewriteRule ^/?project/index\.html$ /project/index.html.trig [R=301]
RewriteRule ^/?project/index\.html\.twig$ /project/index.html [END]
In case you want an internal rewrite use that variant:
RewriteEngine on
RewriteRule ^/?project/index\.html\.twig$ /project/index.html [R=301]
RewriteRule ^/?project/index\.html$ /project/index.html.trig [END]
These rules should work likewise, in the http servers host configuration or in a dynamic configuration file (".htaccess" style file). You should definitely prefer the first option if you have access to it. If you need to use a dynamic configuration file then take care that it's interpretation is enabled at all and that it is located in the host's DOCUMENT_ROOT folder.
In case you receive a server internal error (http status 500) using that rule chances are that you operate an old version of the apache http server. You will find a definite hint on an unknown [END] flag in the http servers error log file in that case. Try using the older [L] flag in that case, it will probably work the same here, though that depends on your setup.

Why is this RewriteRule altering QUERY_STRING, but leaving REQUEST_URI untouched?

I have a copy of Concrete5, a PHP-based CMS, running on example.com.
Concrete5 comes with the following basic instructions for pretty URLs (redirecting all URLs to a central index.php)
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} !^/c5.7
RewriteRule ^.*$ c5.7/$0 [L] # Concrete5 is running in the c5.7/ subdirectory
</IfModule>
Pretty straightforward.
Now I have a certain set of URLs that take the form
/product/{productname}
that I need to forward to the Concrete5 (virtual) URL
/products/details?name={productname}
That URL is set up and works as expected when I enter it manually in the browser.
So I added a line to the htaccess file and it now looks like this:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
# New rule for products
RewriteCond %{REQUEST_URI} ^/product/
RewriteRule ^product/(.+)$ /products/details?name=$1 [QSA]
RewriteCond %{REQUEST_URI} !^/c5.7
RewriteRule ^.*$ c5.7/$0 [L]
</IfModule>
I can confirm the RewriteRule gets triggered when I choose a random, external URL as the redirection target.
But whenever it is an internal redirect like above, what happens is, I get a 404 inside Concrete5. When I inspect what was passed to it, I see:
REQUEST_URI: /product/my-random-product
QUERY_STRING: name=my-random-product
So it appears that the rule is triggered and does some rewriting, but REQUEST_URI remains unchanged!
Why?
Is it because PHP 7.1 is running via CGI?
I have tried a zillion variations and all the flags in the book, with little success.
The REQUEST_URI in PHP is not the same as the REQUEST_URI within mod_rewrite, so you can't do it like this. In PHP it always contains the original URL. So you can't change it like this if your CMS is working off that.
You should set up your CMS to use the URLs you want, rather than trying to augment your CMS's URL rewriting like this.
If you inspect REDIRECT_URL in PHP you will see the last rewritten URI.
REQUEST_URI in PHP will always be the original request URI.
Because this is already explained by LSerni and SuperDuperApps, I won't elaborate.
Instead, I'm offering a quick solution: modify the REQUEST_URI and add a name parameter in PHP instead of in .htaccess.
Add the following code to the start of your Concrete5 index.php to make sure that REQUEST_URI is modified
before any Concrete5 code runs:
if(preg_match('-^/product/([^?]*)-',$_SERVER['REQUEST_URI'],$matches)){
$_SERVER['REQUEST_URI'] = '/products/details';
$_GET['name'] = $matches[1];
}
Your setup works on a PHP 7.1 machine (without Concrete5). It does call a script I just put in, which is in /c5.7/products/details. So the Apache part is working.
Inside the script, I see that REQUEST_URI is the old value prior to the rewrite.
So its value is normal and it not being rewritten is a red herring - it isn't supposed to be rewritten. The 404 error must be due to something else.
Your Concrete5 routing should support the real URL, not just the virtual one, because C5's routing relies itself on REQUEST_URI. If this is so, you need to create a route for your short URLs
Route::register('/product/{productname}' ...)
and an appropriate controller to get the parameters and invoke the "old" controller.
One possibility using .htaccess could be this, but I'm not too sure it will work since REQUEST_URI is still left unchanged:
# New rule for products
RewriteCond %{REQUEST_URI} ^/product/
RewriteRule ^product/(.+)$ c5.7/products/details?name=$1 [L,QSA]
Otherwise you need to do an external redirect, which will disclose the URL in the browser:
RewriteRule product/(.*)$ http://.../products/details?name=$1 [QSA]
See also this other question.

Apache rewrite rule that ignores query/parameters, always redirects based on path

I'm trying to create a rewrite rule that will ignore any additional URL query/parameters and just redirect based on the path.
My company has a Wifi Hotspot service that does some DNS routing trick to force people to login before they can use it. Unfortunately when folks get disconnected from the WiFi and dropped back to their normal cell data service sometimes a URL request is still sent to our host, and it shows up as:
www.ourwebsite.com/login?dst=http://www.google.com/m?client=ms-android-verizon&source=android-home
I already wrote a set of rules to take care of base paths of /login and /login/ to redirect to our homepage,
RewriteCond %{THE_REQUEST} ^.*\/login/\ HTTP/
RewriteRule ^(.*)login/?$ "/$1" [R=301,L]
RewriteCond %{THE_REQUEST} ^.*\/login\ HTTP/
RewriteRule ^(.*)login?$ "/$1" [R=301,L]
but I am having trouble coming up with an appropriate string to ALWAYS redirect based souly on the path, and ignore any query parameters that may or may not come after.
Any help would be appreciate! Thanks in advance.
If I understood right, something like this should do it:
Options +FollowSymLinks -MultiViews
RewriteEngine On
RewriteBase /
RewriteRule ^login /? [R=301,L]
This rule-set will redirect to root as long as the incoming URL is something like:
http://www.ourwebsite.com/login?any_query
From Apache 2.4.0 on you can apply the QSD-flag to the rule.
When the requested URI contains a query string, and the target URI does not, the default behavior of RewriteRule is to copy that query string to the target URI. Using the [QSD] flag causes the query string to be discarded.
-- https://httpd.apache.org/docs/2.4/rewrite/flags.html#flag_qsd
When using this flag for earlier Apache versions you'll cause an 500 Internal Server Error.

How to prevent mod_rewrite from rewriting URLs more than once?

I want to use mod_rewrite to rewrite a few human-friendly URLs to arbitrary files in a folder called php (which is inside the web root, since mod_rewrite apparently won't let you rewrite to files outside the web root).
/ --> /php/home.php
/about --> /php/about_page.php
/contact --> /php/contact.php
Here are my rewrite rules:
Options +FollowSymlinks
RewriteEngine On
RewriteRule ^$ php/home.php [L]
RewriteRule ^about$ php/about_page.php [L]
RewriteRule ^contact$ php/contact.php [L]
However, I also want to prevent users from accessing files in this php directory directly. If a user enters any URL beginning with /php, I want them to get a 404 page.
I tried adding this extra rule at the end:
RewriteRule ^php php/404.php [L]
...(where 404.php is a file that outputs 404 headers and a "Not found" message.)
But when I access / or /about or /contact, I always get redirected to the 404. It seems the final RewriteRule is applied even to the internally rewritten URLs (as they now all start with /php).
I thought the [L] flag (on the first three RewriteRules) was supposed to prevent further rules from being applied? Am I doing something wrong? (Or is there a smarter way to do what I'm trying to do?)
[L] flag should be used only in the last rule,
L - Last Rule - Stops the rewriting process here and don’t apply any more rewriting rules & because of that you are facing issues.
I had similar problem. I have a content management system written in PHP and based on Model-View-Control paradigm. The most base part is the mod_rewrite. I've successfully prevent access to PHP files globally. The trick has name THE_REQUEST.
What's the problem?
Rewriting modul rewrites the URI. If the URI matches a rule, it is rewritten and other rules are applied on the new, rewritted URI. But! If the matched rule ends with [L], the engine doesn't terminate in fact, but starts again. Then the new URI doesn't more match the rule ending with [L], continues and matches the last one. Result? The programmer stars saying bad words at the unexpected 404 error page. However computer does, what you say and doesn't do, what you want. I had this in my .htaccess file:
RewriteEngine On
RewriteBase /
RewriteRule ^plugins/.* pluginLoader.php [L]
RewriteCond %{REQUEST_URI} \.php$
RewriteRule .* index.php [L]
That's wrong. Even the URIs beginning with plugins/ are rewritten to index.php.
Solution
You need to apply the rule if and only if the original - not rewritten - URI matches the rule. Regrettably the mod_rewrite does not provide any variable containing the original URI, but it provides some THE_REQUEST variable, which contains the first line of HTTP request header. This variable is invariant. It doesn't change while rewrite engine is working.
...
RewriteCond %{THE_REQUEST} \s.*\.php\s
RewriteRule \.php$ index.php [L]
The regular expression is different. It is not applied on the URI only, but on entire first line of the header, that means on something like GET /script.php HTTP/1.1. But the critical rule is this time applied only if the user is explicitly requesting some PHP-script directly. The rewritten URI is not used.