FOUR-31303 | User Is Not Taken to Original URL After Logging In To ProcessMaker via Single Sign On

[mcraeteisha]

Ticket: FOUR-31303

When an unauthenticated SAML user tries to open a URL (e.g. a web entry), once they are taken to the IdP for authentication, instead of going back to the originally requested URL they are taken to the home page. This also happens when a user loses session and a specific page is reloaded. For example, a user is in the script editor, the page/computer is left idle for a while, and the session expires; reloading the page sends them to the home page instead of staying in the script editor.

Root Cause

The processmaker_intended cookie is dropped on the IdP's cross-site POST

LoginController::showLoginForm() sets a processmaker_intended cookie with the originally requested URL before redirecting to SSO. For OAuth providers the callback is a same-site GET, so the cookie is visible. For SAML the callback is the IdP's cross-site POST to /saml2/acs, and browsers do not send SameSite=Lax cookies on cross-site requests — so the cookie is gone by the time SSOController::acs() runs.

SameSite=Lax on processmaker_intended was added intentionally by commit e68f3c7 per the security audit's guidance, so it must stay. The fix uses SAML RelayState instead — a protocol parameter the IdP echoes back in the POST body, which survives the cross-site POST that the Lax cookie cannot.

DynamicUI's home page pre-empted the /redirect-to-intended recovery hop

HomeController::redirectToIntended() is the recovery hop the SSO callback redirects to when it can't read the cookie itself (a same-site GET, where the Lax cookie becomes visible again). The old fallback ordering checked package-dynamic-ui's configured home page before consulting the cookie, so even when the intended URL was available, the Dynamic UI dashboard would win.

Solution

In package-auth/src/Http/Controllers/SSOController.php, redirect() now copies the processmaker_intended cookie into saml2_settings.loginRoute before invoking the SAML provider. aacotroneo/laravel-saml2 forwards that to OneLogin as $returnTo, which puts the intended URL on the outbound AuthRequest as RelayState. callback() then prefers RelayState over the cookie when deciding where to send the freshly-authenticated user, falling back to /redirect-to-intended only if neither source yields a usable URL, and a new validIntendedUrl() helper rejects cross-host URLs to prevent an attacker-controlled RelayState (or cookie) from turning the SSO callback into an open redirect.

In ProcessMaker/Http/Controllers/HomeController.php, redirectToIntended() now reads the cookie first, and only falls through to package-dynamic-ui's configured home page when the cookie is absent, restoring the documented redirect chain and ensuring the cookie wins over the configured dashboard.

How To Test

Automated

1. Run vendor/bin/phpunit tests/Feature/HomeControllerTest.php. Ensure all tests pass.
2. Run vendor/bin/phpunit vendor/processmaker/package-auth/tests/Feature/Auth/SamlIntendedUrlTest.php. Ensure all tests pass.

On the CI Server

1. Open the web entry URL in a fresh incognito/private window (no existing ProcessMaker session):

   https://ci-a7410d005f.engk8s.processmaker.net/webentry/18/node_1
   

2. You will be redirected to ProcessMaker's login flow, which (because Default SSO Login is set to SAML) auto-redirects to Mock SAML's IdP page.
3. On the Mock SAML page, enter any name and click "Sign In".
4. Expected: you land back on /webentry/18/node_1 and see the web entry form, not the home/inbox page.
5. Login to the server via https://ci-a7410d005f.engk8s.processmaker.net.
6. Under Admin -> Settings -> Log-In & Auth -> Session Control, set Session inactivity to a short amount of time.
7. Navigate to any page in ProcessMaker and wait to be logged out. Log back in via the Mock SAML page.
8. Expected: you are taken back to the page you were originally on when your session timed out.

ci:deploy
ci:package-auth:bugfix/FOUR-31303

Code Review Checklist

• I have pulled this code locally and tested it on my instance, along with any associated packages.
• This code adheres to ProcessMaker Coding Guidelines.
• This code includes a unit test or an E2E test that tests its functionality, or is covered by an existing test.
• This solution fixes the bug reported in the original ticket.
• This solution does not alter the expected output of a component in a way that would break existing Processes.
• This solution does not implement any breaking changes that would invalidate documentation or cause existing Processes to fail.
• This solution has been tested with enterprise packages that rely on its functionality and does not introduce bugs in those packages.
• This code does not duplicate functionality that already exists in the framework or in ProcessMaker.
• This ticket conforms to the PRD associated with this part of ProcessMaker.

[processmaker-sonarqube]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube

[Kookster310]

QA server K8S was successfully deployed https://ci-a7410d005f.engk8s.processmaker.net

[Kookster310]

QA server K8S was successfully deployed https://ci-a7410d005f.engk8s.processmaker.net

[Kookster310]

QA server K8S was successfully deployed https://ci-a7410d005f.engk8s.processmaker.net