Skip to main content ↑ ↓
Topic: Folder structure (Read 8071 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Folder structure

I was wondering...
ElkArte moved some Subs-*.php files to a 'subs' folder, and subsequently defined SUBSDIR to point to these. Fine by me.

When it comes to your constant name choices (you may have seen I was wondering about this over at Wedge), was the choice made over a vote, or something? Or did something decide the names once and for all? I find 'BOARDURL' and other things to be okay since it's made from $boardurl, but 'SUBSDIR' screams 'I need an underscore!' to me...

Okay, now for the real question... Is the choice of introducing SUBSDIR a simple routine, i.e. "SMF did it this way, so we didn't really ask ourselves...", or is it there for a reason?
Why not use SOURCEDIR . '/subs/' instead? Because it's longer? Then why name all of its contents 'file.subs.php', rather than just 'file.php'? So that you can differentiate between file.php and subs/file.php if you're opening both file in a text editor that shows only the file name in the title bar?
Why do you always have an answer to all of my questions?
Has anyone seen my glasses?

Anyway.
I always assumed that $sourcedir and other folders were not accessed directly from $boarddir because of security concerns. Such as, "if you know where a file is positioned in the folder structure, then you can easily hack into it..."
Well, to me that's just crap. Have you ever, EVER heard from anyone who decided to move their Sources folder to somewhere else than the root? Ever heard from anyone who moved their theme folders outside of the root, or something?
Neither have I.

I think all of this is just there to make life harder for everyone, because somebody, at some point, decided that it would be 'cool' to be able to move your folders around. When it's obvious that this isn't going to work -- many SMF mods expect files to be here or there, and don't use the regular variables to get a proper path or a URL.

Code: [Select]
<?php
########## Directories/Files ##########
# Note: These directories do not have to be changed unless you move things.
/**
 * The absolute path to the forum's folder. (not just '.'!)
 * @var string
 */
$boarddir = dirname(__FILE__);

Well... That's the thing. These directories do NOT have to be changed, period.
Then $boarddir can ALWAYS be determine by dirname(__FILE__), no need to store it in a file. Only $boardurl should be stored, and only because multiple URLs can lead to the same physical file and you may want to be able to choose your defaut URL.

What do you reckon..? Is it just wishful thinking that all SMF forks could, overnight, decide to just drop the silly idea that security is dependent upon the admin moving their files around and updating their paths and making their own lives miserable?
I know I'm at least making my life easier by removing theme support in Wedge. It's only possible because I wrote the skin system alongside it and it works so well that I can have it support the entire templating system. And there are many things that I'm removing from themes right now, that strike me as being complete bollocks. Particularly the complexities of handling both default_theme_url and theme_url, when one could just allow themes to specify a 'replacement' URL for each of the specific icons/images they've replaced the original with... You know, things like that. Things that make sense. Things that make the codebase easier to handle for any skilled developer, not just any 'totally hardcore SMF developer'.

Re: Folder structure

Reply #1 –

Quote from: Nao – I was wondering...
ElkArte moved some Subs-*.php files to a 'subs' folder, and subsequently defined SUBSDIR to point to these. Fine by me.

When it comes to your constant name choices (you may have seen I was wondering about this over at Wedge), was the choice made over a vote, or something? Or did something decide the names once and for all? I find 'BOARDURL' and other things to be okay since it's made from $boardurl, but 'SUBSDIR' screams 'I need an underscore!' to me...

Okay, now for the real question... Is the choice of introducing SUBSDIR a simple routine, i.e. "SMF did it this way, so we didn't really ask ourselves...", or is it there for a reason?
Yep, I've seen you are thinking about constants too, but I've been a bit busy and I didn't read the entire topic.
Regarding the names here... well I don't remember exactly the details, but...
http://www.elkarte.net/index.php?topic=74.0
Should be the original discussion.
Then there are few others but I can only find this one:
http://www.elkarte.net/index.php?topic=469.0
probably some are lost in the IRC topic

mmm... I don't think I like underscores in constants...dunno though.

Quote from: Nao – Why not use SOURCEDIR . '/subs/' instead? Because it's longer? Then why name all of its contents 'file.subs.php', rather than just 'file.php'? So that you can differentiate between file.php and subs/file.php if you're opening both file in a text editor that shows only the file name in the title bar?
Yup, pretty much that. :P
It's a way to identify immediately even only by a single file name where you are, what you are doing.
A bit like the language files now (each language is in a different directory, but the names still contain the language).
The reason why not SOURCEDIR . '/subs/blabla.php' is

Quote from: Nao – Why do you always have an answer to all of my questions?
Do I?
That would be scary. :o

Quote from: Nao – Has anyone seen my glasses?
On your nose? :P

Quote from: Nao – Anyway.
I always assumed that $sourcedir and other folders were not accessed directly from $boarddir because of security concerns. Such as, "if you know where a file is positioned in the folder structure, then you can easily hack into it..."
Well, to me that's just crap. Have you ever, EVER heard from anyone who decided to move their Sources folder to somewhere else than the root? Ever heard from anyone who moved their theme folders outside of the root, or something?
Neither have I.
Just a couple:
sm.org
 mozillaitalia.org
The point is not exactly that you make the name of the directory "unguessable", more that you put it in a place that is not directly accessible from the web, here a couple of pages with the why is good practice:
http://answers.yahoo.com/question/index?qid=20070919195435AApBlWw
http://www.openweb-solutions.net/blog/php-file-structure/
Actually, the most important file that would be interesting to store somewhere else is Settings.php, but unfortunately it's one of the few that cannot be moved (and that's probably the reason why at sm.org the Settings.php just contains an include and not the real settings that are stored somewhere else).
That said, it would be a quite big problem if files were coded as "inline-script" (just code execution and calls to function and classes), with the organization of the codebase is less of a problem.
Of course 99% of the forum admins don't care about that (or don't have the means to accomplish such setup) and several other web-applications are not supporting such a "flexibility", so it's entirely up to the people developing the code decide what to do with paths.

