Mobile web browser forcing users to login too often

[mebeingken]

I have a project that is in production and on desktop and mobile works well, with one major annoyance. In mobile browsers (chrome and safari, iOS and Android), the users all too often end up back on the login screen after periods of inactivity (a few hours or more).

The user experience is:
Login
Navigate all through the app for as long as a user wants…no issues
Leave the tab in the browser open, and go about other things in life.
Come back the next day, and go to the open tab in the mobile browser. Tap to navigate to another link, and get redirected to the login screen.
User logins in, and all is well until they leave again.

Now if a user closes the tab, and then opens a new tab, and goes to the site, they are recognized and there is no login.

I have never experienced the problem on desktop, only mobile.

It has me thinking the memory management of mobile browsers is discarding the auth cookie, so when coming back the server sets a new one.

So I’m wondering if anybody else experiences this? If y’all tell me you have web apps running in mobile and experiencing no login issues, I’d be curious to here about your infrastructure (this project is Apache reverse proxy to node).

The site security cookie was being set with the default settings and in troubleshooting is now set for 365 days, Secure and same site Strict.

Any and all thoughts welcome and appreciated!

[brad]

I too experience this with my mobile app. After much research I found out that mobile apps don’t use cookies so setting the cookie time out to a million won’t help. The login uses the identity session.

Unfortunately, mobile devices will randomly go through and clear any sessions it believes is ‘garbage’.

I have tried using the scheduler to varying degrees of success to keep the session alive. Not completely reliable.

Now there are Cordova plugins available to keep sessions alive indefinitely.

cordova-plugin-keep-alive-mode

Unfortunately there is no documentation so I have not tried it. I’ll be watching this topic closely!

[mebeingken]

Thanks Brad, I should have emphasized more that this is a web application, not an app store app.

Incidentally, I do have a PHP project driving an app store app (PopDish) and I can go weeks without having to login. I built that before the major changes to cordova, Wappler support, etc. and it did involve some carefully scripted work to make it happen, but I just checked the app having not been there in a few weeks and it maintained my login even across an iOS update and restart.

[brad]

I see. Well, then your cookie setting should be active. If you view in a regular web browser is it setting the proper cookie expiry date in the dev tools? I wish there was a way to check that directly on a mobile device.

[mebeingken]

Yes on desktop and mobile I can see the proper cookie setting and expiration.

EDIT: Actually Brad you caused me to check this again, and the session cookie is set, but not the .auth. Thanks for that…something for me to investigate.

I think this was a faulty test.

[brad]

Hopefully you will post your findings! Good luck!

[mebeingken]

@patrick (et al) perhaps you can help me understand this?

For a moment, disregard the above about mobile only.

The new test I performed:

I changed the session timeout to 60 seconds using the server connect config setting.

I then login to the application and see the .auth cookie set:

I wait 65 seconds for the session to expire and click another link in the app and a new session is set, and also a new .auth. You can see the request sent the previously set .auth starting with s%3AO5, but it returns a new value in the response along with a new .sid session:

Maybe my understanding of how this works is incorrect, but I thought the .auth cookie, when sent in the request, would maintain the logged in state, regardless of the session expiration.

I’ve tried this with an Apache reverse proxy and Caddy, just in case that somehow was bungling things, but that does seem to matter here.

Have I misunderstood how this is intended to work?

[patrick]

The auth cookie contains yor credentials encrypted, it is used when the session is expired to login you again and the new login will create a new auth cookie.

[mebeingken]

Thanks. This auto login should also be happening when an internal link is clicked, correct? In other words, it should work when linking to a content page where the layout is not reloaded, only the view?

Also, this auto login process takes place before the server connect global steps are run, and before the server side data is run where the security restrict is typically placed?

[mebeingken]

@patrick Here is what I’m seeing. From the users perspective, they are redirected to /login after sessions have expired.

My layout (the only one used):

The content page:

The valid_sub action attached to all content pages using the Server Side Data:

And my latest test:

I set the redis session timeout to 30 seconds:

I clear all cookies and refresh the page:

The I login:

I then wait for the session to expire and click on a link in the app:

<li class="nav-item" dmx-on:click="browser1.goto('/recipes',true,'Recipes')" onclick="closeSidebar()"

This is the click on link:

And the cookies after the link was processed:

So it looks like the remember me cookie is properly reset on the link click, but the content page restrict is still redirecting users to login. This seems to be confirmed by the fact that even though the user lands on /login, they can still click on another link and successfully reach the destination.

Obviously you will know better, but it sure looks like the security restrict is done before the user is automatically logged in using the cookie.

Interested to hear what you think is going on!

[patrick]

It looks to be something specific for NodeJS with the new server-side templates when you use server connect to restrict the page server-side. I don’t believe we had this problem with the security provider before.

Does the restrict only cause problems when the session expired and there was a partial update (ajax load) or also when the full page is reloaded?

[mebeingken]

I repeated the test, but instead of clicking on a link after the session expired, I refresh the page, and the same behavior happened – I was redirected to /login but could navigate to other pages since I technically was still logged in.

[patrick]

I checked your server action steps, you directly check the identity, how do you retrieve this identity?

[mebeingken]

To make a cleaner test I modified to have only the security restrict action…same results. But to answer your question, I have the identify in global steps.