Login/logout fails with non-default language being active with the URL prefix negotiation

Just an attempt to summarize so far:
* so you suggest having multiple endpoints for the same SP, instead of having each language as separate SPs.
* pitbulk, in the github thread, suggests the opposite.

So far I can't work out a reason for preferring one over the other. But also... I can't work out a reason for having several URLs at all.

Here is my thought: your different-language websites don't care what "language" your SP is, do they? (All they do is direct you to the same URL at the IDP.) So your URLs should just always be www.example.com/saml/login, www.example.com/saml/acs, etc - regardless of language. And yes, after we get back, we may indeed need to do redirection to different pages... but I'm not sure that should be solved by having separate SP endpoints. Maybe we can take this up in #2670118: Make getPostLoginDestination / getPostLogoutDestination configurable - though I admit I don't know exactly how, yet.

If that's not true / you disagree: please enlighten me.

If that is true, then we need to see how to force those URLs, regardless of language. Unfortunately I still have quite little real world D8 experience, but reading UrlGenerator::generateFromRoute() leads me to believe we might be able to do something with 'path_processing' -- like adding the following to all /saml/ paths in samlauth.routing.yml:

  options:
    default_url_options:
      path_processing: FALSE

(Example found in system.routing.yml, for update.php.)

I should have said "I can't work out a reason for having several URLs paths". The multidomain case is still covered with the proposed solution.

I hope you can try out the 'path_processing' sometime because I don't have a multilingual site yet.

As far as the logout destination goes... you're right about this not being fair to site owners. My feeling says "have a plugin architecture, and include a plugin for common multilngual scenario". I hope I will have time to test that before DDD Seville, but that will be latest.

I'm wrong about the plugin architecture; that is overkill. I think a (relative) URL with token replacement is probably better suited for login/logout destinations - this can be discussed further in #2670118: Make getPostLoginDestination / getPostLogoutDestination configurable.

Until now I'm still fairly convinced that a single SP endpoint at the 'URL root' can be OK.

Following up on this because this is still an issue that multilingual sites are facing when using samlauth. I agree that it makes no sense to apply path processing to any of samlauth's /saml routing paths. Would be a pretty simple test, though admittedly I have no clue how to set this up locally to test with.

Uploaded patch applies to 2.0-alpha1, but not 2.x-dev. I can at least confirm that I'm able to login/logout when the default language has a URL prefix configured for it. Need others to review and verify though.

Thanks. Here's a patch that applies to 3.x-dev. (Verified that it makes sense to apply path processing to these routes.)

I haven't tested this myself yet though, so I might let this stew for a bit (until someone else tests too, and/or I have an idea about how I can arrange automated tests).

I can confirm that the 3.x patch fixes this issue on multilingual sites using non-blank prefixes on all languages.

The patch on #12 does not apply to the 2.x-dev version. Here there is a patch that applyes.

Thank you and sorry that it had to take so long before this was committed. This was the most significant outstanding issue in this module.