Quote from: Nao – I think all of this is just there to make life harder for everyone, because somebody, at some point, decided that it would be 'cool' to be able to move your folders around. When it's obvious that this isn't going to work -- many SMF mods expect files to be here or there, and don't use the regular variables to get a proper path or a URL.
Well, I tend to avoid those mods (and any mod created by the same persons) because they demonstrate with their actions that are not able to read instructions, and if this is true, how could I expect them to be able to code?

Quote from: Nao – I know I'm at least making my life easier by removing theme support in Wedge. It's only possible because I wrote the skin system alongside it and it works so well that I can have it support the entire templating system. And there are many things that I'm removing from themes right now, that strike me as being complete bollocks. Particularly the complexities of handling both default_theme_url and theme_url, when one could just allow themes to specify a 'replacement' URL for each of the specific icons/images they've replaced the original with... You know, things like that. Things that make sense. Things that make the codebase easier to handle for any skilled developer, not just any 'totally hardcore SMF developer'.
Well, the theme is a bit of a different mess I think.
I tend to agree that all the themes should stay within the same directory (themes), no need to have themes all over the places.
Though in themes there are two things:
1) php files (including languages),
2) anything else.
php files are almost the same as any other file in sources.
all the other things (images, css, javascript) are a bit more tricky, because in theory it would be nice to be able to move them in other places just for the fun of being able to serve them from different domains for example. Of course, again, this is something that is of any relevance only to a handful of people, usually boards with a level of traffic so high that would benefit from such a setup.

OMG I wrote way too much!! xD
And I'm not even sure of half of what I wrote. :P
Bugs creator.
Features destroyer.
Template killer.

Re: Folder structure

Reply #2 –

Quote from: emanuele – Regarding the names here... well I don't remember exactly the details, but...
http://www.elkarte.net/index.php?topic=74.0
Should be the original discussion.
(It still disturbs me that Norv would be using several nicknames here for no reason...)
I'll look into these topics, thanks.

