Wrong base URI string is calculated when the provided URI contains url-encoded characters about oauth1-signer-java HOT 4 CLOSED

Getting URLencoding consistent between the URL, Authorization header and SBS is one of the reasons that these libraries were written in the first place. Differences with URLencoding are the biggest source of issues with getting OAuth1 signatures correct. The URLencoding behavior has been tweaked and tuned endlessly to get it into stable state across all libraries. Therefore, unless the gateway rejects requests containing these special characters in the current implementation, changing this behavior would be inadvisable.

from oauth1-signer-java.

Yes, unfortunately, these requests are being rejected from the gateway.

A failing example (rejected from the gateway):

client.setBasePath("https://api.com/api");
Api api = new Api(client); // client is using OkHttpOAuth1Interceptor to sign the requests
String pathParam = "foo@bar";
Response response = api.getResource(pathParam); // the generated getResource() method internally escape the path parameter to 'foo%40bar'

• The base URI string computed from the signer lib: /api/foo%2540bar

• The Signature Base String: ... foo%252540bar ...

The request made:

GET /api/foo%40bar HTTP/1.1
Host: api.com

Signature Base String (computed from the lib):
GET&https%3A%2F%2Fapi.com%2Fapi%2Ffoo%252540bar (omitted the not relevant part)
Acceptable signature base string (from the gateway): GET&https%3A%2F%2Fapi.com%2Fapi%2Ffoo%2540bar (omitted the not relevant part)

The current Java getBaseUriString implementation creates a new URI object with the provided schema, authority, and path. If the path contains characters previously encoded, they will be escaped in the new URI object created (the URI internally quote/escape the characters that are not permitted).

The GetBaseUriString behavior for some of the other libraries:

C#

Assert.AreEqual("http://example.com/r%20v/X", OAuth.GetBaseUriString("http://EXAMPLE.COM/r%20v/X?id=123")); // True

NodeJS

const baseUri = getBaseUriString("http://EXAMPLE.COM/r%20v/X?id=123");
assert.equal(baseUri, "http://example.com/r%20v/X"); // true

Java

uri = URI.create("http://EXAMPLE.COM/r%20v/X?id=123");
baseUri = OAuth.getBaseUriString(uri);
assertEquals("http://example.com/r%20v/X", baseUri); // false

The assertion below is true:

from oauth1-signer-java.

Keep in mind that the order in which the SBS and the HTTP request are generated could also influence this. For example, if you pass "raw" unencoded parameters into the OAuth signer library, it will encode them once. However if you construct some kind of a URL object using an arbitrary HTTP library, it might or might not URLencode parameters when you create that object. Passing it to the OAuth1 signer at this point will double encode it.

from oauth1-signer-java.

Thanks, @kkrauth.

Summing up what is happening with Java oauth1-signer lib ver. 1.3.0, the following request is getting rejected from the gateway:

GET /api/example/service/test%40api HTTP/1.1
Host: api.mastercard.com

• SBS:
  GET&https%3A%2F%2Fapi.mastercard.com%2Fapi%2Fexample%2Fservice%2Ftest%252540api

• OAuth signatures did not match. Acceptable signature base string:
  GET&https%3A%2F%2Fapi.mastercard.com%2Fapi%2Fexample%2Fservice%2Ftest%2540api ...

Note: the encoded symbol is in the path, not in the query string.

Below, what is currently happening in the signing process for paths with encoded symbols in it (eg. %40):

1. the path is first encoded in the URI() class: %40 is encoded to %2540
2. the path is encoded again in computing the signature base string: %2540 is encoded to %252540

• The encoded symbol in the HTTP request, remains: %40:

GET /api/example/service/test%40api HTTP/1.1

The same request, if signed with NodeJS lib, is accepted from the gateway as the SBS computed in that case will be: GET&https%3A%2F%2Fapi.mastercard.com%2Fapi%2Fexample%2Fservice%2Ftest%2540api

The proposed is to don't rely on the URI class for returning the base URI string as it internally quote the characters that are not permitted in the base uri, including path parameters already encoded and making it consistent with the NodeJS implementation.
The base URI is encoded (again) in the getSignatureBaseString()

The change will not affect the query strings encoding logic, as they are not considered in the getBaseUriString and processed separately.

from oauth1-signer-java.