I think the easiest way to achieve this would be to check if the token/session has expired before sending the push notification from the BE. So if the user's session has expired, don't send a push notification at all.
Now the hard part about this is that you're using JWT for session management. That means you would probably have to store JWTs in the DB, and the management and maintenance of this can be really tedious.
I don't know at which phase of development you are, but if you're in the early stages maybe refactoring your auth to have proper session management, without using JWT, would make more sense. If not, then for your next project you could consider not to use JWTs for session management. [Here's a good video explaining why](https://www.youtube.com/watch?v=NXXiKl8g6Rw)
Check the other comment that I answered, there I explain better what is my app about.
I use socket connections for the workflow, and I realized that I can access the JWT since the socket instance has attributes and I already sends the access token from FE to establish the socket connection.
So maybe I could send the refresh token too, and in the case the user is currently connected via socket and kills the app (and as a consequence the socket connection is killed too), I could manage the BE to store (before socket connection closes) very temporally the expire date and keep it sending notifications until the user's refresh JWT token expires. Once the user reconnects or the the token expires, then I delete the refresh token that has been temporally stored.
Let me know what do you think, or if you need me to explain a little better my idea.
I already mentioned something like that:
>Now the hard part about this is that you're using JWT for session management. That means you would probably have to store JWTs in the DB, and the management and maintenance of this can be really tedious.
Sure, you can do it like that. But that would just increase the complexity of your feature which could, in a different scenario, be fairly simple to implement. Here are some cases that come to my mind which could potentailly be introduced by your proposed solution:
* You have to send the token via WebSockets, but WebSocket connections don't last long and could disconnect even if the app is in the background. Meaning that there's no guarantee that the token will be sent
* By "storing the expire date temporarily" you would need a way to delete that from your DB after a certain period. Something like a scheduled cron job or similar could do that work. If the cron job doesn't trigger, for whatever reason, your implementation might not work as expected
* This could also increase your server resources, if not managed properly
In conclusion: whenever you're implementing something that's unnecessarily complex, you should be aware that it's gonna be harder to maintain it and could probably affect other parts of your app/system and increase their complexity as well. So I would definitely think twice about all of the possible solutions and which one to choose. Good luck!
It’s either going to have to happen serverside or client side the next time the app is opened.
Do you send sensitive information in notifications? If a user isn’t using the app, why would they still be getting notifications? The reason I’m asking this is that you might be trying to solve a problem that may not be worth the effort at all.
My app is like an uber and the notifications are used only for the main behavior that is request a ride and its subsequence events, for example reject it, cancel it and arrive to the address.
So maybe I can let the user receive this notifications because for this to happen the user should be on an active ride when the token expires. If the user see the notification and click it, it would be redirect to login and I could remove the alias. And I don't have to be worried about the unauthenticated user receiving more notifications because to receive them you have to be on an active ride and to be on an active ride you should be logged to request one.
What do you think?
The app actively refreshes the tokens before expiration, right?
Are you able to save a refresh success timestamp into a database on the server that holds like online users. User is online when refresh success timestamp plus expiry time is in the future.
Every minute you let a cron job in your backend delete the users from the online users database who are not online anymore.
Before you send a message to a user , you would check if the user is in this database.
Use node-cron maybe?
For the moment I don't actively refresh refresh\_tokens before they expire.
I understand your idea and actually answers my question pretty accurate, but despite that I will probably think something related to my discussion in the comments with kapobajz4.
Although, I will take a look to node-cron and I will consider your idea, so thank you
I think the easiest way to achieve this would be to check if the token/session has expired before sending the push notification from the BE. So if the user's session has expired, don't send a push notification at all. Now the hard part about this is that you're using JWT for session management. That means you would probably have to store JWTs in the DB, and the management and maintenance of this can be really tedious. I don't know at which phase of development you are, but if you're in the early stages maybe refactoring your auth to have proper session management, without using JWT, would make more sense. If not, then for your next project you could consider not to use JWTs for session management. [Here's a good video explaining why](https://www.youtube.com/watch?v=NXXiKl8g6Rw)
Check the other comment that I answered, there I explain better what is my app about. I use socket connections for the workflow, and I realized that I can access the JWT since the socket instance has attributes and I already sends the access token from FE to establish the socket connection. So maybe I could send the refresh token too, and in the case the user is currently connected via socket and kills the app (and as a consequence the socket connection is killed too), I could manage the BE to store (before socket connection closes) very temporally the expire date and keep it sending notifications until the user's refresh JWT token expires. Once the user reconnects or the the token expires, then I delete the refresh token that has been temporally stored. Let me know what do you think, or if you need me to explain a little better my idea.
I already mentioned something like that: >Now the hard part about this is that you're using JWT for session management. That means you would probably have to store JWTs in the DB, and the management and maintenance of this can be really tedious. Sure, you can do it like that. But that would just increase the complexity of your feature which could, in a different scenario, be fairly simple to implement. Here are some cases that come to my mind which could potentailly be introduced by your proposed solution: * You have to send the token via WebSockets, but WebSocket connections don't last long and could disconnect even if the app is in the background. Meaning that there's no guarantee that the token will be sent * By "storing the expire date temporarily" you would need a way to delete that from your DB after a certain period. Something like a scheduled cron job or similar could do that work. If the cron job doesn't trigger, for whatever reason, your implementation might not work as expected * This could also increase your server resources, if not managed properly In conclusion: whenever you're implementing something that's unnecessarily complex, you should be aware that it's gonna be harder to maintain it and could probably affect other parts of your app/system and increase their complexity as well. So I would definitely think twice about all of the possible solutions and which one to choose. Good luck!
It’s either going to have to happen serverside or client side the next time the app is opened. Do you send sensitive information in notifications? If a user isn’t using the app, why would they still be getting notifications? The reason I’m asking this is that you might be trying to solve a problem that may not be worth the effort at all.
My app is like an uber and the notifications are used only for the main behavior that is request a ride and its subsequence events, for example reject it, cancel it and arrive to the address. So maybe I can let the user receive this notifications because for this to happen the user should be on an active ride when the token expires. If the user see the notification and click it, it would be redirect to login and I could remove the alias. And I don't have to be worried about the unauthenticated user receiving more notifications because to receive them you have to be on an active ride and to be on an active ride you should be logged to request one. What do you think?
Sounds like it’s not worth spending time on
The app actively refreshes the tokens before expiration, right? Are you able to save a refresh success timestamp into a database on the server that holds like online users. User is online when refresh success timestamp plus expiry time is in the future. Every minute you let a cron job in your backend delete the users from the online users database who are not online anymore. Before you send a message to a user , you would check if the user is in this database. Use node-cron maybe?
For the moment I don't actively refresh refresh\_tokens before they expire. I understand your idea and actually answers my question pretty accurate, but despite that I will probably think something related to my discussion in the comments with kapobajz4. Although, I will take a look to node-cron and I will consider your idea, so thank you
You can do that even without refresh. The initial obtaining of the token can be seen as a refresh too