Quotemmm... I don't think I like underscores in constants...dunno though.
Matter of taste, I guess. I don't like unreadable variable names.
Heck, I'm even still considering updating all Wedge functions to use_underscores_everywhere, so that it's at least properly harmonized across all languages etc. But it's hard to do, e.g. I like function names like loadTemplate() more than load_template(), but I like view_query() better than ViewQuery(), for instance. All I want is harmonizing... :-/

QuoteIt's a way to identify immediately even only by a single file name where you are, what you are doing.
Honestly, I thought loadSource() was a SMF thing, but no, it was added in Wedge. That would explain why Wedge barely accesses $sourcedir, unlike Elk's many calls to SOURCEDIR and SUBSDIR.

Quote
Quote from: Nao – Has anyone seen my glasses?
On your nose? :P
Bugger, you got that one right, too!

QuoteJust a couple:
sm.org
 mozillaitalia.org
And did they actually experience one of the weird moments where their PHP is readable, à la Facebook back in 2008 or so..?

QuoteThe point is not exactly that you make the name of the directory "unguessable", more that you put it in a place that is not directly accessible from the web, here a couple of pages with the why is good practice:
Yeah, I'd already thought of that, but to me it comes down to the fact that most of the codebase will be public anyway, so there's no point in trying to read it. And, precisely, I was at a loss regarding Settings.php -- what good is it to enable admins to move their Sources folder around, or rename it, when you can't protect your very most important file?
I can only see something like, hmm... Well, indeed I guess Settings.php could hold 'only' an include() link to another file outside of the root. If the user can't access that one, then it's all good. But do you know of many people who'd have the technical skills required to do that kind of magic trick?
Honestly, even I don't really know much about this all.

Still, this tends to prove that changing URLs and paths for the various sub-folders is pointless.
I think I'll hide these folders from view, and automatically generate them from the board URL/path.
I also thought of going further into this, and caching PHP files, not just language files. (Wedge caches language files into shorter, faster files, which is cool, although you have to think of regenerating the PHP once files are updated.)

QuoteActually, the most important file that would be interesting to store somewhere else is Settings.php, but unfortunately it's one of the few that cannot be moved (and that's probably the reason why at sm.org the Settings.php just contains an include and not the real settings that are stored somewhere else).
This also means they can't update their admin panel settings 'like that', can they..? Anything with a target of 'file' in the admin will be glitchy, I guess.

QuoteWell, I tend to avoid those mods (and any mod created by the same persons) because they demonstrate with their actions that are not able to read instructions, and if this is true, how could I expect them to be able to code?
Aeva Media breaks a lot of SMF conventions in its code, it's just awful. Mainly due to the fact that Dragooon wrote the first version, and he had to be 'creative' because of technical limitations in SMF 1.x and the fact that he wanted the mod to work in both codebases. Perfectly valid point, and it does mean that he had to make it 'ugly' at points.

QuoteI tend to agree that all the themes should stay within the same directory (themes), no need to have themes all over the places.
Though in themes there are two things:
1) php files (including languages),
2) anything else.
php files are almost the same as any other file in sources.
You still need to take into consideration the fact that PHP files being 'readable' from a web browser is little more than an urban legend at this point. It has happened before, nobody saw it in action, and nobody knows if it'll happen again.

Quoteall the other things (images, css, javascript) are a bit more tricky, because in theory it would be nice to be able to move them in other places just for the fun of being able to serve them from different domains for example.
$my_page_buffer = str_replace('mysite/Themes/mytheme/images/', 'assets.mysite/', $my_page_buffer);
Just a matter of writing the UI for that, of course... (Or just letting skins play with this with a skin option.) (Option parsing in Wedge is easy as hell.)

QuoteOf course, again, this is something that is of any relevance only to a handful of people, usually boards with a level of traffic so high that would benefit from such a setup.
And these people I'm sure, would be willing to fork out money to help with development. But we're not seeing money are we? So why should we support things for me? :P

Re: Folder structure

Reply #3 –

Holy gently caress!
Pardon my French, but what if I simply used a random name for Settings.php..?
It could be generated from a md5 of the current path plus some stuff that is specific to the server, e.g. a series of settings that are findable via php but not if you can't run arbitrary code as a client on the server. What do you think..?
I just need to figure out what to use...

