-
Notifications
You must be signed in to change notification settings - Fork 637
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) // NaNReproduction 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.parsebut 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