Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
S3 client authentication error #484
Comments
|
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
commented
Aug 10, 2015
|
I'm having this issue now as well. |
rehevkor5
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:
|
|
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
commented
Aug 11, 2015
|
This are values returned before exception.
The code works on my machine, on remote machine which runs integration tests, but fails at development environment. |
ppiotrow
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. |
ppiotrow
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
commented
Aug 11, 2015
|
Here is the diff that helped me to figure out that I should use java:8u45 |
|
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
commented
Aug 11, 2015
|
I'm using joda-time 2.7 |
|
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
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 |
|
Will do @ppiotrow. Thanks for reporting this. |
This was referenced Aug 13, 2015
gibbonsj
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
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. |
|
Great to hear! |
shorea
closed this
Aug 17, 2015
urlgrey
commented
Sep 1, 2015
|
I was just bitten by this defect while building a Docker image that uses the 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. |
added a commit
to guardian/teamcity-s3-plugin
that referenced
this issue
Sep 15, 2015
rich-nguyen
referenced this issue
in guardian/teamcity-s3-plugin
Sep 16, 2015
Merged
Team city 9.1.1 #10
pushed a commit
to omarkj/lein-maven-s3-wagon
that referenced
this issue
Oct 14, 2015
omarkj
referenced this issue
in pjstadig/lein-maven-s3-wagon
Oct 14, 2015
Merged
Use joda-time 2.8.1 #6
added a commit
to Craftware/Kornell
that referenced
this issue
Oct 23, 2015
gitastrophe
referenced this issue
in perfectsense/dari
Oct 28, 2015
Merged
Updates joda-time:joda-time from version 2.0 to 2.8.1 and fixes DateUtilsTest#fromString_format_tz() to use “EDT” time zone for consistency with the test input. #128
marcos-zovico
commented
Nov 12, 2015
|
Update JodaTime version above 2.0 and serializer your atribute
|
ppiotrow commentedAug 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?