Frequent 'Signature Mismatch' errors

Question

Hello,

This is a problem I have been seeing from the very beginning of interacting with Atmos (from v 0.5).

Frequently, we get a HTTP error "403 (Forbidden)" when we try to create/update an object; when we retry the same operation, changing nothing except recalculating the signature (since time of request has changed), we succeed. But a successful retry is not guaranteed; sometimes successive retries fail with the same 403 error; and we succeed on the 10th or 15th retry.

We never have to change the shared secret, the headers, time or the algorithm used: just retrying a number of times makes the request successful. This leaves the client application in a big dilemma on what to do.

My questions are:

Is this a known issue?
What is the cause of this problem?
How should a client app deal with this? We cannot keep retrying on a 403 without knowing if the "shared secret" provided by the user is wrong or if Atmos is responding incorrectly. Further, we don't know how many times to retry since the success of a retry is random.

This is a critical issue for us at this time as the reliability of the service we provide to the end-user is dependent on consistent behavior and accurate error reporting. Thank you for your help.

HTTP Error: 403

Atmos Error: 1032

Atmos Error String: There was a mismatch between the signature in the request and the signature as computed by the server.

Navneeth

Navneeth1 · Answer

Thanks, Leo. No, I haven't asked the customer service folks; I will. Navneeth

LeoLeung · Answer

Navneeth - have you tried asking Atmos customer service this question? We're still integrating our response across the developer community and CS, but this sounds like a bug. - Leo

JasonCwik · Answer

Hi Navneeth, Have you resolved your problem?  Are you using one of the wrappers?

Navneeth1 · Answer

Hello Jason, I've opened a case with the support folks and am following up with them. I am using my own implementation of REST (not using the provided wrappers). Navneeth

Sivan1 · Answer

Have you sorted out this problem?I am facing this issue while deleting an object from cloud and also when downloading the files.?any updates?

Navneeth1 · Answer

Hello Sivan,

One of the cases where this can happen is where the signature being calculated is indeed wrong. We found that in functions where we were decoding the token and calculating the HMAC, we were using "strcpy" at some point. However, the contents of the token (once base64 decoded) are not guaranteed to be like null-terminated strings (since they could contain the value 0); we were doing this and hence corrupting our signature. However, retrying a number of times made the request successful since at some point we got a signature without 0 in it and our function succeeded. We now do a byte-copy instead.

Hope this helps.

Navneeth

amarcionek · Answer

I too am trying to track down a signature mismatch error. Frankly, I haven't gotten it to work yet. We aren't using one of the bindings so we have to code to the REST API ourselves. Can anyone give me a clue why this would happen? Here is a sample header:

POST /rest/objects HTTP/1.1
Host: accesspoint.emccis.com
Accept: */*
content-type:application/octet-stream
date:Thu, 30 Jul 2009 20:52:50 GMT
x-emc-date:Thu, 30 Jul 2009 20:52:50 GMT
x-emc-groupacl:other=NONE
x-emc-listable-meta:part4/part7/part8=quick
x-emc-meta:part1=buy
x-emc-uid:c302076ecb114095b0e0426f979f72a1/SEVEN405E60F489EF240
x-emc-useracl:UID1=FULL_CONTROL,UID2=WRITE
x-emc-signature:mvs45xEIyiVhOH3XW7MiBjYyVD4=
Content-Length: 0

Hash string used is:

POST
application/octet-stream

Thu, 30 Jul 2009 20:52:50 GMT
/rest/objects
x-emc-date:Thu, 30 Jul 2009 20:52:50 GMT
x-emc-groupacl:other=NONE
x-emc-listable-meta:part4/part7/part8=quick
x-emc-meta:part1=buy
x-emc-uid:c302076ecb114095b0e0426f979f72a1/SEVEN405E60F489EF240
x-emc-useracl:UID1=FULL_CONTROL,UID2=WRITE

Returns a 403 HTTP response with a 1032 error.

I have run the identical headers through a modified version of the EsuRestApi (to extract the "sign" function) and the hash signature generated by the sign function matches my signature every single time.

aashishpatil · Answer

Hmm, I got this error too using the Java wrapper.

1032 There was a mismatch between the signature in the request and the signature computed by the server.

Got this after using the URL obtained by EsuApi.getShareableURL() method.

Thanks,

Aashish

rbala1 · Answer

Aashish, Does the signature mismatch only happen when you call that method?  Are you able to create/list/delete objects otherwise? Raj

amarcionek · Answer

Just to reply to myself from earlier, I found we had a trailing newline at the end of the hash string (just like the API document says NOT to do.)

Atmos

Frequent "Signature Mismatch" errors

Was this post helpful?