Page 1 of 1

GET vs POST

Posted: Sat Mar 14, 2015 9:42 pm
by onli
I talked shortly with Mattsches about it in our meeting, but found now the corresponding code: We are doing strange things with GET and POST parameters. In fact, we are basically ignoring the difference in parts of the core. I propose to enable the distinction in out next major version

In serendipity_config,inc.php, there are these line:

Code: Select all

// We don't care who tells us what to do.
if (!isset($serendipity['GET']['action'])) {
    $serendipity['GET']['action'] = (isset($serendipity['POST']['action']) ? $serendipity['POST']['action'] : '');
}

if (!isset($serendipity['GET']['adminAction'])) {
    $serendipity['GET']['adminAction'] = (isset($serendipity['POST']['adminAction']) ? $serendipity['POST']['adminAction'] : '');
}
Also, we are actively using GET requests where we should use POST, for example when confirming the deletion of an image or for adding a comment-attribute to the spamblock-list. This is critical, because any browser with a prefetch-function could trigger actions by accident.

Re: GET vs POST

Posted: Sun Mar 15, 2015 11:47 am
by garvinhicking
Yes. Because we don't have $serendipity['REQUEST'] and making each plugin or core part check "if GET... OR POST..." would have disturbed readability.

The better term would be to use "REQUEST" of course, but that'd break BC with a lot of plugins. I don't think it really hurts for specific parameters like these.

Also, we are actively using GET requests where we should use POST, for example when confirming the deletion of an image or for adding a comment-attribute to the spamblock-list. This is critical, because any browser with a prefetch-function could trigger actions by accident.
I think this is mostly because using POST would require a <form>, and often such links are embedded within a <form> and couldn't use a "subform". But of course, whereever a GET request really changes something, we should find ways to perform that with a POST request only!