Microflow URLs dont work with SSO forced redirect

0
So I'm finally getting off of Deeplinks and movnig to Microflow and page URL's. My company requires SSO so I have the SAML20 module installed and we immediately redirect people to it by setting the logni page to "index.html" and then the index.html is just a redirect to "/SSO". It works fine if you want to go to the home page.However When I try going to the Microflow URL it just goes to the home page (which I set as index3.html).My Microflow URL is.viewreport/{Request/Id}I guess mendix requires a "p/" in front so the actual URL iswhatever.com/p/viewreport/{Request/12345678I changed the SSO login page in my model options from "/SSO/" to "/SSO/login?cont=" This doesn't work. I still get to the home page. I try to navigate directly towhatever.com/SSO/login?cont=p/viewreport/12345678Nothing.. still... goes to the home page.Why is the SSO module ignoring everything after the "/SSO/" ?
asked
6 answers
1

Hi Brian Lorraine


The SAML20 module ignores your target URL because the cont= value isn’t passed in the exact format it requires. If the continue URL is invalid, not URL‑encoded, missing the leading /, or points to something Mendix can’t open, SAML falls back to the home page.


format should be:/SSO/login?cont=%2Fp%2Fviewreport%2F<GUID>


Notes:

  • Must include leading slash → /p/...
  • Must be URL‑encoded
  • Must use the object’s GUID, not its ID
  • If anything doesn’t resolve → Mendix loads the home page

That’s why everything after /SSO/ looked “ignored.”


I hope this helps, If you need future help I can assist.



answered
1

Hi,


This behavior is expected when using the SAML SSO module with forced redirect.

When you redirect everything to /SSO, the SAML module takes control of the authentication flow. After successful login, it redirects users to the default landing page, unless a properly encoded continuation URL is passed and handled correctly.

The reason your microflow URL is ignored is because:

  1. The SAML module only respects the cont parameter when it is properly URL-encoded.
  2. The continuation value must not include the /p/ prefix directly.
  3. If the continuation is invalid or not recognized, Mendix falls back to the home page.

Correct Approach

Instead of:


/SSO/login?cont=p/viewreport/12345678

You must URL-encode the continuation:


/SSO/login?cont=%2Fp%2Fviewreport%2F12345678

Additionally:

  • Ensure your microflow URL is correctly defined in Navigation → Microflow URLs.
  • Do not manually prepend /p/ if already configured.
  • Confirm that the microflow allows the user role after login.

Important Note

If forced redirect is implemented via index.html → /SSO, the original requested URL is lost unless explicitly preserved and encoded before redirecting.

A more robust solution is:

  • Let Mendix handle the redirect automatically.
  • Or implement a custom pre-login handler that stores the requested URL and restores it after authentication.

The SSO module is not ignoring the URL — it is defaulting to the home page because the continuation parameter is not correctly encoded or handled. Proper URL encoding of the cont parameter resolves this issue.


answered
0

I've tried a lot of things over the years, but never got the deeplinking to work in combination with SSO. Hopefully you will success Brian and let us know how you finally fixed it.

answered
0

Hi Brian,


Have you check the documentation?

For debugging purposes, you might also try to navigate to a page without any page parameters first, just to make eliminate other possibilities for failure (entity access, non-existing objects, etc.).

answered
-1

The issue is caused by the double leading slash in the continue URL (for example //p/viewreport/...). This results in the “Ambiguous URI empty segment” error, and Mendix falls back to the home page. That’s why it looks like everything after /SSO/ is being ignored.


The fix is simple: in the DeepLink module, set the constant EnableLeadingSlash to false.


This prevents Mendix from automatically adding an extra leading slash, so the continue URL will no longer contain // and SAML will process it correctly.


If this resolves the issue, please close the topic.


answered
-1

I was able to manage it like this:

  • In the Runtime tab of the App Settings, configure the page URL prefix to link instead of the default P to maintain compatibility with existing URLs
  • Add "login?cont=link/P14460107-001" after .../SSO/
answered