Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

S3 client authentication error #484

Closed
ppiotrow opened this issue Aug 10, 2015 · 19 comments

Comments

Projects
None yet
6 participants
@ppiotrow
Copy link

commented Aug 10, 2015

Hi, I get following exception while using aws-java-sdk-s3 in version 1.10.10 (had same issue on 1.9.37). The usecase works on my computer but throws exception on my development environment. Does it use something from OS configuration?

com.amazonaws.services.s3.model.AmazonS3Exception: AWS authentication requires a valid Date or x-amz-date header (Service: Amazon S3; Status Code: 403; Error Code: AccessDenied; Request ID: 41C359C079CBAFCF)
    at com.amazonaws.http.AmazonHttpClient.handleErrorResponse(AmazonHttpClient.java:1182) ~[aws-java-sdk-core-1.10.10.jar:na]
    at com.amazonaws.http.AmazonHttpClient.executeOneRequest(AmazonHttpClient.java:770) ~[aws-java-sdk-core-1.10.10.jar:na]
    at com.amazonaws.http.AmazonHttpClient.executeHelper(AmazonHttpClient.java:489) ~[aws-java-sdk-core-1.10.10.jar:na]
    at com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:310) ~[aws-java-sdk-core-1.10.10.jar:na]
    at com.amazonaws.services.s3.AmazonS3Client.invoke(AmazonS3Client.java:3608) ~[aws-java-sdk-s3-1.10.10.jar:na]
    at com.amazonaws.services.s3.AmazonS3Client.invoke(AmazonS3Client.java:3561) ~[aws-java-sdk-s3-1.10.10.jar:na]
    at com.amazonaws.services.s3.AmazonS3Client.listObjects(AmazonS3Client.java:647) ~[aws-java-sdk-s3-1.10.10.jar:na]
    at com.amazonaws.services.s3.AmazonS3Client.listObjects(AmazonS3Client.java:632) ~[aws-java-sdk-s3-1.10.10.jar:na]
@shorea

This comment has been minimized.

Copy link
Contributor

commented Aug 10, 2015

We add the date header when signing the request and just use System.currentTimeMillis corrected for any potential clock skew error between client and service. Could you try logging the values of System.currentTimeMillis() and SDKGlobalTime.getGlobalTimeOffset() to see if they are returning sensible values?

@rehevkor5

This comment has been minimized.

Copy link

commented Aug 10, 2015

I'm having this issue now as well.

@rehevkor5

This comment has been minimized.

Copy link

commented Aug 11, 2015

Here are a few examples of the times you asked for, logged just before calling a method on the S3 client library:

2015-08-11 00:14:07.731  INFO 1 --- [pool-4-thread-1] x.RedshiftEtl  : System.currentTimeMillis(): 1439252047731
2015-08-11 00:14:07.731  INFO 1 --- [pool-4-thread-1] x.RedshiftEtl  : SDKGlobalTime.getGlobalTimeOffset(): 0
2015-08-11 00:12:07.419  INFO 1 --- [pool-4-thread-1] x.RedshiftEtl  : System.currentTimeMillis(): 1439251927419
2015-08-11 00:12:07.425  INFO 1 --- [pool-4-thread-1] x.RedshiftEtl  : SDKGlobalTime.getGlobalTimeOffset(): 0
2015-08-11 00:13:37.346  INFO 1 --- [pool-4-thread-1] x.RedshiftEtl  : System.currentTimeMillis(): 1439252017346
2015-08-11 00:13:37.346  INFO 1 --- [pool-4-thread-1] x.RedshiftEtl  : SDKGlobalTime.getGlobalTimeOffset(): 0
@shorea

This comment has been minimized.

Copy link
Contributor

commented Aug 11, 2015

Thanks @rehevkor5, that all looks normal. Are you configuring the client or request object before making the call? If possible could you turn on wire logging and paste a sample request, please note wire logs may contain sensitive information depending on your application so take care and review and redact if needed.

http://docs.aws.amazon.com/AWSSdkDocsJava/latest/DeveloperGuide/java-dg-logging.html

@ppiotrow

This comment has been minimized.

Copy link
Author

commented Aug 11, 2015

This are values returned before exception.

System.currentTimeMillis(): 1439277525424
SDKGlobalTime.getGlobalTimeOffset(): 0

The code works on my machine, on remote machine which runs integration tests, but fails at development environment.

@ppiotrow

This comment has been minimized.

Copy link
Author

commented Aug 11, 2015

Ok, I think I have something. The failing machine runs the code on docker container using "java:8" base image. It is open JDK 8. I see that they made some update 4 days ago, which might be problem.
docker-library/openjdk@6f34072
I will try to downgrade to previous tag and let you know the result.

@ppiotrow

This comment has been minimized.

Copy link
Author

commented Aug 11, 2015

Changing openJDK docker base image from java:8 to java:8u45 fixed the issue. "java:8" currently points to openjdk-8u66-jdk so I guess there is some new bug/problem.

@ppiotrow

This comment has been minimized.

