From the OLP specs, X-Correlation-ID is returned to customer in response headers.
It is best if we make this value available to customers on the AccessTokenResponse object.
Suggested to follow a similar pattern to #63, but on the response side, to use a private transient String correlationId with setter/getter.

As a developer, I want to see the X-Correlation-ID logged when I configure my logging to include fine("messages").
Currently, the X-Correlation-ID header is not loggable with the response, unless I inject my own HTTP Provider.

Acceptance criteria:

The X-Correlation-ID is logged via something like

LOGGER.fine("X-Correlation-ID: {}", xCorrelationId);

Note that the headers are not currently exposed in the HttpResponse, so you'll need to add that as well.

Hi

I was using AAA SDK to get the access token but I still can't get it. I get a crash saying the following error

java.lang.NoSuchFieldError: No static field INSTANCE of type Lorg/apache/http/conn/ssl/AllowAllHostnameVerifier; in class Lorg/apache/http/conn/ssl/AllowAllHostnameVerifier; or its superclasses (declaration of 'org.apache.http.conn.ssl.AllowAllHostnameVerifier' appears in /system/framework/framework.jar!classes4.dex)

According to this Android has deprecated the Apache module since API level 22 so any workaround for this or anything

The tool used
Android Studio 4.1.1
Language Used Java

Hi,

I have observed a pattern regarding success or failure of the authorization request depending on whether the nonce was URL encoded while containing special characters. Removing the urlEncode() call seems to make all requests succeed.

Here are a couple examples to illustrate:

Successes

headerValue=OAuth oauth_consumer_key="***", oauth_signature_method="HMAC-SHA256", oauth_signature="wrlkVTMc%2F68A1asrCNlWNRPYzbpsQCrtrmrYYeBG7kk%3D", oauth_timestamp="1549652196", oauth_nonce="f1lpHr", oauth_version="1.0"

headerValue=OAuth oauth_consumer_key="***", oauth_signature_method="HMAC-SHA256", oauth_signature="Sl%2FECnifUqQQQJSkjrzhNxuZYfJGnepqXBAxxC4TwcI%3D", oauth_timestamp="1549652201", oauth_nonce="lrCx33", oauth_version="1.0"

headerValue=OAuth oauth_consumer_key="***", oauth_signature_method="HMAC-SHA256", oauth_signature="v%2Bz20gofBYj7UXXE1rAKjXLGZFkxsQWPiDwBCWCdkaI%3D", oauth_timestamp="1549653242", oauth_nonce="G8mmeS", oauth_version="1.0"

Failures

headerValue=OAuth oauth_consumer_key="***", oauth_signature_method="HMAC-SHA256", oauth_signature="4ia8%2Fsm1luNP2hXVxzl34%2BiGOkOQSkwmFC1GlQgW75w%3D", oauth_timestamp="1549653142", oauth_nonce="vH2Z%2FH", oauth_version="1.0"

headerValue=OAuth oauth_consumer_key="***", oauth_signature_method="HMAC-SHA256", oauth_signature="01j%2B85U77ehTBcDxd0OUTpfekIXjtfmzQX8YCvp12wU%3D", oauth_timestamp="1549653244", oauth_nonce="V%2FK6kl", oauth_version="1.0"

headerValue=OAuth oauth_consumer_key="***", oauth_signature_method="HMAC-SHA256", oauth_signature="UwULcKgLyzD0VpDZIChQE8R5kVycTNz0bWQI%2Fdn71iU%3D", oauth_timestamp="1549653304", oauth_nonce="A%2Bp5oH", oauth_version="1.0"

I haven't investigated too deep into the issue but removing the urlEncode(nonce) and only appending nonce as-is seems to lead a 100% success rate, even with oauth_nonce="7g+/D1" or oauth_nonce="Zs/a9h".

Please feel free to check the hypothesis a bit further.

Thanks,

Boris

