react-native - app in background w/ setTimeout and push notification

We’re running into an issue where Push Notification code is being executed before the setTimeout handler is executed when the app is coming into the foreground. Here is the sequence of events:

  1. User launches the app. setTimeout(this.logout, 10000) gets called.
  2. App is put into the background. Timer continues to count down.
  3. Wait for 10 seconds to pass. Because the app is in the background, this.logout callback will not be invoked until the app is bought back into the foreground.
  4. Push notification is sent to device.
  5. Now, user taps on the Push Notification, which opens the app.
  6. Push Notification code is executed
  7. this.logout code is executed immediately.

The result is that the user is kicked out of the app before he can view the Push Notification.

Is there a way to somehow re-arrange the events in the Event Queue so that this.logout is executed first and Push Notification handling code executed second?

Edit: We’re using the Expo Push Notifications SDK

Sample Code

componentDidMount() {
  this.notifications = Notifications.addListener(this.handleNotification);
  this.timeout = setTimeout(this.logout, 10000);
}

componentWillUnmount() {
  Notifications.remove(this.notifications);
}

this.handleNotification = () => { ... }
this.logout = () => { ... }
1 Like

I’m hung up on what is the purpose of waiting 10 seconds and then logging the user out. Is this happening right when the app launches, or, say, only when the user presses a logout button sometime after opening the app? If the latter is the case, I think you’ll get further if you can find a way to let your logout code execute immediately. It can get real complicated if you’re depending on all these events to fire in a particular order after the app resumes.

@llamaluvr

In our app, we have a business requirement to sign the user out after 5 minutes of idle time. I used 10 seconds without any idle handling logic (i.e. PanHandler) here as a simpler example to get my point across.

All of the stuff I mentioned is happening due to a combination of setTimeout reaching 0 while the app is in the background and the user opening a push notification afterwards. There’s no user interaction involved other than putting the app into the background.

One workaround I saw somewhere was to turn off the setTimeout when the app goes into the background/foreground and record separate timestamps… When processing the push notification, we can compare the timestamp of when the app went into the background vs when the app came into the foreground against the max timeout. If the difference >= the session timeout, then delay the push notification processing by using setTimeout (so it gets placed at the end of the event queue). Then process the logout logic immediately to log the user out of the app. Otherwise, start the countdown timer with the remaining time while the app is in the foreground.

I’d highly-recommend you look into enforcing the idle timeout from the server side. If you’re depending on the mobile client to log the user out after a set period of time, well, there’s a lot of ways that might not actually happen (the user force-closes the app, the phone shuts off, app is cleared from memory, etc.). Additionally, the API could be abused directly by an attacker to keep a session from ever ending. This is possibly one of the most common and easily-discovered security vulnerabilities.

Generally, server side session idle expiration works by resetting the time on a session every time an API endpoint is called by the client app while the user is logged in. It’s not a perfect proxy for actual activity in the app, but it’s generally pretty close (how likely is a user to go 5 minutes in your app without any network I/O?). Then, if an endpoint is called after the timeout, a 401 unauthorized is returned and the app kicks the user back to the login screen. No JavaScript timeouts needed. Just make sure you phone home after the app resumes.

Feel free to throw OWASP resources at business folks who object to such security measures (e.g., Session Management - OWASP Cheat Sheet Series). I’ve fought this battle before and won. You can, too!

If for some (non-security-related) reason you still need to track time elapsed while an app is backgrounded, you can always record the time when the app is backgrounded, and then check the recorded time against the current time after the app comes active again. If the duration is greater than X minutes, you can take whatever actions you need to. That way, no times are needed (though I couldn’t tell you what order app status events fire as compared to push notification events, so you might end up with the same issue).

Thank you so much for this. I was into this issue and tired to tinker around to check if its possible but couldnt get it done. Now that i have seen the way you did it, thanks guys
with
regards
https://get3dsemulator.org/ https://pandahelper.me/ https://kissanime.tips/

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.