Fine Uploader getting "Policy expired" message sending to S3 for some

Question

I recently implemented Fine Uploader and it's been mostly successful. A few users are however are not able to upload. They are all using modern browsers (IE10, FF and Chrome). One let me remotely access their machine and I was able to try it on both Chrome and FF.

I got the same error on both:

[10:45:28.330] "[FineUploader 3.8.0] Received response status 403 with body: <?xml version="1.0" encoding="UTF-8"?>
<Error><Code>AccessDenied</Code><Message>Invalid according to Policy: Policy expired.</Message><RequestId>--removed--</RequestId><HostId>--removed--</HostId></Error>"

Is it something with the timezone settings on their computer where it's generating an invalid policy?

Straightout

Answer 1

The timezone settings will have no effect as times are UTC. However, if the time on the user's computer is not accurate (say, off by 5 or more minutes), then the policy will be expired, according to Amazon.

Fine Uploader sets an expiration date to 5 minutes (again, in UTC). The date used is generated in the browser, so your client machine's time will be used. If the client machine's clock is slow by 5 or more minutes, the policy will be seen as expired when Amazon handles it.

I'm fairly sure that the issue is due to a significant drift on your customer's machine clock. If you verify this, I suggest you instruct them to keep system clock synced with a time server.

Update: A new feature was added to Fine Uploader 5.5 that allows you to overcome extreme clock drift on user machines/browsers. See the clock drift section on the S3 feature page for more information.

Odd

Thanks. I've setup remote access to another customer with the issue for tomorrow and will confirm then. Do fast clocks matter or just slow? Is the 5 minute thing configurable anywhere? – Straightout

A fast clock will not result in any errors from Amazon in this particular case. Currently, the expiration date is not configurable. A clock that is 5 minutes or more off from the correct time is unusual and should really be addressed. I can see why you might want to simply increase the expiration date for compensate for clocks that are, say, 5-10 minutes off, but what about clocks that are 1 hour off, or 1 day off, etc? I suppose the date could be set to some date far off in the future, say, 30 years from now, but I felt 5 minutes was a reasonable and safe expiration date. – Odd

The person whose computer was having the issue bailed on me, so I couldn't confirm that the time was the issue. Any thought to making the expire time being set on the server as part of the signature request? This way you don't have to worry about the user having time issues. – Straightout

Actually, you can already do this, if you really want. Simply edit the policy document on your server when you receive the signature request, substitute the "expiration" property in the policy document with your own time server-side (+5 mins, for example). Then, base-64 encode & sign this modified policy doc). You can read more about the format of the policy doc that Fine Uploader creates client-side here: blog.fineuploader.com/#policy-format. – Odd

Thanks. I'll give it a try. I thought I would have to get the updated expiration back to the browser so it could be passed along to S3. – Straightout

The base 64 encoded policy is what is sent to s3, along with the signature and file, for the most part. Fine Uploader generates the policy as a convenience, but you can certainly change it server side and return the modified policy base 64 encoded and the signature. – Odd