Currently, the Client.Builder() class allows you to construct an instance without specifying, for example, a Serializer. The result is you get what appears to be a valid Client, but later when you send requests, they fail at the serialization step with a NullPointerException.

A Client instance that can be constructed, but cannot be used, is rather of pointless.

The solution should either

1. Have the Client.Builder use reasonable defaults, such as apache HttpProvider, NoAuthorizer, and JacksonSerializer, when no override was specified.
2. Have the Client.Builder.build() method validate not null with assertions that fail-fast and a clear null indicator.

I guess there were also releases v0.4.13 and v0.4.14, but I don't see them being tagged at https://github.com/heremaps/here-aaa-java-sdk/tags. Please add those tags.

Hi team,

I'm trying to use this library in an Android project with minSdkVersion 24. Here is a quick recap of the problems I face:

First, in order to avoid build issues with Apache httpcomponents, I had to exclude things as follow:
implementation('com.here.account:here-oauth-client:0.4.16') {
exclude group: 'org.apache.httpcomponents', module: 'httpclient'
}
And then I ended up using the pure JavaHttpProvider. I naively ran some unit tests and the authentication went through.
Then, I ran an instrumentation test and hit the wall mentioned above. Indeed, the library uses java.util.Base64 while Android only provides android.util.Base64, leading to the runtime issue: java.lang.NoClassDefFoundError: Failed resolution of: Ljava/util/Base64. I have found it in OAuth1Signer and SignatureCalculator.

My current workaround to get going is to copy those classes and make the small one-line changes to have them work with Android. I now use the Apache Base64 implementation in module 'commons-codec:commons-codec:1.10'.

I now have class AndroidOAuth1Signer.java:

import org.apache.commons.codec.binary.Base64;
.
.
String nonce = new String(Base64.encodeBase64(bytes)).substring(0, NONCE_LENGTH);

And class AndroidSignatureCalculator.java:

import org.apache.commons.codec.binary.Base64;
.
.
byte[] keyBytes = Base64.decodeBase64(key);
.
.
return new String(Base64.encodeBase64(signedBytes));
.
.
Plus a few more replacements

So I'm using those two classes above via third class ClientAuthorizationRequestProviderFromAndroidProperties.java:

package com.here.account.android;

import com.here.account.auth.OAuth1ClientCredentialsProvider;
import com.here.account.auth.provider.FromProperties;
import com.here.account.http.HttpProvider;
import com.here.account.util.SettableSystemClock;

import java.util.Properties;

/**
 * ClientAuthorizationRequestProviderFromAndroidProperties is the class allowing HERE AAA from given
 * properties.
 *
 * It does override getClientAuthorizer() in order to use classes
 * like AndroidOAuth1Signer and AndroidSignatureCalculator specifically modified for Android usage.
 *
 * @author guenebau
 * @since 1.0.0
 */
public class ClientAuthorizationRequestProviderFromAndroidProperties extends FromProperties {
    /**
     * The OAuth 1 signer created from properties.
     */
    private final AndroidOAuth1Signer mOAuth1Signer;

    /**
     * Class constructor.
     *
     * @param properties the properties containing credentials related values.
     */
    public ClientAuthorizationRequestProviderFromAndroidProperties(Properties properties) {
        super(new SettableSystemClock(), properties);
        mOAuth1Signer = new AndroidOAuth1Signer(
                getClock(),
                properties.getProperty(OAuth1ClientCredentialsProvider.FromProperties.ACCESS_KEY_ID_PROPERTY),
                properties.getProperty(OAuth1ClientCredentialsProvider.FromProperties.ACCESS_KEY_SECRET_PROPERTY));
    }

    /**
     * {@inheritDoc}
     */
    @Override
    public HttpProvider.HttpRequestAuthorizer getClientAuthorizer() {
        return mOAuth1Signer;
    }
}

It does work well and I can get authorization from HERE Account.

