I made a transfer of a CMS from one server to another. On the new server an image was not found. I looked in the HTML code and saw
<img src="/images/john" alt="john" />
The picture had no extension like *.jpg. But why did it work on the old server? It is the same code, same database and same htaccess file. Even Internet Explorer can find the picture.
Is an Apache or PHP configuration responsible for that behavior? I only want to find out why.
Is it possible that MultiViews is enabled on the old server but not on the new one? MultiViews is an Apache feature that lets you query for files without including the extension (so images/john might return the file at images/john.jpg). It is intended (as far as I'm aware) to allow you to have multiple versions of the same page, with the ultimate version picked depending on the user's locale; a browser requesting index from Spain might get index.es.php while in Japan it might get index.jp.php. I've never used this feature myself, so I don't know if that's the correct usage to serve locale-dependent pages, but I do know that MultiViews has the side effect of serving index.php in response to index.
Note that MultiViews is controlled by the Options directive, and it is the only such option that is not included in All. So to get all options including MultiViews, you would need Options All MultiViews in your .htaccess file. This may or may not enable MultiViews depending on the Allow Override directive in Apache's configuration for your directory; if you're on shared hosting there's nothing you can do but complain (although they tend to allow all .htaccess overrides to avoid such complaints).
Related
I'm adding some database usage to a public facing site, and I wanted input on what the most secure way to store mysql connection information might be. I've come up with a few options:
First I could store the config in another directory, and just set the PHP include path to look for that dir.
Second, I know there are some files that apache won't serve to browsers, I could use one of these types of files.
Third, I could store encrypted files on the server, and decrypt them with PHP.
Any help would be much appreciated.
Storing the config outside of apache's document root is a must
You can configure apache to disallow any files with htaccess.
in the config folder add a .htaccess with the following
order allow,deny
deny from all
If you don't want to use .htaccess as #johua k, mentions, instead add
<Directory /home/www/public/config>
order allow,deny
deny from all
</Directory>
to your apache config.
This will deny any files in that folder from being served to anyone, which is fine since php doesn't care about htaccess you can just
include('config/db.php')
If you properly config your php scripts, they should never appear in plain text.
so a file like
define('mysql_password', 'pass')
would never display that text.
If you are worried about a shared hosting environment and another use having access to read this file then you should evaluate the security of the linux installation and the host. Other users should have any browsing access to your file. From the web files marked php should never return source.
You can explicitly tell apache not to serve the files ever, so they would only be include() or require() able.
I'm trying to use .htaccess files with PHP on OS X (Snow Leopard, 10.6.8), but when I go to localhost/ the browser just downloads whatever file it's lead to by the rewrite rules (rather than getting the output of the server-side execution of the PHP).
I've confirmed that PHP runs with Apache on other, simpler installations. For debugging I'm targetting check.php script so that should be good.
The web is full of guidance to hunt down and replace all AllowOverride None statements with AllowOverride All, but my apache configuration for this differs from the base OS X installation and doesn't include any of the various files with the AllowOverride None directives. I've set all of those touched by my configuration.
This same configuration runs the php scripts just fine when they're hit by the URL.
I've confirmed that mod_rewrite.so is available and loaded.
I'd appreciate help diagnosing / debugging this.
EDIT:
Also, when I hit the page from Firefox, I get a dialog saying "You have chosen to open [blank, for the index url] which is a: application/x-httpd-php5" and the choice to save or run. That x-httpd-php5 value is the string I use in the AddType directive in the .htaccess file.
Make sure Web Sharing is turned on in the preferences.
The problem is the following:
There is one server that I deploy to and for some reason the server does not respond to urls as usual. What I mean is when I have a file called somefile.php uploaded to mysite.com/ and I type in browser mysite.com/somefile the file somefile.php gets called instead of saying 404 not found. I think that this is weird and for some reason it prevents my .htaccess file to rewrite correctly, because the file somefile.php gets called and if there is information after mysite.com/somefile like mysite.com/somefile/someotherfile, someotherfile gets ignored and somefile.php gets displayed. I have all other .htaccess files deleted even in parent directories of the server and still the same result. I hope that you can hep me.
On localhost this problem is not observed. I get 404 not found as I should...
Sounds like you have MultiViews currently enabled. Try disabling them.
Multiviews
MultiViews is a per-directory option, meaning it can be set
with an Options directive within a , or
section in httpd.conf, or (if AllowOverride is properly set) in
.htaccess files. Note that Options All does not set MultiViews; you
have to ask for it by name.
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.
http://httpd.apache.org/docs/2.2/content-negotiation.html#multiviews
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.