New security feature? allowing logins only from specific URLs

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

You don't want your editors to log into the https://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.

The two branches I put this code in are at:

An empty page is rather unhelpful, isn't it?

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.

2 Likes

"Nothing to see here; move along"

"Government agents are heading to your location"

"Oh, you shouldna done that...!"

I like the idea, but could we have multiple URLS? Thinking about a multi-domain website or a shared hosting provider.

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?

So maybe this feature should use reverse logic: do not allow login from a specific URL (the public, heavily cached one).

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.

2 Likes

@tkimnguyen, forget my comment, I was thinking in the wrong direction :stuck_out_tongue:

Doing it on the web server is way better.

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."

By 'webfront' do you mean nginx or Apache?

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...

Do you agree with Joni, that this shouldn't be in Plone code?

Agree - thx

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.

We also have in CastleCMS the ability to restrict login based on country: https://github.com/castlecms/castle.cms/blob/master/castle/cms/browser/controlpanel/security.py#L12

Plone Foundation Code of Conduct