Posted by Anonymous (not verified) on April 21, 2004 at 12:02am
22 followers
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | base system |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Issue Summary
There shouldn't be .inc files.
.inc.php is better since webservers won't allow users to view their content.
Just in case someone modifies one with confidential information.
Comments
#1
That's why we lock the directory in .htaccess. Any reason why this not sufficient?
#2
yes - that solution is specific to apache web server.
#3
.inc.php file "protection" is also server configurable.
If the web server adminstrator screws up his configuration, some files which should be hidden will not be.
If the web server administrator knows what they are doing, it doesn't matter what the files are called. They will be safe.
Defaulting towards Apache is not a bad idea. Apache runs more web servers than all the other programs combined, currently at about 67% of all servers.
#4
+1 for renaming all *.inc to *.inc.php. and all *.(module|theme) to *.(module|theme).php. beside being more secure and shrinking the .htaccess, this makes drupal more "standard" and "out-of-the-box" accessible for development (code editor file associations, debuggers, etc.) and other purposes. doxygen, for example, doesn't work with the current naming scheme out-of-the box but has to be patched to recognize *.(module|theme). quite hard under windows ...
#5
+1 to ax's suggestion
#6
It's a reasonable suggestion, but it would take major re-architecting, and need not affect users with proper server configurations, so I'm reclassifying this as a feature request for HEAD (making setup easier in hosted environments) rather than a bug report for 4.4.
#7
This is a very interesting idea, but I don't see this as a threat.
All of the main settings and usernames/passwords are stored in settings.php ... no way that is going to get through. Also, phpTemplate is the default now and those files end *.php as well. Only files that don't are modules and inc files but there is nothing sensitive in those pages.
Marking those closed as it really isn't needed anymore.
#8
Re-opening this. Having consistent naming of .php files would:
1. Make it easier to see what's php and what isn't when visually scanning a folder.
2. Save having to configure text editors to recognise those files as PHP
3. Help people on crappy hosting lock those files down a bit more.
Even if people think 3 is unreasonable, 1 and 2 are pretty good reasons IMO.
#9
Actually I think it easier to scan a directory when all the files don't end in .php, .module, .info, .theme, even .inc tell me a lot about the file with out looking at it.
#10
I am advocating this for quite some time now :) (I know I know moving stuff out of webroot is best, but many hosts won't allow for it).
#11
@nevets - we could append .php (I think that's catch's suggestion) - so, for example, node.module.php, node.pages.inc.php
#12
Decreases readability for me and there is an advantage to not using .php since by default those files are not executable by the PHP interpreter
#13
#14
subscribing. I'll patch this if it would be accepted. what are the issues with this breaking all the patches in the system though? is there a best time to do it?
#15
Major changes to do with moving files around are happening at the moment (eg #22336: Move all core Drupal files under a /core folder to improve usability and upgrades ) so maybe it makes sense to do this now-ish?
#16
The CMI initiative will see all settings migrated to an xml flat file storage system with an obfuscated namespace so some of the security implications of this are less important but i still see value in simplifying things like htaccess, general security and ide configuration, etc. If theres a little more support ill spend the time to try it out in the next couple days.
#17
So, reading through this issue, I understand what the problem is with having php files end in .module, .theme, etc., but the problem may not be as clear to other people.
Say I write a module that does something really cool that's key to my business...I dunno...maybe it makes all Microsoft products magically start working as intended or something.
Anyways, I hire some noob to put my site online for me. He uses lighty because it's faster and less bloated or something. Since core only has configuration files for Apache and IIS, the security precautions mentioned in #1 don't apply. So now, anybody on the internet could browse to http://myawesomesite.com/sites/all/modules/microsoft_magic/microsoft_mag... and see the code that powers my site.
This is bad.
So, I can see two possible fixes here:
#18
Since i wasnt particularly clear above , the other issues include the dx papercut level issues of configuring IDE's (im looking at you eclipse!) to parse .module/.install etc files as php so you get source formatting, error checking and code completion. And issues greping by file type:
grep -r --include=*.php "some_string" some_directory#19
+1 for this because of IDE configurations and because of "Stick .php on the end of any file that has PHP code in it (which makes sense in my mind)" from #17. Sometimes just making sense explains enough why this is the way to do a thing.
#20
Note that since we've now adopted PSR-0 for OO code in core (and modules once we figure out how to make that work), it mandates a ClassName.php format anyway for OO stuff.
#21
Initial moving for inc, module and theme extensions:
find . \( -name '*.inc' -o -name '*.module' -o -name '*.theme' \) | while read FILE; do git mv "$FILE" "$FILE.php"; done;I did not find any file with a theme extension on core, I guess this should be related with the age of the issue :-)
Other files/extensions on core with php but not a php extension on the filename:
I mainly used changes on #22336: Move all core Drupal files under a /core folder to improve usability and upgrades as reference for this, and then start to solve some of the problems so submitting a format-patch output to see what test bot says.
Far for being completed, but it's an start.
#22
The last submitted patch, add-php-extension-round-0.patch, failed testing.
#23
Expanding on my meaning in #20... Since this will de-facto happen anyway as we convert stuff over to PSR-0, should we bother doing it for /includes at all at this point? Seems like that would break more patches than it needs to right now.
I'm not against this change in the general sense; I'm just asking if we shouldn't wait until it's a smaller problem space anyway.