The best example of this is the oauth_callback. If you set a URI, JSON, or something else that is already encoded as a parameter to your oauth_callback, then you have trouble.
For example (extraneous parameters removed for clarity):
Then, in check_oauth_signature, the processing includes a call to normalize_parameters, which decodes, then re-encodes each parameter key and value. That ends up doing this:
After decode:
http://myapp.com/redirect.html?state={"client_id":"myClientID"} <--- This is the problem!
So, as you can see, the oauth_callback was stripped of a layer of URI encoding. This means the signatures will never match if you include anything that needs to be encoded in a callback parameter.
I'm willing to help fix this, but I'm unsure why it's being decoded and re-encoded in the first place. I'm sure it was for a good reason, so if a project maintainer can provide some insight, I'd be happy to help.
The best example of this is the oauth_callback. If you set a URI, JSON, or something else that is already encoded as a parameter to your oauth_callback, then you have trouble.
For example (extraneous parameters removed for clarity):
Sent from client:
In the plugin, $_GET decodes all parameters, so $_GET['oauth_callback'] gets you:
Then, in check_oauth_signature, the processing includes a call to normalize_parameters, which decodes, then re-encodes each parameter key and value. That ends up doing this:
After decode:
After re-encode:
So, as you can see, the oauth_callback was stripped of a layer of URI encoding. This means the signatures will never match if you include anything that needs to be encoded in a callback parameter.
I'm willing to help fix this, but I'm unsure why it's being decoded and re-encoded in the first place. I'm sure it was for a good reason, so if a project maintainer can provide some insight, I'd be happy to help.