Login Page Continuously Refreshing in QA Environment, Works Fine Locally

0
Hi Team,I am facing a strange issue in my Mendix application and would appreciate any guidance.Application SetupI have a custom login page with a dynamic background image.Navigation ConfigurationDefault Home Page → Custom Login PageSign-In Page → Custom Login PageNo anonymous role-based home page is currently configured.Login Page StructureThe login page contains a main data view.Data Source: MicroflowThe data source microflow performs the following:Retrieves the active LoginImage object.Creates a non-persistent entity (NPE) named MiscHelper.Stores the retrieved LoginImage in an association: MiscHelper_LoginImage.Returns the MiscHelper object.The login page then uses the following:MiscHelper_LoginImage to display a dynamic background image.IssueEverything works perfectly in my local environment.However, after deployment to QA:When accessing the application URL, the browser continuously refreshes.The login page never loads completely.The URL keeps reloading in a loop.Important FindingsI attached the debugger to the datasource microflow of the login page.Surprisingly, the data source microflow is never triggered in QA.The page starts refreshing before the datasource microflow executes.Browser ConsoleI am seeing the following error:POST .../xas/ 401 (Unauthorized) along with repeated refreshes.QuestionsCan a login page configured as both the default home page and sign-in page cause a refresh loop?Has anyone experienced a situation where a page refreshes continuously before the datasource microflow is executed?Can a page parameter / NPE initialization on a sign-in page cause this behavior?Is the 401 Unauthorized on /xas/ likely related to page initialization, security, or authentication configuration?AttachmentsI have attached:Navigation configuration screenshotLogin Page structure screenshotDatasource microflow screenshotAny suggestions on where to investigate next would be greatly appreciated.Thanks in advance!
asked
2 answers
0

Hi Harsh,


Since the login page works locally but continuously refreshes in QA, I would first investigate the 401 Unauthorized response from /xas/ and the authentication/session handling, rather than the datasource microflow itself.


I would check the following:

  1. Review the failed network request: Open the browser’s Developer Tools → Network tab, enable Preserve log, and reproduce the issue. Inspect the failing /xas/ request, including its request payload, response body, cookies, and any preceding redirects. This should help identify whether the failure occurs during authentication or session initialization.
  2. Check session cookies and environment configuration: Compare the local and QA environments. Verify the application URL and domain, HTTPS configuration, cookie handling, and any reverse proxy or load balancer settings. If cookies are missing, rejected, or not sent correctly in QA, the client may repeatedly attempt to initialize an authenticated session.
  3. Verify navigation and security settings: Configuring the same custom page as both the default home page and the sign-in page does not automatically cause a refresh loop. However, verify that the page and its dependencies are accessible in the intended authentication state. Mendix can redirect users to the configured sign-in page when they attempt to access a resource they are not authorized to use.
  4. Test without the custom datasource: Temporarily remove the datasource microflow and display a static login page. If the loop continues, this helps narrow the issue to navigation, authentication, or session initialization rather than the LoginImage retrieval or non-persistable MiscHelper object.
  5. Check runtime logs: Correlate the failing browser request with the QA runtime logs to identify whether the request is rejected because of an authentication, session, or security error.


My first step would be to inspect the failing /xas/ request and its response. The fact that the datasource microflow never executes suggests the failure may occur before the page reaches that stage, but the network trace is needed to confirm this.


References:


Hope this helps!

answered
0

The key clue here is that the datasource microflow never executes in QA, while the browser repeatedly receives 401 Unauthorized responses from /xas/.

This suggests the issue occurs during authentication or page initialization, before Mendix reaches the datasource microflow.

I would investigate the following:

1. Default Home Page vs. Sign-In Page

You mentioned that both point to your custom login page.

The Default Home Page is normally intended for authenticated users, while the Sign-In Page handles unauthenticated access.

Try configuring a separate home page for authenticated users and keeping your custom login page exclusively as the Sign-In Page.

2. Anonymous User Access

Check whether anonymous users are enabled in your project security settings.

If your custom login page depends on a datasource microflow, verify that the appropriate unauthenticated user context has permission to execute it and access the required entities.

3. Microflow and Entity Permissions

Your datasource microflow retrieves a persistent LoginImage object and associates it with an NPE (MiscHelper).

Verify that the relevant user role has:

  • Permission to execute the datasource microflow.
  • Read access to the LoginImage entity and required attributes.
  • Appropriate access to MiscHelper and its association.

4. Investigate the /xas/ 401 Response

A 401 Unauthorized response is not necessarily the root cause, since authentication-related requests can legitimately return 401.

However, repeated 401 responses combined with continuous page reloads suggest an authentication or session initialization problem.

Check the Network tab to identify which /xas/ action fails and whether the application redirects or reloads immediately afterward.

5. Compare Local and QA Configurations

Since the application works locally, compare:

  • Project security settings.
  • User roles and module roles.
  • Anonymous access configuration.
  • Environment-specific authentication settings.
  • Any SSO or reverse-proxy configuration in QA.

My recommendation:

Start by separating the Default Home Page from the Sign-In Page and temporarily testing a simple login page without the datasource microflow.

If the refresh loop continues, the problem is likely occurring before your page-specific logic executes.

If the simplified login page works, progressively reintroduce the datasource microflow and dynamic image to isolate the issue.

answered