I have Apache 2.2 set up to accept PUTs and funnel them to a specific handler script /put.php as shown below in the Directory Directive in httpd.conf:
<Directory />
Options FollowSymLinks
AllowOverride All
Script PUT put.php
</Directory>
This has always worked, no matter the request as long as the method is PUT in the past. I used curl to validate this using a request URL of "/" which pointed to index.html.
I recently found a need to convert index.html to index.php to do some session handling, and suddenly my PUT requests stopped being handled by /put.php as soon as the file became index.php.
I realize that one solution is to point all PUT requests to /put.php, but we have an app that is hard coded to send them to / which doesn't work anymore since the change to index.php.
It'd be nice to be able to get index.php to still send PUT requests to it to /put.php, but I haven't been able to find a way.
The apache logs show that the PUT requests are being handled properly (201 response and no error), but the behavior is just that it never redirects to /put.php as it used to.
I also tried leaving the page as html, and adding the following line to the httpd.conf prior to the "Script PUT /put.php" directive:
AddType application/x-httpd-php .html
which then parsed the html page with the php parser, but then I got the same effect (No redirection to put.php) as when the page was called index.php and parsed by php.
Anyone have any ideas or encountered this before? It is as if when I turn index.html into index.php and send to the php parser it is unable to redirect any longer using the "Script PUT" directive.
Related
Let's take a proper URL to a php-Page like:
https://secure.php.net/ChangeLog-7.php
If we now add a trailing slash and some random garbage like this:
https://secure.php.net/ChangeLog-7.php/nonexistentfolder/anotherfile.html
the URL still works. In my opinion, it should have generated a 404-Error because "nonexistentfolder" is a folder not existing on the remote server as well as "anotherfile.html" is a non existent file.
This seems to happen generally, independent from webserver or rewrite-rules, so it seems to have its source in the PHP-Webserver-Module.
I do understand, what PATH_INFO is, but i do not understand, why calling such a URL does not generate a 404 response which would be the case if the existing file in the URL would be .html (and not .php).
How do people deal with this i.e. to avoid such bogus links making their way to search engines or alike?
Thanks!
According to the Apache Documentation, the Setting for AcceptPathInfo depends on the Handler used to answer the request. Handlers to answer requests for .html and .php files are different and it seems the default of the handler for .php is to accept PATH_INFO.
If you want the webserver to reply with a 404-Status, when the url is pointing to an invalid file/folder but includes a valid .php file at the beginning of the url, you can do so by adding the following i.e. to a .htaccess-file:
<Files ~ "\.php$">
AcceptPathInfo Off
</Files>
I am creating a website with my own CMS. My problem is that I can access certain files via a URL in the browser.
I have tried to block it via .htaccess but when I do that, it also stops my functions from working, because they are blocked.
Does anyone know a solution for my problem?
Are your functions in a server side script or a client side script?
If they're server side, you can block HTTP access to the files by putting them in a directory that doesn't need to be accessed through HTTP and then putting a deny from all directive in that directory's htaccess file.
If they're client side, then you can't block access to them and still have the scripts work. The browser is executing the script, and it needs to access those files. You can do hacky things like refusing to serve the file unless a certain referrer URL is present, but I advise against doing that because it can cause problems with usability, caching, and search engines.
Add line at the end of .htaccess
Options All -Indexes
or Use
<FilesMatch "*\.(css|js|png)$">
Order Allow,Deny
Allow from all
</FilesMatch>
I'm working on a PHP project using Apache 2.2.22 and PHP 5.3.10 and I'm running into an issue where index and index.php are being treated as the same file.
I have an admin/index.php that redirects to admin/index to allow my mod_rewrite rules in .htaccess to take over and reroute the request into a custom framework. The problem is, when the browser goes to admin/index it goes into an infinite redirect loop because the request is being sent to admin/index.php which redirects to admin/index
I've tried removing the htaccess file to see if there was a problem with my mod_rewrite rules that was causing it and it didn't change anything. It just redirects to admin/index endlessly.
I've never heard of this behavior before, skimming over some Google results and skimming through the apache configuration files didn't show anything really obvious. Has anyone seen this before and know how to fix it?
EDIT:
Below is the code being used by the index.php to redirect to index.
<?php
header("Location: index");
die();
This may be due to MultiViews being enabled:
The effect of MultiViews is as follows: if the server receives a
request for /some/dir/foo, if /some/dir has MultiViews enabled, and
/some/dir/foo does not exist, then the server reads the directory
looking for files named foo.*, and effectively fakes up a type map
which names all those files, assigning them the same media types and
content-encodings it would have if the client had asked for one of
them by name. It then chooses the best match to the client's
requirements.
— https://httpd.apache.org/docs/2.2/content-negotiation.html#multiviews
Try adding Options -MultiViews to your .htaccess
Enable rewrite Logging inside Apache and raise the log level. That way apache will tell you exactly, step by step, what request is rewritten how, in which order and why.
I am having what I believe is a strange problem. I have several sites developed on the same hosting platform. All site seem to be fine except for one of them. The website is set up around 1 page (index.php) that retrieves the correct data to display from the database based on the path_info - this has worked for years - now on one site this has stopped working. By stopped working I mean it the page below now goes to a 404 error - I was under the impress that it should see the index.php as the script to use.
I believe this is an issue with htconfig or another file I don't have access to being misconfigured on the host's end. Perhaps someone can shed light on where I might direct them. My own htaccess file is completely empty:
wwww.testsite.com/index.php/page1
The above used to go to index.php and then using $_SERVER path_info retrieve page1 and get the contents associated with page1 from the database and display that on the page. Can someone confirm I am not going mad - that the above should go to index.php please? and perhaps too explain why the url is now seen as non-existent since it doesn't seem to be going to index.php but to page1. Thanks in advance for any advice.
Can someone confirm I am not going mad - that the above [wwww.testsite.com/index.php/page1] should go to index.php please?
Nope. That should look for a file called page1 in the directory index.php in the document root for www.testsite.com.
I think you used to have an .htaccess file that looked something like this:
RewriteEngine on
RewriteRule ^index.php(.*)$ index.php
Another possibility is that MultiViews were previously enabled and now not anymore. With MultiViews you also get the behavior you described. If it's allowed by the hoster, you can enable it by simply creating an .htaccess file containing:
Options MultiViews
If you put an .htaccess file with either one of abovementioned solutions in it in your document root, you can verify this.
In Apache, if you have AcceptPathInfo on anywhere relevant in the Apache config (including in .htaccess, if the server config allows it) and there's a file /index.php, then /index.php/stuff should indeed go to /index.php, and should set $_SERVER['PATH_INFO'] to "/stuff". The CGI script handler and mod_php* even do this by default, so it should just work unless it's explicitly turned off.
Either way, if it's currently off, you can turn it back on by adding AcceptPathInfo on to your .htaccess file, if AllowOverride FileInfo is set for the site.
I make no promises about other web servers, but PATH_INFO is part of the CGI spec, so i'd think most servers would have a similar setting.
Last night I made some admin changes to my webserver. I use php. The php processor failed after the update and if someone went to my homepage, the php page would simply download and show the proprietary code and password to anyone visiting. So I was wondering if there is a way to prevent any form of download for php files using .htaccess -- but still allow for normal viewing of the files.
A good pattern to follow during development is to use a minimal initialization file, which invokes the actual application which resides outside the webroot. That way only a minimal stub with no critical information is exposed in a case like this.
Simplified example:
/
/app
critical_code.php
/webroot
.htaccess <- rewrites all requests to index.php
index.php <- invokes ../app/critical_code.php (or other files as requested)
The trouble here is that either .htaccess is serving your files to the user or it's not. You can't tell it to deny access to the .php files, because then access will be denied during normal use, as well. There is no fallback behavior for the PHP processor simply not running correctly.
Maybe it's worth temporarily moving the web root to point to an "under maintenance" site when doing big things like that, to minimize risk as much as possible.
Assuming you're using Apache, your .htaccess file would look something like this.
<FilesMatch ".*\.php">
Order allow,deny
Deny from all
Satisfy All
</FilesMatch>
<IfModule php5_module>
<FilesMatch ".*\.php">
Allow from all
Satisfy All
</FilesMatch>
</IfModule>
The first rule denies access to all .php files. By default, the user will see a 403 (Forbidden) error.
If the PHP5 module successfully loads, the second rule will take affect, which grants access.