Submit GET forms to the plugin adminstration

[cmb]

Hello Community,

I've just noticed that it seems to be impossible to submit GET <del>requests</del><ins>forms</ins> to the plugin administration without using XHR(2). The problem is that the PLUGIN_NAME parameter can't be set in the request URL (because it is overridden for GET requests), nor can't it be set via a named input element[2].

Please correct me if I'm wrong. Otherwise I suggest that we get rid of this severe flaw[1]. We have done so regarding the related flaw that the current page couldn't be requested via a GET request in XH 1.6 (however, that introduces a DC issue, as I've already noted in the respective thread). We should consider to allow for a similar solution (in this case the DC issue wouldn't be a problem, because bots won't have access to the administration anyway). I propose to abstract the details by introducing some API, however, the one I've suggested a while ago doesn't seem to be sufficient resp. convenient.

Any suggestions to improve the current situation are welcome!

[1] In some rare cases the distinction between a POST and a GET request might be blurred. However, most often it is clear which method is appropriate, and we shouldn't work against RFC 2616 (respectively its successors). Furthermore strictly requiring JavaScript for the adminstration isn't the best option, either, IMO.

[2] Well, there seems to be a workaround by checking for isset($_REQUEST[PLUGIN_NAME]) instead of $PLUGIN_NAME, but then we could get rid of the global $PLUGIN_NAME in the first place (would break a lot of plugins, though).

Christoph

[cmb]

On the roadmap:

rethink the general usage of $_REQUEST variables?

Actually, I'm not a fan of $_REQUEST, but I rather prefer to use $_GET, $_POST or $_COOKIE as appropriate. For one thing, $_REQUEST heavily depends on the configuration of PHP, i.e. variables_order (well, $_GET, $_POST and $_COOKIE also depends on this ini setting, but either they're available or not; the latter shouldn't be the case on any sanely configured general webserver). For another thing $_REQUEST blurs the distinction of GET vs. POST requests; for details see my suggestion for a stricter distinction between $_GET and $_POST. (We also have to keep an eye on PHP 7, where it has been discussed to change the behavior of $_GET and $_POST or maybe even rename them. It doesn't seem to happen, though.)

We may consider to temporily switch to $_REQUEST, but that would bring a potential backward-compatibility issue. As it is now, a plugin might use the its name as a GET or POST parameter name in the front-end to pass some value (should work fine as long as no cookie with this name is involved, if register_globals=On). Switching to isset($_REQUEST[...]) could cause unexpected behavior in this case.

Anyhow, I would prefer that the plugin administration (and even some special frontend functionality of a plugin) could be requested via the value and not the name of a GET/POST parameter. That would help to solve the $s issue, and might open further improvements with regard to skipping unnecessary work (it is not always necessary to read and parse content.htm, and not necessarily all plugins have to be loaded for every request).

[cmb]

I've just noticed that it seems to be impossible to submit GET <del>requests</del><ins>forms</ins> to the plugin administration without using XHR(2).

That depends on how the plugin detects that the plugin administration is requested. This is usually done by checking whether a global variable with the name of the plugin is set (to 'true'). For instance, if the plugin is named foo and one requests http://example.com/?foo, the global variable $foo is set to 'true' by the core. However, also $su === 'foo' in this case, so one can do:

Code: Select all

if (isset($foo) && $foo === 'true' || $su === 'foo') {
    // handle plugin administration
} 

This way GET forms are possible for the plugin administration without further workarounds.

That doesn't solve the other related issues mentioned above, but at least it's a viable workaround for now.

[cmb]

Well, the proper solution for now would be to redirect requests with `selected` in the query string, but no proper page URL, to the "canonical" URL. This would also solve the mentioned DC issue. I've added this redirect to Pfw_XH.