> MODX is very finicky about Manager passwords, but probably not
> database passwords. Just out of curiosity, see if you can create
> a new user from inside the Manager with the second password above.
> I suspect that you'll get an error message.
Suprisingly, no. The new user created without so much as a failed reload. The only error I got was for trying to get away with not specifying an e-mail address.
As for the $modx object and security in general, unfortunately - to my knowledge - you can't hide a variable based on security, and most importantly - even if you somehow did (e.g. by erasing the variable on error), it would be unavailable to the rest of the code. PHP doesn't support security-based scoping and variable visibility (AFAIK, no language does). As for not creating the user object in the first place, the error was a simple "failed to connect to the database @ 'IP' (using password: yes)". I made extra sure to specify the port each time, because the host uses a different SQL server port for obscurity reasons. On a side note, I don't see why anybody would bother to change the format from address:port to address;port=port in the Setup script, when the standard format (addr:port) is used in the XML.
Also, as far as populating the ->user property, during Setup I don't see how any security checks could fail - the security system is not in place yet, because there's nothing to secure. And as far as I've seen, the class loader doesn't do any security checks at all. All the loader does is organize and load the various chunks of code required for the thing to function properly - any failure of security at this stage would imply an error in the code, seeing as you can't verify security w/o all of the verification code in place...
And, regardless of how it actually works, not throwing a fatal error during SETUP (ie. installation, not use, of software) due to failed security checks would be bad design on multiple levels. Not only does it do nothing to further security (whose security, at this point?), it prevents the issue from being properly understood and debugged. The SETUP might as well finish with a "Success!" for all the good it would do.
For a short time, I thought that my problematic passwords cause a variable overflow somewhere in the code (which is hard to do with PHP, but possible), or - more likely - cause some of the parsed code to go out-of-scope with relation to the rest of the environ, but that doesn't seem to be the case. It merits digging around, though -- the moment you start preloading your code as strings and managing them as such, it's then up to you (the coder/designer) to prevent buffer overflows and memory overwrites, as it would otherwise fall to the executing parser thread. But from what I've seen, that's not exactly the case here. Like I said, it merits digging around.
