I've been playing around with a new security feature for Plone.
When you deploy Plone, you might want to have two separate URLs, one being a heavily cached public domain such as https://blabla.com, and one used internally by editors to maintain content such as https://internal.blabla.com
This new "editing URL" setting in the Security control panel lets you specify an optional editing URL. If it is set, and if someone tries to go to the /login_form from a non-matching URL, e.g. an editor mistakenly tries to login via https://blabla.com/login_form, they'll get a blank page.
At least a warning message explaining the situation would be better IMHO.
I can understand that due to security reasons you would not hive that much information, but at least pointing to the need to change the URL would be best I think.
I was thinking about that, because I could see wanting at least http://localhost:8080/Plone and one non-localhost URL
Can you give an example of needing more than one non-localhost enforced editing URL?
I suppose there's also the issue of maybe needing to ssh tunnel to work on a site, so if you've got ssh port forwarding localhost 8081 to remote host 8080, you'd need to allow http://localhost:8081... on the other hand, all those localhost URLs you would use to access and edit a site would not require use of the login_form, as you'd authenticate at the Zope level, right?
This should be done at the webfront level - not serving the site at all via non-whitelisted domains. Do not bring this logic to the application code, when avoidable. Amend hosting documentation instead.
The message should be what really happened: "You're using is an incorrect login url. Please check with your service provider the correct way of logging into the website."
For highly secured environments, the non-public URLs would simply not be accessible except via, say, VPN, or the internal client network.
For less secure environments, it's ok for the editing/management URL to be served.
As with many things, even though they are documented, if we can make it easy for users or administrators to do something, maybe we should. Relying on something being only in documentation is a good way to ensure that no one ever learns of it or uses it...
Somewhat related but I added a feature to https://github.com/collective/Products.LoginLockout which prevents logins except from a specifc IP range. So its based on source rather than destination domain like your feature. And it doesn't hide the the login form.
Just in case anyone is searching for this feature.
