Open PanGian97 opened 2 years ago
Hello @PanGian97,
What your describing sounds like the behavior I would expect if your application doesn't clean up subscriptions when one user logs out and another logs in. Is this the case?
These subscriptions are managed by an open WebSocket, where auth is managed when the websocket is opened. When the last subscription is unsubscribed, then the socket is closed. If any subscription is open while user A logs out and user B logs in, then when user B opens their subscriptions it will continue with the connection authenticated for user A.
I've seen two approaches to ensuring this happens.
Component cleanup:
function MyComponent () {
useEffect(() => {
const sub1 = PubSub.subscribe('myTopicA').subscribe({
next: data => console.log('Message received', data),
error: error => console.error(error),
complete: () => console.log('Done'),
});
return () => sub1.unsubscribe();
}
}
When the user logs out, all session components are unloaded, calling the cleanup functions on these useEffects to prompt subscriptions to close and the connection to close.
useState([])
in React) so that the Auth close behavior can loop through and unsubscribe when the user is logging out, which will close the websocket connection.For this purpose, it might be useful to offer something like PubSub.closeAllConnections()
that can be called on logout to ensure the websockets don't outlive the user session.
Even if one of the above recommendations works for your use-case, I would be inclined to leave this issue open as a feature request to offer something like this close all behavior.
Hope this helps. I appreciate the detail you put into this issue.
Thanks, Aaron
Before opening, please confirm:
JavaScript Framework
React
Amplify APIs
PubSub
Amplify Categories
auth
Environment information
Describe the bug
I'm using PubSub to subscribe to mqtt topics. I will describe you a scenario that it's behavior is faulty.
Let's say we have a react web app with amplify authenticator to handle sign-in/out. We have 2 users (userA userB)
userB stops receiving messages or isn't able to subscribe successfully ONLY if he reloads the page after sign-in.
The above can be fixed by automatically calling unsubscribe method on user sign-out (but it isn't a good and safe practice)
userA is able to subscribe successfully ONLY if he reloads the page after sign-in.
Please reply me cause i rely all my web application on Amplify, and as you can see a behavior like this isn't acceptable
Expected behavior
Accoring to the bug's description scenarios...
1st scenario (should work as):>userA sign-in -> attempt to subscribe(let's say pressing a sub button) -> subscribes successfully to aws iot -> decides to sign-out -> userB sing-in from the same machine ->attempt to subscribe(let's say pressing a sub button) -> cannot subscribe succesfuly because he has NOT the authority for this action according to his cognito identity id. (without the need for a page reload)
2nd scenario (should work as):>userB sign-in -> attempt to subscribe(let's say pressing a sub button) -> cannot subscribe successfully because he doesn't has the authority based on his cognito identity id -> decides to sign-out -> userA sing-in from the same machine ->attempt to subscribe(let's say pressing a sub button) -> subscribes successfully because he has the authority for this action based on his cognito identity id . (without the need for a page reload )
Reproduction steps
I explained on details on bug description above by mentioning 2 complete scenarios (use cases)
Code Snippet
Log output
aws-exports.js
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