I have an rewrite recursion error somewhere on my website that Google Bot caused, but I can't find the url that caused it because my Loglevel is low. I raised it but it has not happened again so far.
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
All Rewriterules look fine to me and have the [L] flag, except this one.
I can't quite understand it. It is from the open source shop system Magento.
As far as I can tell it does nothing but sets the environment variable E. But isn't that a very stupid way of doing that? Shouldn't you use SetEnv if that was the goal?
Symfony developers Group has a good answer for it. I quote:
it looks like your hosting is running php as a fcgi, not a php5_module, like your localhost does. ( phpinfo - Server API: CGI/FastCGI )
the point is that php5_module automatically handles HTTP_AUTHORIZATION headers, but fcgi_module does not.
solution is simple - add this line to your .htacces on your hosting server:
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]
It worked for me
This line is setting the environment variable to the value of user authentication string - essentially setting a variable rather than constant value. As far as I know, SetEnv and SetEnvIf only allow you to set an environment variable to a predetermined constant.
The variable being set is actually HTTP_AUTHORIZATION, not E. I would guess this is part of the user authentication process.
Related
I'm trying to code a F3 ("Fat Free Framework") application using PhpStorm and XAMPP on Linux.
In order to make use of the .htaccess file provided by F3 necessary for the RewriteEngine (see the comments as why this is wrong), I launch my code using the following special run configuration :
I launch the run configuration, which starts the Web Server. I open a browser and go to http://localhost:8000/ . I can see the content, and the links work and I can navigate from page to page, per the routes defined.
But none of the CSS is there. If I click on "view-source" and click on the CSS link, I get the 404 Not Found message from F3. So, it seems that for some reason, F3 is blocking CSS files.
The beginning of the webpage is as follow:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>A title</title>
<link href="{{#BASE}}/f3style.css" rel="stylesheet" type="text/css" />
</head>
Although the #BASE variable is empty in my case. The "f3style.css" file is really at the root of my web directory currently.
I use the default .htaccess file recommended by F3:
RewriteEngine On
# Uncommenting the following line has no effect
# RewriteBase /
RewriteRule ^(app|tmp)\/|\.ini$ - [R=404]
RewriteCond %{REQUEST_FILENAME} !-l
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .* index.php [L,QSA]
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]
(Again, see the comments as to why the .htaccess file is irrelevant here)
And here are my routes. They are in "index.php":
<?php
$f3 = require('lib/base.php');
// Routes
require 'controller.php';
$f3->route('GET /index.php', 'Controller->showMain');
$f3->route('GET /', 'Controller->showMain' );
$f3->route('GET /items/#item', 'Controller->showItem');
$f3->run();
Any idea what I should look for?
Based on the screenshot you are using PHP's built-in web server. The thing is: it does not support .htaccess. Therefore all HTTP requests go to your router script (framework/index.php -- part of the F3 app I guess).
I'm not familiar with how F3 routing works, but I'd assume it's the same as any other: it goes through all registered routes/endpoints and if no match found it will report "404 Not Found" response.
Since there are no rules from .htaccess in place to filter out requests for such static/existing files (css/jpg/png/js etc), the request goes through your index.php, through the whole routing table and it's F3 that reports that 404 error back to the browser (when no matching route was found).
There are a few possible solutions here:
Create a separate route(s) for such static resources and serve them there from your F3 code (your code needs to locate a file and send a response with the right headers etc.)
Not really worth implementing it this way TBH (since it's just to handle this specific situation / under PHP's web server).
Do a pre-filter and ignore any requests to such static files. When using PHP's web server it's a matter of returning false in the router script (which tells PHP to use built-in web server code to serve such request). Look at the sample from the following link and add a similar one to your code: https://www.php.net/manual/en/features.commandline.webserver.php#example-426
if (preg_match('/\.(?:png|jpg|jpeg|gif|css)$/', $_SERVER["REQUEST_URI"])) return false;
NOTE: you can add it right into the existing index.php like you did (at the top, after all use lines but before actual code lines) but this means that you are hardcoding such specific-to-PHP's-web-server-only logic into the script that can run under a proper web server.
Instead I suggest creating a separate router script (e.g. php-router.php and use it instead of index.php from your screenshot) where you will do this and if execution will pass that condition, only then call the code from your real index.php (i.e. require './index.php'; or alike)
Why not use Apache web server from your XAMPP to serve the whole site in the first place?
Once Apache is running it handles ALL of the virtual hosts (that you can access via fake domain name in your OS' hosts file or by having website on a custom dedicated port) -- no need to launch each site separately.
Apache obviously fully supports .htaccess and always better/more features/more close to the production environment than for-dev-only PHP's built-in web server (mod_rewrite and other modules).
I have been look around trying to get this working right for a while now, and finally bit the bullet and posted here.
I've got a LAMP stack with ModSecurity using the OWASP core rule set (v 2.2.5) and just installed Wordpress. I expected conflicts with ModSecurity, but I haven't been able to ignore or work aroudn the only error I've encountered so far.
The Apache error.log file and the modsec_audit.log both list the same error:
ModSecurity: Rule 7f5d9a449228 [id "950901"][file "/etc/modsecurity/owasp-crs/activated_rules/modsecurity_crs_41_sql_injection_attacks.conf"][line "77"] - Execution error - PCRE limits exceeded (-8): (null).`
I've tried creating a new .conf file where the crs conf files are located containing
<LocationMatch .*>
<IfModule mod_security2.c>
SecRuleRemoveById 950901
</IfModule>
</LocationMatch>
and even removed the IfModule statement and then LocationMatch statement when it didn't work.
Finally I resorted to commenting out lines 76 and 77 in the .conf file, and the error still appeared. This also had no effect.
Only changing SecRuleEngine to Off in modsecurity.conf finally let me access the page. Of course this defeats the purpose of ModSec.
Where am I going wrong?
Try adding this to your php.ini file (or included conf file):
pcre.backtrack_limit = 10000000
pcre.recursion_limit = 10000000
And then this to your modsecurity.conf:
SecPcreMatchLimit 150000
SecPcreMatchLimitRecursion 150000
This should allow for recursion without having to fully disable mod_security.
If I try to visit an invalid image url e.g. example.com/images/non-existent-image an error is thrown: Symfony\\Component\\Routing\\Exception\\ResourceNotFoundException
How should I prevent this, is there a specific route(-requirement) I should add, or should I use something like a .htaccess rule?
Thanks
If it was a permission error you would get sth like permission denies. Check again the path...also check that you have placed the folder images in the proper directory in server (try moving images/ in the same directory where directory WEB-INF is..files under WEB-INF cannot be accessed for security reasons)
Okay the answer to this question is twofold.
First of all: Yes, static resources should not be requested via the front controller (as per thecatontheflat's comment). Symfony has a rule in the .htaccessfile distributed with the standard edition:
# If the requested filename exists, simply serve it.
# We only want to let Apache serve files and not directories.
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule .? - [L]
As it turned out, my problem was somewhere else. It is normal for symfony to throw the ResouceNotFoundException. However , this error should be caught and should create a 404 instead. This was not happening because I was using IS_GRANTEDin my error template. (Also see stof's comment here)
I try to use AvalancheImagineBundle and I don't understand how it can works in production environment.
The default cache_prefix is media/cache. All cached images will be in the myProject/web/media/cache directory and it's also a Symfony2 route :
Name Method Scheme Host Path
_imagine_thumbnail GET ANY ANY /uploads/cache/{filter}/{path}
If I do a test on this url "http://my-project.fr/app.php/", the bundle works fine:
The first time, I try to show the /app.php/media/cache/thumbnail/profile.jpg picture. The Symfony2 route is caught. The bundle return the cropped picture and cache it.
The second time, the route is caught again and the bundle redirects me to the cached picture /media/cache/
In short, the first time /app.php/media/cache -> bundle, and second time /media/cache -> assets
But in production environment, app.php is missing so how the bundle can do the difference ?
I'm not familiar with lighttpd, so I can only point you to a direction where to look.
The "switch" is done via .htaccess, here are two relevant lines and explanation:
# If request is an existing file, then it's simply returned
RewriteCond %{REQUEST_FILENAME} !-f
# Else the request is pushed to the app.php front controller
RewriteRule ^(.*)$ app.php/$1 [QSA,L]
I think you're missing first part of this config.
P.S. Note that app.php isn't actually missing, it's just "hidden".
The -f option does not exist in lighttpd so I switch to apache2 and everything work well.
Like the question says, if I have a request for a page on my site like this
http://somename.something.here/Dada.aspx
to something like this
https://somename.something.here/Dada.aspx
I prefer to (a) not redirect local connections (to ease development under VS), and (b) use a UriBuilder instead of a string.Replace as it's a bit more exact.
if (!Request.IsLocal && !Request.IsSecureConnection) {
var ub = new UriBuilder(Request.Url);
ub.Scheme = Uri.UriSchemeHttps;
ub.Port = -1; // use default port for scheme
Response.Redirect(ub.Uri.AbsoluteUri, true);
return;
}
You tagged ASP.NET so I assume you use IIS. Create a file in your Web Root of your web site, call it SSL_Redirect.htm or something like that. Put this Javascript in there:
<Script language="JavaScript">
<!-- begin hide
function goElseWhere()
{
var oldURL = window.location.hostname + window.location.pathname;
var newURL = "https://" + oldURL;
query = '' + window.location;
position = query.indexOf('?');
if (position > -1)
{
query = query.substring(position + 1);
newURL = newURL + "?" + query;
}
window.location = newURL;
}
goElseWhere();
// end hide -->
</script>
Now, go to the properties of your Web Site. Go to the Customer Errors Tab, look for the 403.4 error, edit it. Change it to use a URL of /SSL_Redirect.htm (or whatever you named it). Now, in the IIS Admin, find that file, SSL_Redirect.htm, right click, go to properties. Go to File Security and uncheck Require SSL for that particular file.
You're done.
I think it is as simple as witing
Response.Redirect("https://somename.something.here/Dada.aspx");
I remember dealing with the same issues a while back. I wanted to make sure certain pages were over https, while the rest were using http. I also wanted to be sure that once the visitor left the secure page for pages that didn't need to be secure they would flip back to http. To accomplish this I explored two options:
The first option was that I could use the free .NET URLRewriter project to rewrite specific pages outlined in the configuration file:
# HTTP REQUIRED PAGES
RewriteCond %{HTTPS} =on
RewriteCond %{REQUEST_URI} !(/login\.aspx|/securepage\.aspx).*$ [NC]
RewriteCond %{HTTP_HOST} (.+)
RewriteRule ^(.*)$ http://%3$1 [R=301,L]
# HTTPS REQUIRED PAGES
RewriteCond %{HTTPS} =off
RewriteCond %{REQUEST_URI} (/login\.aspx|/securepage\.aspx).*$ [NC]
RewriteCond %{HTTP_HOST} (.+)
RewriteRule ^(.*)$ https://%3$1 [R=301,L]
Using this configuration I can ensure only the two pages are secure, while the rest will be insecure. I had fine results with this option.
The second option came after I located a complete solution dedicated to handling this very problem. The company is SanibelLogic and they have a product called SSLRedirect. This HTTPModule based solution does exactly what I needed. It does cost a little money but if you want something simple to implement and manage this might fit the bill. They even offer the source code if you want to edit anything about it...
I used both options for many months but ended up using the SSLRedirect product for its simplicity.
I hope this helps...
I just had the same problem but I found different solutions using purely IIS configuration.
There are two ways:
(1) The simple way is to just rename your MyWebApp to MyWebAppSSL for example. Enable SSL for the latter. Then create a new empty folder in your IIS called like the old MyWebApp. Click the Properties for MyWebApp, and under "Directory" choose "A redirection to a URL" and put http://MyServer/MyWebAppSSL there. It is recommended to enable "A permanent redirection" for it. You don't need to click the "Create web application" button for MyWebApp by the way as it is not a web application but merely does redirect.
(2) The simple way has of course the disadvantage that from now on your application will run under a new name (with the -SSL ending in this example). If we need to keep it running under the same old name, it will also be possible by merely configuring IIS but we have to proceed a little bit differently. We will have to set up a new web space on our IIS running on a different port. I found this good description: How to Auto-Redirect to a SSL-secured Site in IIS.
Send a Redirect Header (302) to the browser.
Example:
Response.Redirect("WebForm2.aspx")
Article on the difference between Server.Transfer and Response.Redirect