Access Control and File naming

[TerryE]

This is one simple improvement that we can definitely make (and I could easily give you the patch script for 3.1)

• Rule 1: PHP scripts will only be executed from the root dir (in the case of user scripts) and the ACP sub-directory in the case of ACP commands
• Rule 2: These directories should contain no php modules that are not intended to be executed as a script.
• Rule 3: Any directories that contain files that are only intended to be accessed programmatically and not by external URI should be prefixed with an "_" character

So config.php becomes _includes/config.php, download/file.php becomes download_file.php, cache becomes _cache, etc.

Why do this? Simply because the .htaccess rule (or the equivalent <DirectoryMatch regex> in the corresponding <VirtualHost> on large boards)

RewriteRule /(\.|_) - [forbidden]

is sufficient to enforce all such access control (and we can also lose the IN_PHP trick as well as current .htaccess files)

[DavidIQ]

Would need to make sure there is an equivalent for this in IIS as well. . (at least IIS7 anyways)

[TerryE]

It maps almost directly into the web.config XML file. (and also makes it easier here as well). However we don't talk about this at all in the user documentation. I've been drafting a set of kB articles on "How to set up your web services to get good phpBB performance" under my phpBB wiki user page: Work-in-progress_articles. I plan to complete the two Linux variants: (i)where the admin has root access to the Apache config(e.g. a VM or dedicated server) and (ii) where the admin doesn't (on a shared service). We could do with an experienced IIS based-admin writing a similar page for IIS. Once reviewed, these should be moved to the proper knowledge-base.

[Oleg]

I for one don't want to be typing those underscores all the time. php already has more than enough required punctuation.

Configuring htaccess is a one-time operation, and most users don't need to bother with that because shipped htaccess files work perfectly well. It does not make sense to make ongoing work more difficult to save a few lines in htaccess files.

Moving config to includes I can agree with but really the contents of that file should not be under web root at all, at which point it does not matter where it is.

[TerryE]

I for one don't want to be typing those underscores all the time.

Sorry but you've really lost me here.

It's the private directories within the phpBB file hierarchy that we would prefix with underscore. The entire code base has 316 includes and if we did this then this would be one bulk patch. We're already moving to an autoload strategy so the number of explicit includes will go down not up. The references to _cache, etc., are localised to a few occurences.. There are no material extra characters to type in the code to implement this.

It makes no difference in Explorer / Nautilus as a click is a click whether or not the directory has an underscore at the front. Or are you talking about at the command prompt because you don't want to type "cd _c*" instead of "cd c*" to navigate to the cache directory?

Re "the shipped .htaccess file work perfectly well", yes they do functionally, but if you rely on them then phpBB runs like a dog. Read the phpBB wiki page that I referenced, Configuring .htaccess for phpBB, if you want to understand why.

[naderman]

download/file.php becomes download_file.php

This is not possible. The only reason that file.php is in its own subdirectory is to protect from certain flash exploits in flash attachments (flash cross domain policies).

Generally the idea behind 3.x releases is to keep things as backward compatible as possible. By that I mean introducing new concepts only in new features or areas we want to refactor anyway. This works fine with autoloading since it's only used for code that is new or refactored for other reasons. Changes like modifying all directory names are something for 4.x not 3.x since this would break various assumptions people have been making in MODs and scripts.

[naderman]

and we can also lose the IN_PHP trick

This would assume that the .htaccess file (or provided alternatives for other webservers) always work. But there are other webservers where they don't work and there are apache servers which are configured to call these by a different name etc. So we cannot assume that the server has been configured to do this properly. We can try and educate our users as best as we can, but we cannot assume that they will actually set their server up the way we recommend.

[TerryE]

OK Nils, but could we at least move common.php and config.php into the includes directory? These shouldn't be accessed directly by MODs and scripts.

The underscore prefix is a nice convention, but not worth a lot of hassle. Note that as per Configuring .htaccess for phpBB, you can still do the protection with two rewrite rules (where nec. altering the install directory name):

RewriteRule phpbb3/(cache|files|includes|install-old|language|store)/ - [forbidden]
RewriteRule /(\.|_|config\.php$|common\.php$) - [forbidden]

[naderman]

OK Nils, but could we at least move common.php and config.php into the includes directory? These shouldn't be accessed directly by MODs and scripts.

Well from that perspective yes, but it also means that we break any external phpBB integrations that include common.php or config.php with the upgrade. I guess we could accept that, but again I'm not sure there benefit is worth it.

Note that as per Configuring .htaccess for phpBB, you can still do the protection with two rewrite rules (where nec. altering the install directory name):

RewriteRule phpbb3/(cache|files|includes|install-old|language|store)/ - [forbidden]
RewriteRule /(\.|_|config\.php$|common\.php$) - [forbidden]

Yup, that's certainly something we could put in the regular .htaccess.

[TerryE]

again I'm not sure there benefit is worth it

It's that entropy issue again. Having script files in a public directory which implements the phpBB requests apart -- from modules A and B which shouldn't be called. Yuck!

I take it by "external phpBB integrations" you are mainly talking about developer/admins that have extended the core product by adding their own pages. Anyone that does this should surely be daft to assume that they will automatically continue to work on phpBB upgrade; there will always be some regression tasks especially on a 3.0.x to 3.1 or to 3.2 upgrade. We're talking about a 2 line change or if they don't want to do that then adding a couple of symlinks.