Re: Folder structure

Reply #4 –

Or, simpler, just use a completely random hash and get it from a glob('Settings*.php') call. This still makes it impossible for the client to find that file without having access to the file list (which is just a matter of ensuring htaccess is probably set up or the server sees index.php as the index manager, which is the case in 99.999% of all servers these days I think.)

What do you think..? A good idea for Elk too, no..?

Re: Folder structure

Reply #5 –

Note for future development: we'd have to make that quick reply thing expand a bit when quoting longish posts, barely 5 for messages long tens of lines is a pita to use.

Quote from: Nao –
Quote from: emanuele – Regarding the names here... well I don't remember exactly the details, but...
http://www.elkarte.net/index.php?topic=74.0
Should be the original discussion.
(It still disturbs me that Norv would be using several nicknames here for no reason...)
Well... That's (also) my fault. O:-)

Note for future development: we should add a way to refine search while looking at the results (i.e. action=search2).

Quote from: Nao –
Quotemmm... I don't think I like underscores in constants...dunno though.
Matter of taste, I guess. I don't like unreadable variable names.
Indeed.

Quote from: Nao – Heck, I'm even still considering updating all Wedge functions to use_underscores_everywhere, so that it's at least properly harmonized across all languages etc. But it's hard to do, e.g. I like function names like loadTemplate() more than load_template(), but I like view_query() better than ViewQuery(), for instance. All I want is harmonizing... :-/
Harmonization is a good thing.
I think we have kind of a double standard at the moment for functions and variables, maybe at some point...

Quote from: Nao –
QuoteIt's a way to identify immediately even only by a single file name where you are, what you are doing.
Honestly, I thought loadSource() was a SMF thing, but no, it was added in Wedge. That would explain why Wedge barely accesses $sourcedir, unlike Elk's many calls to SOURCEDIR and SUBSDIR.
I think we discussed about a loadSomething too, but Norv's opinion was that it would result in too many function calls or something like that... I think I'd still prefer it, but nothing too relevant to bother.
Though it would be handy in development to track down where and when files are included to consider changes of the code. But not very important either.

Quote from: Nao –
Quote
Quote from: Nao – Has anyone seen my glasses?
On your nose? :P
Bugger, you got that one right, too!
O_O
 emanuele is scared by himself

Quote from: Nao – Yeah, I'd already thought of that, but to me it comes down to the fact that most of the codebase will be public anyway, so there's no point in trying to read it.
I explained myself not very clearly: I think it is (mostly) a practice very useful in the past.
Let's assume you have a file like this:
Code: [Select]
<?php
if ($_POST['setting'])
    updateMySetting($_POST['setting']);
?>
<form>
change my setting <input type="text" value="<?php echo $mySetting; ?>"/>
</form>
Having this file in a web-accessible directory is a very big potential security risk: someone may access it directly and change the settings, so the file should stay in a protected, closed down in a non-web-accessible directory.
Yes, it's full of bad coding practices and completely alien to current coding standards, but it wasn't so unusual even only few years ago (I think the contact form I use on my site is coded like that because I wrote it years ago copying a tutorial found on the web somewhere and even older).
With such "coding style", have the files locked was a matter of life-or-dead.
When everything is organized like "our" (Elk, Wedge (I think), SMF) is organized, this is less or a concern, because the best you can get is a "you cannot access this file directly" (or "hacking attempt").

Quote from: Nao – I can only see something like, hmm... Well, indeed I guess Settings.php could hold 'only' an include() link to another file outside of the root. If the user can't access that one, then it's all good. But do you know of many people who'd have the technical skills required to do that kind of magic trick?
Unfortunately, I don't think "we" can do anything really worth about it.
Even scrambling the name, yes, it would be better than now for sure, though it would lead to some issues in case you end up with multiple versions of the file for any reason (transfer, bug, whatever)... :-\

ETA: and even having the real settings somewhere else, if the site allows to upload something or edit files from the admin panel, the forum is still vulnerable somehow: I'd just need to upload a script that requires the file including the settings and then echo'ed them.

