Issue Summary

When using an incorrect fallback URL to bypass SAML, you are still passed to the login form.

This can be reproduced using a context path in the URL when no context path is set in the server.xml or by using a misspelled/wrong context path when one is set.

This is reproducible on Data Center: yes

Steps to Reproduce

1. Install Confluence 8.9.4 but configure it to have no context path in the server.xml:

   <Context path="" docBase="../confluence" reloadable="false" useHttpOnly="true">

1. Configure SAML, for example with Okta.
2. Enable the fallback method as described here.
3. Try the fallback URLs:

• https://confluencetest.com/contextPath/login.action?auth_fallback
• https://confluencetest.com/anytext/login.action?auth_fallback
• https://confluencetest.com/cjjj///////////////contextPath/login.action?auth_fallback
• https://confluencetest.com/contextPath/contextPath/login.action?auth_fallback

Note: These URLs do not work if the fallback method is not enabled.

Note: This behavior can also be reproduced when you do have a contextPath set in the server.xml. For example if you set /wiki as the contextPath, you can still get through to the login form by using /wiki/wiki in the fallback URL.

Expected Results

We should get a 404 and not be passed through to the login page.

Actual Results

Access logs show a 401, but we are still passed along to a slightly different login page (login form aligned to the left, missing the Confluence text in the header, no footer message, no gray background behind the login form.) The login form still works.

Tested with Confluence 8.9.4 and the SSO app version 4.3.10 and 4.3.11

Workaround

This behavior no longer occurs in 9.0.2.