1

I was testing a Python app using boto3 to access DynamoDB and I got the following error message from boto3.

{'error': 
    {'Message': u'Signature expired: 20160915T000000Z is now earlier than 20170828T180022Z (20170828T181522Z - 15 min.)', 
     'Code': u'InvalidSignatureException'}}

I noticed that it's because I'm using the python package 'freezegun.free_time' to freeze the time at 20160915, since the mock data used by the tests is static.

I did research the error a little bit and I found this answer post. Basically, it's saying that AWS makes signatures invalid after a short time after they are created. From my understanding, in my case, the signature is marked to be created at 20160915 because of the use of 'freeze_time', but AWS uses the current time (the time when the test runs). Therefore, AWS thinks that this signature has expired for almost a year and sends an error message back.

Is there any way to make AWS ignore that error? Or is it possible to use boto3 to manually modify the date and time the signature is created at?

Please let me know if I'm not explaining my questions clearly. Any ideas are appreciated.

Pinyi Wang
  • 823
  • 5
  • 14

3 Answers3

2

AWS API calls use a timestamp to prevent replay attacks. If you computer time/date is skewed too far from actual time, then the API calls will be denied.

Running requests from a computer with the date set to 2016 would certainly trigger this failure situation.

The checking is done on the host side, so there is nothing you can fix locally aside from using the real date (or somehow forcing Python into using a different date to the rest of your system).

John Rotenstein
  • 241,921
  • 22
  • 380
  • 470
  • Thanks for the information and advice :) I did find out a way to change to time back whenever I try to access dynamodb. – Pinyi Wang Aug 29 '17 at 20:35
  • I am experiencing this error within a moto.mock_ssm decorated unit test. I don't see why in such a case this checking should take place. Is this expected behavior even if the corresponding API is mocked? I'm using time_machine to make the unittest time invariant. – Hendrik Wiese Apr 27 '23 at 07:22
1

Just came across a similar issue with immobilus. My solution was to replace datetime from botocore.auth with a unmocked version, as suggested by Antonio.

The pytest example would look like this

import types
from immobilus import logic

@pytest.fixture(scope='session', autouse=True)
def _boto_real_time():
    from botocore import auth
    auth.datetime = get_original_datetime()

def get_original_datetime():
    original_datetime = types.ModuleType('datetime')
    original_datetime.mktime = logic.original_mktime
    original_datetime.date = logic.original_time
    original_datetime.gmtime = logic.original_gmtime
    original_datetime.localtime = logic.original_localtime
    original_datetime.strftime = logic.original_strftime
    original_datetime.date = logic.original_date
    original_datetime.datetime = logic.original_datetime
    return original_datetime
Roman Imankulov
  • 8,547
  • 1
  • 19
  • 14
  • For the record, switched from freezegun to immobilus because of the [performance issue](https://github.com/spulec/freezegun/issues/69) the freezegun had for longtime. – Roman Imankulov Aug 31 '18 at 14:15
0

Is there any way to make AWS ignore that error?

No

Or is it possible to use boto3 to manually modify the date and time the signature is created at?

You should patch any datetime / time call that is in the auth.py file of the botocore library (source: https://github.com/boto/botocore/blob/develop/botocore/auth.py).

Antonio
  • 1,565
  • 3
  • 20
  • 33
  • 1
    Thanks for the information and advice :) I did find out a way to change to time back whenever I try to access dynamodb. – Pinyi Wang Aug 29 '17 at 20:36