CSRF token in url-encoded body is url-decoded twice

[alxndrsn]

1. by body-parser, and
2. by authHandler

Introduced in 36b97ff

---

$ curl http://localhost:8383/v1/projects/1/forms/1/submissions.csv.zip -H 'Cookie: session=<valid-session-token>' -H 'x-forwarded-proto: https' -H 'content-type: application/x-www-form-urlencoded' --data '__csrf=%25ea'
{"message":"Internal Server Error"}

[matthew-white]

IIRC we have seen that CSRF tokens sometimes end up URL-encoded in the __csrf cookie (I think just $ and/or ! characters in the token). I think Enketo will then pass that encoded value back to Backend as-is without decoding it first. After Enketo encodes its request body, the encoded token will end up encoded a second time, requiring Backend to decode it twice. We considered changing how that works in Enketo (i.e., having Enketo decode the value of the __csrf cookie), but decided that it wasn't needed. Valid tokens don't contain %, which I think means they can be decoded any number of times without issue.

[alxndrsn]

they can be decoded any number of times without issue.

As you say, risk-free for valid tokens 🙂

Handling for invalid tokens added at #1265

[matthew-white]

I'm going to go ahead and close this issue now that #1265 is approved. Feel free to reopen if there's more to discuss!

[alxndrsn]

It looks like valid tokens do not need URL-decoding at all, so I'd say there's still an option to simplify the code by removing a round of decoding.