MODX Staff
Let me be more specific about what I might want to do. Say, in the default context, the System Setting: captcha_use_mathstring = false.
Any use of captcha.php as an image source would not use the mathstring because the veriword class checks it to decide.
Say I load a page that’s on the same server in the default context and use a plugin to set it to another context based on its document ID.
Snippets on that page would operate in the new context. Now a snippet on that page sets the System Setting captcha_use_mathstring to true and then uses captcha.php as an image source. The mathstring appears?
Now, the user transfers to another page, again on the same server in the default context, that doesn’t trigger the plugin and uses captcha.php as an image source. The mathstring doesn’t appear because we’re back in the default context?
It’s probably better to write my own captcha.php that responds the way I want it to (or rewrite the original so it takes an argument and uses the system setting as a default), but this example is helping me understand contexts.
I’m kind of lost on this one. I think the problem is configuration settings are not intended to be modified at runtime, ever, so changing a setting in a Snippet IMO, should not be allowed. Because they are stored in an array and you can doesn’t mean you should. In fact, in an upcoming change to further improve scalability of extremely busy, large sites, the configuration settings will be accessed via a function call, i.e. modX::config(), rather than via direct access to the modX::$config array. This will also close the gap on some seldom considered security issues, e.g. users won’t be able to write scripts to modify their config settings, which could be used maliciously.
MODX Staff
No, because that would only modify the setting for the duration of the current request. Once that request is done, the value of the system setting would be reloaded from the cache with the original value. To modify a system setting permanently, you would have to save changes to the table row and clear the cache.
For the sake of my understanding of contexts, though, would what I described in my last post actually work as I described it (assuming that $modx->config[’setting’] = $x works)?
Quote from: BobRay at Oct 12, 2008, 02:34 PMNo, because that would only modify the setting for the duration of the current request. Once that request is done, the value of the system setting would be reloaded from the cache with the original value. To modify a system setting permanently, you would have to save changes to the table row and clear the cache.
For the sake of my understanding of contexts, though, would what I described in my last post actually work as I described it (assuming that $modx->config[’setting’] = $x works)?
MODX Staff
That is a separate request, and, IMHO, one that should go through the MODx gateway rather than directly called via an external php file. Why can’t the captcha.php logic be encapsulated into a processor in the model, then called from the connectors context, or a front-end context, or from a controller in the mgr context for that matter?
Wouldn’t the use of captcha.php as an image source be included in the current request (or is that a new request).? I wanted a *temporary* change in the system setting to begin with.
Why can’t the captcha.php logic be encapsulated into a processor in the model, then called from the connectors context, or a front-end context, or from a controller in the mgr context for that matter?
But I’ve drifted from the topic; which is that configuration settings should always be considered read-only, unless you are changing them permanently in the scope of the system, a context, or a user. Changes to settings will potentially affect all users, since context and user settings can inherit values from the previous layer.
MODX Staff
I still do.
Quote from: OpenGeek at Oct 12, 2008, 04:29 PMIt certainly could, but I seem to recall that someone wanted it out of the core.
Why can’t the captcha.php logic be encapsulated into a processor in the model, then called from the connectors context, or a front-end context, or from a controller in the mgr context for that matter?
Just because it adds something to the model doesn’t mean it can’t be installed from a transport package.
Quote from: BobRay at Oct 12, 2008, 05:24 PMI still do.
Quote from: OpenGeek at Oct 12, 2008, 04:29 PMIt certainly could, but I seem to recall that someone wanted it out of the core.
Why can’t the captcha.php logic be encapsulated into a processor in the model, then called from the connectors context, or a front-end context, or from a controller in the mgr context for that matter?
MODX Staff
Just create context settings to override the system settings. Then each context will be able to determine which options are in effect for captcha_mathstring. That said, the login processor might process logins for any context itself (via the connector context), and this would be a different challenge, since captcha occurs before an authenticated user is logged into a specific context. I think you picked the toughest thing to implement first; let me get my head out of a couple of things this morning and I’ll spend some time looking over the captcha stuff again and make some recommendations.
At the least, I ought to re-do the captcha function so it’s easier to override the system setting for using the mathstring -- maybe with a $_POST variable (or setPlaceholder() ). Some users might want to use the mathstring in the Manager login but not elsewhere or vice versa.