The discussion revolves around the behavior of the SAML login in Discourse version 2.4.2. sbernhard misses the previous behavior where a landing page with a login button was displayed before the SAML login page. This is no longer possible in the current version, which displays the SAML login page immediately.
sbernhard shared a screenshot of the previous behavior and mentioned that enabling “local logins” brings back the landing page, but sbernhard does not want to have local login enabled.
Falco explained that the change was made to improve the SSO behavior, and david suggested a workaround by linking users to /login instead of the homepage.
sbernhard shared reasons for wanting the previous behavior, including displaying a nicer landing page and a minor security benefit. sam suggested that a plugin would be needed to change this behavior, but sbernhard is a developer and offered to submit a PR to add a configuration option.
david advised against adding more settings noise and instead suggested overriding the behavior in a plugin by patching a specific method. sbernhard thanked the team for their help and appreciated their work on Discourse.
On previous versions, a landing page was shown on which the “login” button appeared. Clicking this buttons showed the saml login page.
Personally, I really liked this behavior. With the current version 2.4.2 this isn’t possible any more as the saml login page is shown immediately.
Is it configurable?
I am not following, you mean we showed a modal that had a single button “Login with SAML” ?
Can someone help me? maybe @eviltrout ?
I certainly didn’t change this on purpose. If you could help us track down when it changed that would be helpful as we could look into the context.
It’s possible it changed for security reasons.
This was a long requested improvement to make omniauth behave like real SSO, when the number of omniauth login methods is only one.
How can I help?
one hint: if you enable “local login”, the “Landing page together with the login button” is shown.
If you really want the confirmation page, you can link the user to /login (rather than the homepage). That will not trigger the login automatically.
But note this is not really supported, it is just a quirk of the implementation and may change at any time.
New behavior is better and consistent with SSO login. If a message is needed before login it can be implemented in the Identity Provider.
ah, good to know.
I know of 2 reasons:
Is it possible to configure this behavior?
You are going to need to hire a dev here to build a plugin to change this. As it stands this is the first complaint I have heard about the new system in months.
I’m a dev 
(see my changes in discourse_saml)
Would you accept a PR which adds a configuration option (default: new behavior)?
The automatic redirect should not introduce any security vulnerabilities. If you are aware of an exploit, please let us know via our disclosure program: discourse/docs/SECURITY.md at main · discourse/discourse · GitHub
I don’t think we want to add more noise to the settings until we have some more users requesting this change.
You could override this in a plugin by patching this method:
So I think you would want to simplify the function right down to
def redirect_to_login
dont_cache_page
cookies[:destination_url] = destination_url
redirect_to path("/login")
end
Thank you. Very appreciated!
BTW: You are doing a great job with Discourse.