Open Closed

Session Lost on Mobile Browsers (iOS/Android) After Closing Tab #8885


User avatar
0
pooria.shariatzadeh@gmail.com created
  • ABP Framework version: v8.3.4

  • UI Type: Blazor WebApp

  • Database System: MongoDB

  • Tiered Auth Server Separated: yes
    hi

Users experience session loss when logging in via Safari or Chrome on iOS/Android. When they close the browser tab and reopen it, they are required to authenticate again via the auth server. This issue does not occur on desktop browsers (e.g., Chrome on PC), where the session persists as expected.

Steps to Reproduce:

Login to the platform using Safari or Chrome on an iOS/Android device.
Close the browser tab (without logging out).
Reopen the website in a new tab.
Observe that the session is lost, and the user must authenticate again.
Expected Behavior:
The session should persist after closing the tab, similar to how it behaves on desktop browsers.

Actual Behavior:
The session is lost, requiring re-authentication.

Additional Information:

Affects both Safari and Chrome on iOS/Android.
Works as expected on desktop browsers.
Cookies, session storage, or authentication token handling might be different on mobile browsers.
Request:
Investigate and resolve the issue to ensure session persistence across mobile browsers after closing and reopening tabs.


7 Answer(s)
  • User Avatar
    0
    berkansasmaz created
    Support Team .NET Developer

    Hello,

    Can you update the cookie addition part of the ConfigureAuthentication method of the MyAppBlazorModule class as follows and try again?

       .AddCookie("Cookies", options =>
                {
                    options.ExpireTimeSpan = TimeSpan.FromDays(365);
                    options.SlidingExpiration = true;
                    options.Cookie.HttpOnly = true;
                    options.Cookie.SecurePolicy = CookieSecurePolicy.Always;
                    options.Cookie.SameSite = SameSiteMode.None;
                    options.Cookie.IsEssential = true;  // Ensure cookies are not cleared by tracking prevention
                    options.IntrospectAccessToken();
                })
    

    Screenshot 2025-02-28 at 15.57.40.png

  • User Avatar
    0
    pooria.shariatzadeh@gmail.com created

    Hi @berkansasmaz,

    Thank you for your response, and I apologize for my delayed reply. I needed to update my staging environment to verify whether the issue was resolved.

    Unfortunately, after implementing your recommendations, the problem still persists. The session is still lost after closing the tab on mobile browsers.

    Do you have any additional suggestions or troubleshooting steps I should try?

    Best regards,

  • User Avatar
    0
    EngincanV created
    Support Team .NET Developer

    Hi @berkansasmaz,

    Thank you for your response, and I apologize for my delayed reply. I needed to update my staging environment to verify whether the issue was resolved.

    Unfortunately, after implementing your recommendations, the problem still persists. The session is still lost after closing the tab on mobile browsers.

    Do you have any additional suggestions or troubleshooting steps I should try?

    Best regards,

    Interestingly, the same issue doesn't occur on desktop browsers like Chrome on PC, where the session persists as expected. This could be tied to how cookies, session storage, or authentication tokens are handled differently on mobile browsers compared to desktops.

    Can you check in your App.razor file there is a code as stated in https://abp.io/docs/9.0/release-info/migration-guides/abp-8-2-blazor-web-app#mycompanyname-myprojectname-blazor-webapp-tiered-and-mycompanyna

  • User Avatar
    0
    pooria.shariatzadeh@gmail.com created

    Hi @EngincanV,

    Thank you for your detailed response and for pointing me in the right direction.

    I reviewed my App.razor file and compared it with the recommended implementation. Here are my findings:

    1. PersistentComponentState Configuration:

      • In your example, RenderMode.InteractiveWebAssembly is used, whereas in my implementation, I have RenderMode.InteractiveAuto.

      • Would switching to RenderMode.InteractiveWebAssembly help ensure better persistence across mobile browsers?

    2. Authentication Configuration:

      • I have the following configuration in ConfigureAuthentication inside MyProjectNameBlazorClientModule:

        private static void ConfigureAuthentication(WebAssemblyHostBuilder builder)
        {
            // TODO: Remove SignOutSessionStateManager in new version.
            builder.Services.TryAddScoped<SignOutSessionStateManager>();
            builder.Services.AddBlazorWebAppServices();
            builder.Services.AddBlazorWebAppTieredServices();
        }
        
      • In the provided reference, only builder.Services.AddBlazorWebAppTieredServices(); is mentioned.

      • Could there be a conflict or redundancy with SignOutSessionStateManager in mobile browsers that affects session persistence?

    3. Session Persistence on Mobile Browsers:

      • As you pointed out, mobile browsers might handle cookies, session storage, or authentication tokens differently.

      • Is there any recommended approach for ensuring authentication token persistence in Blazor WebAssembly for mobile browsers specifically?

      • Would explicitly persisting the token in sessionStorage or localStorage on mobile browsers help mitigate this issue?

    I'd appreciate any further insights or recommendations you may have on this.

    Best regards,

  • User Avatar
    0
    EngincanV created
    Support Team .NET Developer

    Would switching to RenderMode.InteractiveWebAssembly help ensure better persistence across mobile browsers?

    Hi, I don't think it does. Because, when you use auto mode, it first connects via blazor server and then switches to wasm (when the DLLs are downloaded to the browser). So, you can keep InteractiveAuto unless you want strict WASM execution.

    Could there be a conflict or redundancy with SignOutSessionStateManager in mobile browsers that affects session persistence?

    Yes, this may conflict with session persistence in mobile browsers. Mobile browsers handle session storage differently as you said, possibly triggering unintended sign-outs. So, you can try to remove SignOutSessionStateManager and test if session persistence improves or not.

    Is there any recommended approach for ensuring authentication token persistence in Blazor WebAssembly for mobile browsers specifically?

    Would explicitly persisting the token in sessionStorage or localStorage on mobile browsers help mitigate this issue?

    Storing the token in localStorage might be the best option, since it persists across tabs and restarts and there is no expiration.

  • User Avatar
    0
    pooria.shariatzadeh@gmail.com created

    Hi @EngincanV,

    Thank you for the clarification and insights.

    Storing the token in localStorage might be the best option, since it persists across tabs and restarts and there is no expiration.

    Based on your suggestions, I will test removing SignOutSessionStateManager to see if session persistence improves on mobile browsers.

    Regarding authentication token persistence, I understand that storing the token in localStorage might be the best approach for ensuring it persists across tabs and restarts. However, since mobile browsers handle storage differently, could you recommend the best implementation practice for securely storing and retrieving the authentication token in localStorage specifically for mobile browsers?

  • User Avatar
    0
    EngincanV created
    Support Team .NET Developer

    Based on your suggestions, I will test removing SignOutSessionStateManager to see if session persistence improves on mobile browsers.

    Hi, I will be waiting for your response.

Boost Your Development
ABP Live Training
Packages
See Trainings
Mastering ABP Framework Book
Do you need assistance from an ABP expert?
Schedule a Meeting
Mastering ABP Framework Book
The Official Guide
Mastering
ABP Framework
Learn More
Mastering ABP Framework Book
Made with ❤️ on ABP v9.2.0-preview. Updated on March 13, 2025, 04:08