The login page displays the correct project label or company branding after customization is applied at the layer that owns the unauthenticated request. A protected Perspective project cannot reliably replace the page that blocks it from loading; use the built-in project title or gateway-wide branding for presentation changes, and place custom middleware before Ignition only when the application must own routing and the complete login experience.
Where does the login request stop?
Follow the packet. The browser first reaches the Perspective session endpoint. If that project requires authentication, the gateway redirects the unauthenticated request into its login and identity-provider path before loading the protected project view. The login page therefore belongs to the pre-project authentication path, while a custom Perspective view belongs to the project itself.
| Stage | Request handler | What is available | Failure indication |
|---|---|---|---|
| Network connection | Gateway or upstream middleware | Configured host, port, and transport | No page, connection error, or certificate error |
| Unauthenticated session request | Perspective gateway | Gateway authentication and IdP configuration | Redirect to the default login page |
| Identity validation | Configured IdP or user source path | Credentials and authentication policy | Rejected login or redirect loop |
| Authenticated project load | Perspective project | Views, session properties, and project navigation | Project-level error after login |
Layer one first: confirm that the browser reaches the intended gateway or middleware address and port before debugging scripts. Then inspect the redirect sequence. If the default login page appears before the custom view, the connection works and the request has stopped at the unauthenticated gateway stage.
A login button inside a custom view was tested with the following call:
system.perspective.login(username=username, password=password)In that configuration, the call did not validate the supplied credentials. The session immediately returned to the default page because authentication was required before the custom view could become the active login surface. Moving fields or scripts within the protected project does not change that ordering.
Which customization path fits the requirement?
| Approach | Best fit | Authentication owner | Scope | Main constraint |
|---|---|---|---|---|
| Display the project title | Replace an identifier such as Some_Project with Some Project
|
Ignition | Project label | Depends on an Ignition release that includes the title change |
| Perspective branding customization | Add shared branding such as a company image or theme | Ignition | Gateway-wide across Perspective projects | Cannot provide different branding for each project on the same gateway |
| Custom Perspective login view | Project UI after the session can load | Ignition | Inside the project | Cannot replace a pre-project authentication redirect in the tested protected-session design |
| Custom middleware with Ignition IdP | Own the entry page and route users to different projects | Ignition IdP, with routing handled by middleware | Deployment-defined | Adds another application, address, redirect path, and operational dependency |
For a spacing or capitalization problem, select the project-title path. For a common logo or theme, select Perspective branding customization. Use middleware only when routing users among projects or replacing the complete entry experience is a real requirement. A custom project view is not the recommended route when the gateway must authenticate users before project content loads.
How should the project title be used?
Keep the machine-oriented project name and the human-readable project title separate. In the stated case, the project name is Some_Project and the desired display text is Some Project. The title change was first discussed as a possible 8.0.2 delivery, then later targeted for 8.0.4 after an earlier implementation was rejected by QA and revised. The later target still depended on approval and QA, so the installed build must decide the result.
- Open the project configuration and set the title to the exact user-facing text.
- Save and publish the project using the normal deployment workflow.
- Start a new unauthenticated browser session rather than reusing an already authenticated tab.
- Observe the label on the login page. If it still uses the project name, check the installed Ignition version and its release information for the project-title change.
- Retest after applying an appropriate approved release; do not rename the project merely to change presentation unless every project reference and launch path has been assessed.
This route leaves authentication, credential validation, and redirects under Ignition control. It changes the displayed identity without inserting another component into the request path.
When does gateway-wide branding solve the problem?
Perspective co-branding added a gateway configuration category at Config > Perspective > Branding Customization. Its purpose is to apply branding to Perspective projects, including visual changes such as an image and brand theme. The setting is gateway-wide and affects all Perspective projects hosted by that gateway.
- Inventory the Perspective projects on the gateway and confirm that they may share one brand treatment.
- Open
Config > Perspective > Branding Customization. - Configure the required brand image and theme using the fields present in the installed build.
- Apply the change and open each affected project in a fresh unauthenticated session.
- Check the login surface at common desktop and mobile dimensions, including image scaling, text contrast, and the visibility of credential controls.
Do not select this approach when projects on the same gateway require distinct company logos. Its shared scope also means a change made for one project can alter every other Perspective login experience on that gateway. The Perspective setting does not serve as a confirmed customization mechanism for gateway status and configuration pages; distinguish DEV, TEST, and PROD gateway pages by their verified hostnames and deployment controls before making configuration changes.
When is middleware the right recommendation?
Middleware is justified when one entry application must present a completely custom login experience and then distribute authenticated users to different Perspective projects. The working architecture used Ignition's IdP features for identity and permissions while the middleware managed redirection to the appropriate project.
| Decision field | Direct Perspective path | Middleware path |
|---|---|---|
| Initial address | Perspective project URL | Middleware URL |
| Port | Gateway deployment setting | Middleware deployment setting, then gateway setting |
| Login timing | Before protected project content | Before project selection and final redirect |
| Permission decision | Ignition identity and project rules | Ignition identity and project rules |
| Project routing | Fixed by requested project URL | Selected by middleware logic |
| Operational burden | Gateway only | Middleware plus gateway and their redirect integration |
Keep credential validation with the configured IdP rather than creating a second password authority. The middleware should initiate or coordinate the authentication flow, retain only the state required to complete it, and redirect the authenticated browser to an authorized project. Never log passwords. Validate the middleware-to-Ignition return address, transport protection, session state, and rejection behavior using the actual settings shown by those components; no address, port, or timeout value is universal.
How do you verify the selected fix?
- Open a private browser window so cached authentication cannot hide the pre-login path.
- Enter the exact launch address and confirm which host and port answer the initial request.
- Use the browser network trace to record each redirect in order: entry endpoint, authentication endpoint, return endpoint, and final Perspective project.
- For a title change, confirm that
Some Projectappears andSome_Projectis no longer exposed as the login-page label. - For branding, test more than one Perspective project on the gateway and confirm that the gateway-wide treatment appears on all of them.
- For middleware, test a valid user, an invalid password, a user without permission to the selected project, a direct request to a protected project, and an expired session.
- Confirm that a failed login remains outside the protected project and that a successful login reaches only the project permitted for that identity.
A redirect loop points to disagreement among the entry address, authentication return path, or session state. A direct jump to the default page shows that the browser reached Ignition before the custom entry path took ownership. A page that loads correctly but displays the wrong title is a presentation-version or project-configuration problem, not a credential-validation problem.
FAQ
What happens if a protected Perspective project uses a custom login view?
The gateway can redirect the unauthenticated request to its default login page before the project loads. The custom view and its system.perspective.login() call therefore never become the first authentication surface.
What happens if the project title still shows the project name?
Confirm the configured title, then check whether the installed Ignition build contains the title-display change. The work was tentatively associated with 8.0.2 and later targeted for 8.0.4 pending approval and QA.
What happens if I change Perspective branding on one project?
The setting under Config > Perspective > Branding Customization is gateway-wide, so the change affects all Perspective projects on that gateway. Review every hosted project before applying a new image or theme.
What happens if users must be sent to different projects after login?
Place middleware at the entry point to manage project selection and redirection while Ignition's IdP continues to authenticate users and drive permissions. Test unauthorized destinations as well as successful routes.
How do I verify an Ignition Perspective login redirect?
Start a private session, capture the browser network trace, and follow every redirect from the initial host and port through authentication to the final project. The final check is that valid credentials reach only the authorized project while invalid credentials remain outside all protected views.