In the meantime: You can use a custom Route Part Handler to check for the (sub)domain but RoutePartHandlers will only be evaluated upon first hit(!) unless you disable the routing cache which is a bad idea mostly.
Another option could be a custom HTTP Component that detects the domain and sets some additional routing values either before or after the regular “routing” component. Let me know if you need further details on how to achieve this.
Is this package working (last commit was in 2013 for Flow 2.0) for the new Flow 3.0.x ?
I just recently tried that myself locally because we might use that packages ourself for a project. There are some small adjustments to make (policy configuration mainly), but it works. I might be able to prepare a PR for 3.0 compatibility over the weekend, but can’t promise it.
Is it possible, to have one single Flow Installation with a SSO.Server and SSO.Client but with multiple subdomains? So that users only must authenticate on one subdomain?
That’s exactly what SSO (Single Sign On) solves: you have a single server instance running on one domain (say auth.mydomain.com). Then for every other project, that want’s to use authentication, it makes use of SSO.Client package and configures it to authenticate against “auth.mydomain.com”. That way, you even stay logged in when switching from a.mydomain.com to b.mydomain.com and even to myotherdomain.org as long as they all are SSO.Clients that authenticate against auth.mydomain.com.
And yes, in theory they can even share the same flow installation, though that would require different sub-contexts for server and clients, as they need different authentication entry point configs.