Disabling source code view in Apache

PHP code in non-standard file extensions

[craig1972]

In one of our domains, we have a non-standard file extension for our PHP programs. (Don't ask, it just is--corporate stuff.)

So in my httpd.conf I include the "AddType" directive to assign this extension to PHP, so they become PHP executables.

My problem is that when Apache is sometimes updated by the sysadmin, and the httpd.conf is freshly installed, this association breaks. So a user accessing these programs by the usual URLs directly in the browser can see the source code!

There are several ways to solve this, I think:

1. Make sure everytime apache is updated, the old httpd.conf is brought back instantly. (Question: is there a Linux way of maybe checking that Apache has been updated

2. CHMOD the files with this non-standard file extension so they're executable by Apache and therefore viewable to public (i.e., proper PHP code), but not "readable" as in source code. Is this possible?

3. Use some Apache directive maybe that allows files which are not executable to at least now show up as source code? (I think the "DefaultType text/plain" is the culprit here!)

Any thoughts?

[jdMorgan]

4.) The next time the problem arises, don't fix it... until it is agreed that using non-standard file extensions is the root cause, and that it costs time, money, and confidence in your corporation's ability to run a Web site... :)

Sorry, but anything else just impresses me as putting lipstick on a pig.

Jim

OK, OK, a far-distant second choice: Tell the sysadmin that if he ever updates Apache again and forgets to use the proper config file, he'll be looking for a new job. This should be an item on his checklist -- In bold red type. Have his manager sign off on this checklist as well.

[craig1972]

Thanks JD. My thoughts exactly!

But I have put an .htaccess file in the root folder of the domain too.

So even if httpd.conf configs are out of whack, shouldn't this line in the .htaccess file help? --

DefaultType application/x-httpd-php

It seems to be ignored though. The .htaccess seems to be doing nothing!

[jdMorgan]

Try AddType and/or AddHandler instead.

Understand that using "type" directives to invoke PHP execution is a kludge that they came up with in the very early days of PHP, and we're living with that legacy. The proper way to specify that a filetype should be parsed for executable scripts is using the "handler" directives.

Along with adding exceptions to password protection, this is one of those subjects that causes me to pull out my hair, just like almost everyone else... :)

Jim

[craig1972]

Problem with AddHandler and AddType is how to enable PHP on file that don't have any extension at all? So instead of "index.php" our great coders have "index", which they like to parse through PHP. If I understand AddHandler it *requires* a file extension, right?

[craig1972]

Actually I have an idea. We use "Easy Apache" to (re)build Apache. This overwrites the httpd.conf, but does allow for Include files. So I can move most of our customized directives into an external Include file.

But my question is this: several of our VirtualHost definitions are heavily customized. As the newly generated httpd.conf file already recreates default VirtualHost entries for all our domains, the external Include file will only repeat those VirtualHost definitions. This is not allowed, so Apache croaks.

Any workaround for this? Thanks!

[jdMorgan]

A thorough review of procedures and "what will really work for you" seems in order here... It sounds like your company is fighting its own tools and procedures, and the solution is not to make them even more complex, but to change them.

An easy and cheap method isn't easy or cheap if it requires several man-hours to 'recover' every time you use that method...

Take the boss to lunch... The big, big boss.

Jim

[g1smd]

*Files* should always have extensions. *URLs* don't have to have extensions.

Files are not URLs. The two things are 'associated' but are *not* the same thing.

Once you have that clear, the next steps should be fairly obvious.

[jdMorgan]

The problem is that the extensionless files are not under his control. He's dealing with "things the way they are" at his company.

There may be a technical solution to this problem, but I don't know what it might be: Someone, somewhere is either going to need to change the policy to follow technical standards or to enforce an official procedure for server upgrades that provides reasonable assurance that the proper server config file will be (re)installed.

Jim