Open vinu-ablabs opened 3 weeks ago
hello @vinu-ablabs . Sorry for any inconvenience with the library. Is it possible for you to upgrade to v6, and test this behavior ? You can decrease the expiration time of your access token to 5 minutes for faster testing.
The issue is not with cognito access token. Upgrading would need us to migrate some of the code. This was a production. What is expiring is the session token from sts
Thanks and Regards,
Vineeth Vijayan +91 9902921500 Head of Engineering
On Wed, 8 May 2024 at 21:58, israx @.***> wrote:
hello @vinu-ablabs https://github.com/vinu-ablabs . Sorry for any inconvenience with the library. Is it possible for you to upgrade to v6, and test this behavior ? You can decrease the expiration time of your access token to 5 minutes for faster testing.
— Reply to this email directly, view it on GitHub https://github.com/aws-amplify/amplify-js/issues/13347#issuecomment-2100956835, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2DSXOCF45CLD3A4QDVWS6TZBJHBFAVCNFSM6AAAAABHMKTABCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBQHE2TMOBTGU . You are receiving this because you were mentioned.Message ID: @.***>
Thank you for the context. I'll bring this to the team, try to reproduce it and be back with next steps. Thanks for the patience!
Related to #13307
hello @vinu-ablabs . Are you seeing this error after authenticating via a social provider, username and password, guess access or all of them ?
hey @vinu-ablabs . Is this issue also happening for both light and heavy size files ?
@israx Yes. Even any API calls going through Amplify prior to the upload calls do not revive the session
hello @vinu-ablabs . Are you seeing this error after authenticating via a social provider, username and password, guess access or all of them ?
@israx Yes it happens to login via email/password. I believe it could happen to all of them
Hello @vinu-ablabs . I'm unable to reliable reproduce this issue. I see the library is able to refresh tokens and credentials on the following scenarios:
Storage.put
In both cases the library is constantly refreshing AWS credentials and authentication tokens.
Can you upgrade to the latest version of Amplify v5 (5.3.18)
and check if the issue still persist ?
HI @israx Tried with 5.3.18 but still no luck
Getting the below error still
Request URL: https://xxxx-qa.s3.us-east-1.amazonaws.com/public/vendor/a00aa016-2636-4737-b2a4-xxxx/bid-attachments/19fff378-1f09-4674-a0fc-xxxx/version0/d211fbe1-772b-4a42-8a3b-xxxx.png Request Method: PUT Status Code: 400 Bad Request Remote Address: 52.216.50.106:443 Referrer Policy: strict-origin-when-cross-origin
PUT /public/vendor/xxxxx-2636-4737-b2a4-xxxx/bid-attachments/19fff378-1f09-4674-a0fc-xxxx/version0/d211fbe1-772b-4a42-8a3b-xxxxx.png HTTP/1.1 Accept: / Accept-Encoding: gzip, deflate, br, zstd Accept-Language: en-GB,en-US;q=0.9,en;q=0.8 Connection: keep-alive Content-Length: 965205 Host: arkstoragedev132731-qa.s3.us-east-1.amazonaws.com Origin: http://localhost:3000 Referer: http://localhost:3000/ Sec-Fetch-Dest: empty Sec-Fetch-Mode: cors Sec-Fetch-Site: cross-site User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 authorization: AWS4-HMAC-SHA256 Credential=ASIA2RSZYKMI6PAZUAMT/20240514/us-east-1/s3/aws4_request, SignedHeaders=content-type;host;x-amz-content-sha256;x-amz-date;x-amz-security-token;x-amz-user-agent, Signature=7ae8133104becf95eb63eb0f1261fbe2e6f3974ddc46df87ae2b38c362babd34 content-type: image/png sec-ch-ua: "Chromium";v="124", "Google Chrome";v="124", "Not-A.Brand";v="99" sec-ch-ua-mobile: ?0 sec-ch-ua-platform: "Windows" x-amz-content-sha256: UNSIGNED-PAYLOAD x-amz-date: 20240514T040227Z x-amz-security-token: IQoJb3JpZ2luX2VjEA8aCXVzLWVhc3QtMSJIMEYCIQDE6e5XBARuPy9JuSWxP6pJi/Ye7kgJgyhA52rTpNCC6gIhAPSI+HnjbS5WYtzNV634NPL+09gfuYN1TrFGdZRIpOcpKsQECHgQARoMNzI0OTYzOTcxODU3IgwwrJ37r7QpZsXsh6IqoQQ0Y8fWA+joA4dOL+dVHgSllowObt6qIryNMRD76qdeqrHeaAm7tw/E0c5OTTPuWaIu7u6mLwpHaCN77KK0Wra2SBmircrGA8p0GWtX2kB6IIlqoB9qpVgu6td6fjvcOwDYEZ7RV3YvYz/22O5CNWvPuhk4qkLQzMVII0eALkN2jJacSkT8nlJnSirkzxYsZiZM9VOM7CvLO48bC9zMGgbNAq2JG9yb6kH1FqrCUxfOnTda4YHvJgTbTOJrbDLTG62Hd5eNZ4TkSryKmlr85jJCTgg3Sm8gSuntqKs9jjw1v5AYJKwjeldzoJoSF8bM3V8rGnF7d/hAkQX/9Ik5yJijOv5EsCacPGcI08utpA7ZbuxcZET/sl/04XAEXqGJezxF0s+4J5SZ0a0XXCy701+pZVFgjk/nxL3JKAZ2SyerPVBXzXON6Scm2ROxyASotWtXH3Z/4VD//NoNrz9Q25OgTh+cme+ebE7gOKX+agKojceLVIH8AqKvHTY4MmHLxzqpKOzPFfiSeq5SxqDvGC7X8p7Uyy1CiIDi5QGePjHTzm8aUV4BPBS5lmWFRIgxv/kWwbpBaf9ot8HdaaHuie1YHEn36E9n4qatadDpEZy0cVecozCcGQyPDvbF3r07gYtAS22AGyimL+kqzcXuI4d+jzkty/dFyuXTNofT7iHNn9OYdDZGb+nYxVtWkgXl4Xo3cVXuk8RHMbJvHpC81MAbbzCqzYiyBjqEAkD2Hr2JleOlrkp0+3yts3c9uTcjiLy0E99BlfOqB5OEB4guuP2EuO2AwUFIx6ryTww37nKIZXwYUjfD74K4KhSzRyQf06t3ccy4TsQYpR9ofCrDMt86LTDKXlNIaak4vQPrLFmM50v514U5lVzzohUKchDv82jMJNk6luv3j1/HiJ8cMezjjbVNknSfoE4KVmiUZkjq3WqVfOeWu2v2/Mg8i7/wf8Q2kqjU4VDL8ZD5/cAxJJ7H0GagRshz2wY8nV39YJ00kCJY7pR6ie7h2ioADFrl1nrl3l2D6BpMFuoO9EzMAxweRqmdQ9w4sEor91dG+Oo8MGi8fV4S05dPftZglv0L x-amz-user-agent: aws-amplify/5.3.18 storage/1 framework/1
HTTP/1.1 400 Bad Request Access-Control-Allow-Origin: Access-Control-Max-Age: 3000 Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method x-amz-request-id: 2WNZP2QWZTBJK8SD x-amz-id-2: C4DDPVSLx3Trgmb0kEkJg41N6O+NnKfwXlWFAkjCiksNg8tOhjskAB3POzziRpXFH3ibxPEzOeA= Content-Type: application/xml Transfer-Encoding: chunked Date: Tue, 14 May 2024 04:02:35 GMT Server: AmazonS3 Connection: close access-control-allow-headers: access-control-expose-headers: access-control-allow-credentials: true access-control-allow-methods:
@israx another issue was looped in on my issue. You think its relavant?
That issue is related to creds being expired while uploading a heavy file, and we currently have a PR to address it. We highly recommend to upgrade to v6 as we are constantly bringing updates.
@israx I have a feeling that the same thing is happening here as well. When you do not use the S3 APIs for an hour, the credentials expire, and the signed URL won't work after that. I can see the credentials (Cognito) are refreshing, but I don't think that is being used here. Upgrading to v6 at this juncture would require us to do a through round of testing
As a workaround, I am moving away from the storage plugin and getting a presigned url from the backend to upload the file. I will let you know how that goes
Thanks @vinu-ablabs for all the context. We will dig deep into the root cause in v5 and follow up with next steps. Thanks for the patience
hello @vinu-ablabs . In the mean time can you try the following setting in your config and see if that ends up working for you?
{
AWSS3: {
bucket: ******,
region: *******,
resumable: true
}
}
@israx That didnt work. Still getting the error
hey @vinu-ablabs . Following up on the issue. You are mentioning that after 1 hour even the preSigned URL won't work. This is expected behavior as credentials have a default expiration of 50 minutes. A potential work around is to refetch the preSigned URL on an interval or just manually increasing the expiration date.
What I'm still not able to repro is the failing calls to the put
API after credentials have expired. I see that the library will refresh them after expiration
@israx When i said presignedUrl, I didnt mean the url you fetched via preSIgnedUrl method. From what I understood/assume is assumed, the sdk signs the put url with a credentials which expires like you mentioned. Once it fails its not really refreshing the url/credentials and further attempts to upload fails. It works once you refresh the whole screen and the library reinitializes.
The repo we have is tied to the company. Will see if we can reproduce the issue on a barebone repo and share it with you. Might take some time to do that
hey @vinu-ablabs . The way am testing and not able to reproduce this issue is by doing the following:
Storage.put
Storage.put
. Here I see the library is refreshing credentials and able to upload a file successfully.Something that might be happening is that your refresh_token
might be expired when calling Storage.put
. In that case the library will clear tokens. You can check the expiration date of your refresh_token
by going to your user pool and select your app client id
.
If that is not an issue, then something that can help is to provide a sample app or more specific steps to reliable reproduce the issue.
Before opening, please confirm:
JavaScript Framework
React
Amplify APIs
Storage
Amplify Version
v5
Amplify Categories
storage
Backend
None
Environment information
Describe the bug
We use amplify with Cognito and have some user uploaded files pushed to S3. Both both reactJs webapp and react native mobile app do similar functions.
If the user leaves the screen unattended for more than an hour, further invocation of Strorage.Put keeps failing, saying the session token has expired. It resumes working only after refreshing the page. We checked the amplify-user in IAM console and it is configured to have access keys
It looks like Amplify signs the S3 URL and does not refresh the token even after the session expires. Ideally, since it is a key based signature, the token is an optional parameter. All further attempts give the same error and the session error. Initially we thought it to be a cognito token expiry but turns out that is not relevant here
Expected behavior
Ideally, the token should refresh if it fails and a new signed url should be created. If not we need to do this at our backend servers and push the new signed url to front end. Trying to avoid this.
Reproduction steps
Use amplify Storage in any reactJs app leave the app idle for an hour Try uploading a file
Code Snippet
Log output
aws-exports.js
Manual configuration
Additional configuration
No response
Mobile Device
No response
Mobile Operating System
No response
Mobile Browser
No response
Mobile Browser Version
No response
Additional information and screenshots
No response