Copy link
Author

commented Aug 11, 2015

Here is the diff that helped me to figure out that I should use java:8u45
docker-library/docs@358b772#diff-db78c7f2f1969a2e1b5c9aa31e0fbc9aL7

@shorea

This comment has been minimized.

Copy link
Contributor

commented Aug 11, 2015

Ahhh my memory has failed me. This appears to be related to #444. Can you check what version of joda time is being resolved in your maven dependencies?

@ppiotrow

This comment has been minimized.

Copy link
Author

commented Aug 11, 2015

I'm using joda-time 2.7

@shorea

This comment has been minimized.

Copy link
Contributor

commented Aug 11, 2015

Upgrading to at least joda-time 2.8.1 should allow you to use Java 1.8u60 and higher. If another portion of your dependency graph is causing 2.7 to be pulled in declaring a direct dependency on 2.8.1 will take precedence.

@ppiotrow

This comment has been minimized.

Copy link
Author

commented Aug 12, 2015

It fixed issue. I recommend to write about it somewhere (FAQ, requirements) because I wasn't able to google it using exception message

@shorea

This comment has been minimized.

Copy link
Contributor

commented Aug 12, 2015

Will do @ppiotrow. Thanks for reporting this.

@gibbonsj

This comment has been minimized.

Copy link

commented Aug 17, 2015

Chiming in @shorea to let you know the joda-time work around did not work for me. I'm using OpenJDK8_u66, aws-java-sdk-s3 1.10.11, and joda-time 2.8.1 but I'm still receiving the same S3 authentication error that @ppiotrow reported.

@shorea

This comment has been minimized.

Copy link
Contributor

commented Aug 17, 2015

@gibbonsj are you sure 2.8.1 is the version being used at runtime? Can you try starting your application with the "-verbose:class" option to see where the joda time classes are being loaded from?

new DateTime().getClass().getProtectionDomain().getCodeSource() may also work if it's easier for you to just add a print statement in your application.

@gibbonsj

This comment has been minimized.

Copy link

commented Aug 17, 2015

@shorea, the work around is good. Long story short, the code was using an older joda-time from a TPS fat jar. Once the class path was fixed everything worked perfectly. Thank you again.

@shorea

This comment has been minimized.

Copy link
Contributor

commented Aug 17, 2015

Great to hear!

@urlgrey

This comment has been minimized.

Copy link

commented Sep 1, 2015

I was just bitten by this defect while building a Docker image that uses the maven:3-jdk-8 base image; the base image was updated to use Java 8u66 since the last time I committed.

I'm building a Dropwizard 0.8.1 app, and Dropwizard has a dependency on joda-time 2.7 which is vulnerable to this issue. I pinned joda-time to 2.8.1 in my Maven pom.xml, rebuilt the image, and all is well.

rich-nguyen added a commit to guardian/teamcity-s3-plugin that referenced this issue Sep 15, 2015

omarkj pushed a commit to omarkj/lein-maven-s3-wagon that referenced this issue Oct 14, 2015

Ómar Kjartan Yasin Ómar Kjartan Yasin
Use joda-time 2.8.1
This updates joda-time to version 2.8.1. This is due to a bug in older versions of
joda-time which cause it to [break when used with the AWS SDK](aws/aws-sdk-java#484).

faermanj added a commit to Craftware/Kornell that referenced this issue Oct 23, 2015

@marcos-zovico

This comment has been minimized.

Copy link

commented Nov 12, 2015

Update JodaTime version above 2.0 and serializer your atribute

// serializer Joda DateTime
public class JodaDateTimeSerializer extends JsonSerializer<DateTime> {

    private static DateTimeFormatter formatter = DateTimeFormat.forPattern("yyyy-MM-dd HH:mm:ss.SSSZ");

    @Override
    public void serialize(DateTime value, JsonGenerator gen, SerializerProvider arg2) throws IOException, JsonProcessingException {
        gen.writeString(formatter.print(value));
    }                       

]

// Deserializer Joda DateTime
import java.io.IOException;

import org.joda.time.DateTime;
import org.joda.time.format.DateTimeFormat;
import org.joda.time.format.DateTimeFormatter;

import com.fasterxml.jackson.core.JsonParser;
import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.DeserializationContext;
import com.fasterxml.jackson.databind.JsonDeserializer;

public class JodaDateTimeDeserializer extends JsonDeserializer<DateTime> {

    private static DateTimeFormatter formatter = DateTimeFormat.forPattern("yyyy-MM-dd HH:mm:ss.SSSZ");

    @Override
    public DateTime deserialize(JsonParser jsonParser, DeserializationContext context) throws IOException, JsonProcessingException {
        String date = jsonParser.getText();
        return formatter.parseDateTime(date);
    }
}


In your class

@JsonSerialize(using = JodaDateTimeSerializer.class)
@JsonDeserialize(using = JodaDateTimeDeserializer.class)
private DateTime created;

mdedetrich added a commit to mdedetrich/fm-sbt-s3-resolver that referenced this issue Nov 23, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.