ABE Anonymize action should accept optional arguments

[AlbertMTom]

Enhancement request ...

It would be useful if the Anonymize action were able to accept optional arguments in the same way that the INCLUSION method does. This would allow the user to specify for example that only cookies should be stripped from the request.

[AlbertMTom]

If I were to submit a patch to add this feature, and presuming it met your standards, would you accept it?

Based upon the specification (excerpt* below), the optional arguments would include such as the following (suggestions for alternative naming welcome):
HTTPAUTH
COOKIE
METHOD
DATA

A user could then, for example, specify the following rule:
Site *
Accept from SELF++
Anonymize(HTTPAUTH, COOKIE)

This would allow the user to implement some ABE-based CSRF protection without the problematic URL rewriting rules which cause numerous compatibility issues** without any user benefit in many use cases.

* Anonymize (synonyms are Anon and Logout) – strips Authorization and Cookie headers, turns methods different than GET, HEAD and OPTIONS into GET, remove upload data, then sends the modified request.
** Just one example of such a compatibility issue: ABE Anonymize action replacing "??" with "?" in URL

[barbaz]

It makes no sense to separate method & data - 1) sending empty POST data is useless and will break things, and 2) how can you send POST data in a GET request?
It would make more sense to just have 3 sub-categories: HTTPAUTH, COOKIE, and REQ

And, of course, just plain Anonymize would have to cover ALL of those for backwards compatibility.

[AlbertMTom]

It makes no sense to separate method & data - 1) sending empty POST data is useless and will break things, and 2) how can you send POST data in a GET request?
It would make more sense to just have 3 sub-categories: HTTPAUTH, COOKIE, and REQ

My best guess is that the URL rewriting I mentioned above (e.g. modifying/removing GET parameters) occurs under the category of "remove upload data" in the specification ("DATA" in my proposal). It clearly does not fall under any of the other 3 categories. It is reasonable to expect that a user might not wish for their GET request's URL to be rewritten (which causes compatibility issues, such as with CSS and JavaScript loaded from wp.com on many blogs, with Google Maps Street View, and with CSS loaded from fsdn.com) while still wishing for POSTs to be converted to GETs (to avoid requests which imply the possibility of permanent results).

Whether anyone could come up with a use case for converting the request type but leaving the data, I don't know, but giving the option wouldn't hurt.

Regarding your pointing out that the functionality could break things on a site ... that's true of Anonymize in general ... it's up to the user to determine how it will affect the sites they apply the action to, and whether they are willing to accept those effects.

Regarding your question about how POST data could be sent in a GET request ... by simply converting the name-value pairs to GET parameters. Or by assuming that a conversion from POST to GET necessarily results in removal of the POST data.

But a lot of this is beside the point, because I'm not currently proposing any changes at all in the functionality contained within the Anonymize action; I am merely proposing adding the ability to select which parts of the Anonymize action are applied to a request. Basically, I expect that this would entail updating the ABE interpreter so that it will recognize optional parameters for Anonymize (referencing how this is done for the INCLUSION method), and then wrapping conditional blocks around different sections of the Anonymize code which respect the optional parameters, where applicable.

And, of course, just plain Anonymize would have to cover ALL of those for backwards compatibility.

Agreed, and that is what I meant by optional, same as the INCLUSION method.

[barbaz]

Whether anyone could come up with a use case for converting the request type but leaving the data, I don't know, but giving the option wouldn't hurt.

The problem is that a website that's designed to take POST won't know what to do with GET data, and vice versa.

Or by assuming that a conversion from POST to GET necessarily results in removal of the POST data.

What I was trying to say is that I think that's the only viable option.

I'm not currently proposing any changes at all in the functionality contained within the Anonymize action; I am merely proposing adding the ability to select which parts of the Anonymize action are applied to a request.

I know (and +1 to your request)

[AlbertMTom]

Whether anyone could come up with a use case for converting the request type but leaving the data, I don't know, but giving the option wouldn't hurt.

The problem is that a website that's designed to take POST won't know what to do with GET data, and vice versa.

It is not strictly the case that converting POST data to GET data would result in loss of functionality on a site. For example, in PHP, code has access to the following variables:
$_GET
$_POST
$_REQUEST

The $_REQUEST variable can be (and quite often is) used instead of $_GET or $_POST (or even $_COOKIE) ... it's a way for the website developer to indicate that they don't care which method the data is transmitted through, that they just want to use it. This is useful, for example, when validating username and password. Instead of checking both $_POST['username'] and $_COOKIE['username'], the developer can simply check $_REQUEST['username'] to check the username regardless of whether the user is logging in or was already logged-in.

Or by assuming that a conversion from POST to GET necessarily results in removal of the POST data.

What I was trying to say is that I think that's the only viable option.

I don't see any reason to impose an arbitrary restriction which would disallow the above use case while offering no benefit to the user. But considering that I'm only proposing making changes to logic and not functionality within the Anonymize code, and presuming that the Anonymize code does not currently convert POST inputs to GET parameters before stripping them off, this isn't relevant to the current proposal. But even presuming that data would always be removed from POST requests, there would still need to be 4 optional arguments for Anonymize, including one for data which covers GET, presumably HEAD, and any of the other methods which support sending data such as via the query string (I'm not familiar enough with the other methods to know off the top of my head).

I'm not currently proposing any changes at all in the functionality contained within the Anonymize action; I am merely proposing adding the ability to select which parts of the Anonymize action are applied to a request.

I know (and +1 to your request)

Thanks!

[Thrawn]

It is technically quite possible to include a request body with a GET request, although it violates the HTTP specification.

The decision about accepting patches is all up to Giorgio, but if it's good code, I expect he'd be interested. I'm not sure what your proposed use case is, though? When/where do you need to anonymize some aspects of a request and not others?

[barbaz]

I think the main point is so that there is an option to Anonymize except for re-writing GET requests, so that some level of Anonymization can be applied to sites which break when GET request URLs are re-written.

It can also be useful to effectively disable sites from sending cookies to the server while not really Anonymizing the request, by only anonymizing cookies (this would be useful for some of the tests I do on my local server). Or to prevent POST requests while still allowing GET requests with cookies, to help prevent unintentionally submitting data to a site.

Anyway, there are plenty of use cases for this.

@AlbertMTom: Thanks for the tip about $_REQUEST, I did not know about it. I'll have to remember that.