So please let me know if there is any Android friendly direction you would like to explore.

Thanks,

Boris

Add a configurable RetryPolicy to the HereAccessTokenProvider, that by default retries socket and 5xx errors up to 2x with backoff.

This would allow, particularly when using HereAccessTokenProvider.Builder.setAlwaysRequestNewToken(true), some additional client-side resilience to network hiccups or expected low-probability failures server-side.

The DefaultRetryPolicy can then be chosen from java.util.Random using exponential random backoff starting with [0,200] ms, with up to 3 max attempts. Or, other suitable alternative.

currently, if you create a FileAccessTokenResponse for an access_token response that is valid for an hour, and read from that file using HereAccessTokenProvider over time, the getStartTimeMilliseconds() does not increase, and the getExpiresIn() does not decrease with each new instance.

The behavior of FileAccessTokenResponse must be as follows. From the time the file is read, getExpiresIn() should represent how much time is left on the access_token.

The fix must have for 2 instances of the FileAccessTokenResponse constructed from the same file contents, but N seconds apart, a getStartTimeMilliseconds() that is ~N*1000 larger in the second one and a getExpiresIn() that is ~N smaller in the second one.

The OAuth1 signature is not calculated correctly if query parameters are included in the request URL.
For example for request like GET http://example.com/some/path?key1=value1 the key1=value should be included in the OAuth1 sorted signature base string. Now those are just included as part of the URL and thus the OAuth1 signature is wrongly calculated.

Apparently the OAuth1Signer class does not extract query parameters from URL and use those to calculate the OAuth1 signature as specified in the RFC-5849. The SignatureCalculator calculateSignature method has support for the query parameters, but those are currently passed as null in the OAuth1Signer class.

Also some characters like '*' and '~' are not correctly encoded when adding those to the signature base string.

The README.md is always one version ahead of the actual published version of the here-aaa-java-sdk.
The readme states to use:
<dependency> <groupId>com.here.account</groupId> <artifactId>here-oauth-client</artifactId> <version>0.4.23</version> </dependency>

But so far only version 0.4.22 is published.

Previous test cases didn't use characters in the alphabet that gets escaped via the method of https://tools.ietf.org/html/rfc5849#section-3.5.1 :

1. Parameter names and values are encoded per Parameter Encoding
   (Section 3.6).

We followed this directive for the oauth_signature, but not for the oauth_consumer_key value.

When we add your library from Maven (0.4.23) to our SDK it pulls in both Apache httpclient and httpcore.
This results in a duplicate META-INF/DEPENDENCIES resource:

Caused by: com.android.builder.merge.DuplicateRelativeFileException: 2 files found with path 'META-INF/DEPENDENCIES' from inputs:

• /Users/m/.gradle/caches/transforms-3/4edeb743f367f53d909b8c6e94203f1b/transformed/jetified-httpclient-4.5.2.jar
• /Users/m/.gradle/caches/transforms-3/562b29ddf764906d0d191a0ba1b0c987/transformed/jetified-httpcore-4.4.4.jar
  Adding a packagingOptions block may help, please refer to
  https://google.github.io/android-gradle-dsl/current/com.android.build.gradle.internal.dsl.PackagingOptions.html

+--- com.here.account:here-oauth-client:0.4.23|
+--- org.ini4j:ini4j:0.5.1|
+--- com.fasterxml.jackson.core:jackson-databind:2.10.0.pr1 -> 2.13.0 (*)|
--- org.apache.httpcomponents:httpclient:4.5.2|
+--- org.apache.httpcomponents:httpcore:4.4.4|
+--- commons-logging:commons-logging:1.2|
--- commons-codec:commons-codec:1.9

Which requires any app using our SDK to now have to add a packagingOptions to exclude it:
packagingOptions {
resources.excludes += "META-INF/DEPENDENCIES"
}

We think you should be excluding this duplicate resource as a packagingOptions section in your library build step.