Quote from: Nao –
QuoteActually, the most important file that would be interesting to store somewhere else is Settings.php, but unfortunately it's one of the few that cannot be moved (and that's probably the reason why at sm.org the Settings.php just contains an include and not the real settings that are stored somewhere else).
This also means they can't update their admin panel settings 'like that', can they..? Anything with a target of 'file' in the admin will be glitchy, I guess.
Yep.
Even though I always wondered about the fact that apparently patches were installed from the admin panel, that would mean files are writable (yeah, and of course at least directories are if the hacker successfully uploaded something somewhere last year), so security is not always a straightforward process.

Quote from: Nao –
QuoteWell, I tend to avoid those mods (and any mod created by the same persons) because they demonstrate with their actions that are not able to read instructions, and if this is true, how could I expect them to be able to code?
Aeva Media breaks a lot of SMF conventions in its code, it's just awful. Mainly due to the fact that Dragooon wrote the first version, and he had to be 'creative' because of technical limitations in SMF 1.x and the fact that he wanted the mod to work in both codebases. Perfectly valid point, and it does mean that he had to make it 'ugly' at points.
well, if have to do it for a reason, no problem because you know what you are doing, I was more thinking about several people that submit simple mods that just use $boarddir instead of $sourcedir to upload files from pacman for example.

Quote from: Nao – You still need to take into consideration the fact that PHP files being 'readable' from a web browser is little more than an urban legend at this point. It has happened before, nobody saw it in action, and nobody knows if it'll happen again.
See above. ;)

Quote from: Nao –
QuoteOf course, again, this is something that is of any relevance only to a handful of people, usually boards with a level of traffic so high that would benefit from such a setup.
And these people I'm sure, would be willing to fork out money to help with development. But we're not seeing money are we? So why should we support things for me? :P
lol
Bugs creator.
Features destroyer.
Template killer.

Re: Folder structure

Reply #6 –

Quote from: emanuele – Well... That's (also) my fault. O:-)
Hmm that doesn't explain the difference between Norv, TestMonkey and FeatureCat... (Or is there?)

QuoteI think we discussed about a loadSomething too, but Norv's opinion was that it would result in too many function calls or something like that... I think I'd still prefer it, but nothing too relevant to bother.
A function call has some overhead, but much less than a call to require_once, I'd say.
That's because PHP's handling of 'uniqueness' seems to be less efficient than simply keeping a static array of loaded files in a loadSource function.

Quote
 emanuele is scared by himself
I'm mostly scared by your constant use of the 'me' tag...  O:-)

QuoteUnfortunately, I don't think "we" can do anything really worth about it.
Even scrambling the name, yes, it would be better than now for sure, though it would lead to some issues in case you end up with multiple versions of the file for any reason (transfer, bug, whatever)... :-\
Not really, no..?
Some algorithm like this could work, I guess... In index.php, do this:
- glob(dirname(__FILE__) . '/Settings*')
- If you find a Settings.php file, check whether it's the only one.
     - If yes, then generate a random base 64 string, rename it to Settings-thatstringphp, rename Settings.php.bak (if found) to the same.
     - If not, then skip it, and add a security warning for admins in forum pages, asking to delete the file.
- If you find a Settings-randombase64string.php file, load it.
- If you find more files, possibly check their filemdate and load the most recent one, and show a security warning..?

That way, you can upload additional Settings files, and the script will still load the 'proper' one (i.e., the most recently updated/uploaded one.)

What do you think, guys..?
Sure, it's slower than just require_once(Settings.php), but it's certainly more secure at that point.

QuoteETA: and even having the real settings somewhere else, if the site allows to upload something or edit files from the admin panel, the forum is still vulnerable somehow: I'd just need to upload a script that requires the file including the settings and then echo'ed them.
AFAIK, SMF doesn't allow uploading executable code anywhere. Regarding admins, they can certainly do that, but... What's the point?
I have to admit though, I already discussed (over at Wedge) the possibility of preventing admin-but-not-main-admin users from accessing areas of Wedge that allow handling the filesystem. With this new information in hand, it would make even more sense, I think.