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.
<?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'.
(It still disturbs me that Norv would be using several nicknames here for no reason...)
I'll look into these topics, thanks.
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... :-/
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.
Bugger, you got that one right, too!
And did they actually experience one of the weird moments where their PHP is readable, Ã la Facebook back in 2008 or so..?
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.)
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.
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.
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.
$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.)
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
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..?
Hmm that doesn't explain the difference between Norv, TestMonkey and FeatureCat... (Or is there?)
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.
I'm mostly scared by your constant use of the 'me' tag... O:-)
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.
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.