matt-at-allera
commented
1 month ago @cwomack Hi Chris, is there any triaging results to report on? This is a large blocker for specific customers of ours.
Closed matt-at-allera closed 1 month ago
matt-at-allera
commented
1 month ago @cwomack Hi Chris, is there any triaging results to report on? This is a large blocker for specific customers of ours.
cwomack
commented
1 month ago Hey, @matt-at-allera and thanks for opening this issue. I'm working to reproduce this behavior on my side with a v5 app that runs through the reproduction steps you've outlined. Is the service worker (or others) handling anything else beyond respond with 503 errors when offline requests are made?
matt-at-allera
commented
1 month ago Thanks for the update @cwomack.
No, the service worker isn't handling anything else that is notable. I will share the relevant code in the service-worker.ts file:
// Any other custom service worker logic can go here.
let isOnline = navigator.onLine;
self.addEventListener('message', (event) => {
if (event.data.type === 'ONLINE_STATUS') {
isOnline = event.data.isOnline;
console.debug(`Service Worker: Online status is now ${isOnline ? 'online' : 'offline'}`);
}
});
self.addEventListener('fetch', (event) => {
if (!isOnline) {
event.respondWith(
new Response(JSON.stringify({ error: 'Offline mode: No network connection' }), {
status: 503,
headers: { 'Content-Type': 'application/json' },
})
);
} else {
event.respondWith(
(async () => {
try {
const response = await fetch(event.request);
return response;
} catch (error) {
// Fallback response in case there is no cached response and fetch fails
return new Response('Service is currently offline.', {
status: 503,
statusText: 'Service Unavailable',
headers: new Headers({ 'Content-Type': 'text/plain' }),
});
}
})()
);
}
});The service worker tracks online status based upon a combination of navigator.onLine and a forceOfflineMode state variable that we relay from our app code to the service-worker via events of type 'ONLINE_STATUS' as you can see above. The logging out issue occurs for all permutations of 1) no wifi signal, 2) device wifi turned off, 3) offline mode forced, and 4) no wifi signal and offline mode forced
matt-at-allera
commented
1 month ago Hi @cwomack could you share the results of the test you performed? Is there additional information needed?
matt-at-allera
commented
1 month ago I believe I found out why this may be occurring. I noticed that if I toggle the browser to offline mode and then enable online mode, that a request to Cognito is immediately made for the REFRESH_TOKEN_AUTH auth flow
curl 'https://cognito-idp.us-east-1.amazonaws.com/' \
-H 'sec-ch-ua: "Not/A)Brand";v="8", "Chromium";v="126", "Google Chrome";v="126"' \
-H 'sec-ch-ua-mobile: ?0' \
-H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36' \
-H 'Content-Type: application/x-amz-json-1.1' \
-H 'Cache-Control: no-store' \
-H 'Referer: <url>/' \
-H 'X-Amz-Target: AWSCognitoIdentityProviderService.InitiateAuth' \
-H 'X-Amz-User-Agent: aws-amplify/5.0.4 @aws-amplify/ui-react/5.3.3 auth framework/1' \
-H 'sec-ch-ua-platform: "macOS"' \
--data-raw '{"ClientId":"<ClientId>","AuthFlow":"REFRESH_TOKEN_AUTH","AuthParameters":{"REFRESH_TOKEN":"<token>","DEVICE_KEY":null}}'If I quickly toggle the browser back to offline, the request fails with the 503. Upon the failure, the auth seems to fire off requests that revoke all tokens in local storage:
curl 'https://cognito-idp.us-east-1.amazonaws.com/' \
-H 'sec-ch-ua: "Not/A)Brand";v="8", "Chromium";v="126", "Google Chrome";v="126"' \
-H 'sec-ch-ua-mobile: ?0' \
-H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36' \
-H 'Content-Type: application/x-amz-json-1.1' \
-H 'Cache-Control: no-store' \
-H 'Referer: <url>' \
-H 'X-Amz-Target: AWSCognitoIdentityProviderService.RevokeToken' \
-H 'X-Amz-User-Agent: aws-amplify/5.0.4 @aws-amplify/ui-react/5.3.3 auth framework/1' \
-H 'sec-ch-ua-platform: "macOS"' \
--data-raw '{"Token":"<Token>","ClientId":"<ClientId>"}'I'm going to continue to experiment and see if I can hack my way around this. However, it seems like there could be some work done to make this more resilient to intermittent connections on Amplify's end. @cwomack Could you replicate this on your end and let me know what you think?
matt-at-allera
commented
1 month ago This appears to be something initiated programmatically on our end. I'm closing this issue for now.
Before opening, please confirm:
JavaScript Framework
React
Amplify APIs
Authentication
Amplify Version
v5
Amplify Categories
auth
Backend
Amplify CLI
Environment information
Describe the bug
We host our application as a PWA to enable offline usage. Users are complaining of being signed out at random times which is requiring them to go back to a WiFi enabled area before signing back in. For some of our customers, this is not acceptable as it can be a very long time before they are able to return to the ares with signal. We do NOT use DataStore, as we ran into a myriad of unrelated problems while using it before; we have our own in-house solution using IndexedDB.
Here a couple of other tickets that never reached resolution (for reference): https://github.com/aws-amplify/amplify-js/issues/10575 https://github.com/aws-amplify/amplify-flutter/issues/2806
Notably, we are using the
withAuthenticatorHOC:I have also increased the token validation period for both access and id tokens to 24 hours. It's worth noting that changing the values here did not seem to make the issue any better. I think regardless of these settings, the user should be able to remain using the application even with an invalid token:
I did manage to get a screenshot captured of the debugging logs when a user is forcibly logged out. I've converted the screenshot into readable logs:
It appears that the failed Cognito requests (which I do not know exactly what is in the contents of those requests) may have triggered a sign out event. Once the device is deemed offline (either forced offline or by actually losing network connection), we place the service-worker in a state where it rejects all requests with the 503 'Service Unavailable'. At the time of these capture logs, we also were performing a frequent session refresh to see if it alleviated this issue. It did not appear to have any positive effect.
Lastly, we do listen to 'auth' events using the Amplify Hub:
Expected behavior
I expect that users remain logged into our Amplify app while offline. There should be no random logging out. At worst, the user should be logged out when Amplify is certain that there access and/or id tokens have expired, which does not appear to be the case.
Reproduction steps
Code Snippet
Log output
aws-exports.js
No response
Manual configuration
No response
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