-
Notifications
You must be signed in to change notification settings - Fork 634
Closed
Labels
bugThis issue is a bug.This issue is a bug.p3This is a minor priority issueThis is a minor priority issuequeuedThis issues is on the AWS team's backlogThis issues is on the AWS team's backlog
Description
Describe the bug
When using miliseconds to define the expiry of a cloudfront signed url, i.e. specifying dateLessThan
, the cloudfront signer throws
Error: dateLessThan is invalid. Ensure the date string is compatible with the Date constructor.
Expected Behavior
Milliseconds should be accepted as they are accepted by the Date constructor
This works in SDK v2 and breaks when upgrading from SDK v2 to SDK v3
Current Behavior
The cloudfront signer throws the above mentioned error because it uses Date.parse
and not new Date()
However it is perfectly valid to call the Date constructor with a value in miliseconds
new Date(1000000000000) // Sun Sep 09 2001 03:46:40 GMT+0200
However Date.parse
does not support milliseconds
Date.parse(1000000000000) // NaN
Reproduction Steps
Call
import { getSignedUrl } from "@aws-sdk/cloudfront-signer";
// ...
getSignedUrl({
url,
privateKey: privateKeyContents,
keyPairId: accessKeyID,
dateLessThan: 10000000000,
});
Possible Solution
Either of this would suffice
- Change the error message to
Ensure the date string is compatible with Date.parse()
- note that this would be breaking from SDK v2 and needs to be added to Upgrading Guide - Handle milliseconds correctly (swap
Date.parse()
withnew Date()
? unsure if it breaks formats accepted byDate.parse
but then it would at least align with docs)
Additional Information/Context
No response
SDK version used
3.451.0
Environment details (OS name and version, etc.)
not applicable
Metadata
Metadata
Assignees
Labels
bugThis issue is a bug.This issue is a bug.p3This is a minor priority issueThis is a minor priority issuequeuedThis issues is on the AWS team's backlogThis issues is on the AWS team's backlog