User domains checking is broken

[georgpfolz]

I used to have a System-user for my Zope instances accessible only on Domain 'localhost'. This does not seem to work anymore (Zope 4.4, Python 3.8). But using 127.0.0.1 instead of localhost did the trick. Is this a deliberate change?

[dataflake]

Zope has nothing to do with how your browser resolves localhost and the normal Zope user folder has no notion of host names at all. I don't understand your question.

[georgpfolz]

It's not the User Folder, it's the "Domains" property of a user:

I don't think it's about how the server resolves this, as it's on the same server it previously worked with "localhost" as domain name.

It's not a big issue for me, it just took me some time figuring out why I had an "Unauthorized" error. It could be due to the change from Zope 4.2 to 4.4 or from Python 2 to 3.

A similar command as this one: curl http://system:systempassword@localhost/manage_delObjects?ids=delete_this (locally on the server of course) threw the "Unauthorized" error, and the problem was resolved as soon as I entered "127.0.0.1" instead of "localhost" in the user's form.

[dataflake]

I have moved the issue to the package that contains the code that does the checking against the "domains" attribute.

First of all, that code has seen no changes in 3 years, so there is no "deliberate change" involved at all. The change may have to do with your move from Python 2 to Python 3 and how that interacts with the machine network libraries to resolve names, Zope (and AccessControl) have nothing to do with that.

Secondly, after looking at the code that uses this domains value, the feature seems dubious at best. "localhost" doesn't mean the same in all cases, especially with IPv6 involved. From the look of it the code doesn't work with IPv6 at all.

For your particular case I suggest you change the domains attribute of the user to 127.0.0.1 and use 127.0.0.1 to access Zope, that way name resolution shouldn't get in the way and you are guaranteed to talk IPv4 only.

Other than that I would consider that feature broken for use cases that use host names instead of IP adresses (because those could resolve to IPv6) and use cases that involve IPv6 at all.

[georgpfolz]

Thank you for the clarification, I'll just use 127.0.0.1.

The feature itself is an important security feature for me, please do not remove it :)

[d-maurer]

Georg Pfolz wrote at 2020-5-10 06:09 -0700:

I used to have a System-user for my Zope instances accessible only on Domain 'localhost'. This does not seem to work anymore (Zope 4.4, Python 3.8). But using 127.0.0.1 instead of localhost did the trick. Is this a deliberate change?

I think this is a bug in "waitress" (the http server where Zope now typically runs in (instead of `ZServer`)). The domain checking code requires that the CGI variable `REMOTE_HOST` contains the host name with which the server was accessed (and `Remote_ADDR` the corresponding address). With the new (`waitress`) environment, both `REMOTE_HOST` and `REMOTE_ADDR` contain the same value: the address; the host name information is lost.

[georgpfolz]

I think this is a bug in "waitress" (the http server where Zope now typically
runs in (instead of ZServer)).

I could have guessed as the major change that came with switching to Python 3 was that I no longer could use ZServer. Thank you for the clarification.

[d-maurer]

Georg Pfolz wrote at 2020-5-10 06:09 -0700:

I used to have a System-user for my Zope instances accessible only on Domain 'localhost'. This does not seem to work anymore (Zope 4.4, Python 3.8). But using 127.0.0.1 instead of localhost did the trick. Is this a deliberate change?

I think this is a bug in "waitress" (the http server where Zope now typically runs in (instead of ZServer)).

The domain checking code requires that the CGI variable REMOTE_HOST contains the host
name with which the server was accessed (and Remote_ADDR the corresponding address). With the new (waitress) environment, both REMOTE_HOST and REMOTE_ADDR contain the same value: the address; the host name information is lost.

REMOTE_HOST is one of the so called "CGI variable"s. CGI is specified by RFC 3875 and REMOTE_HOST by "https://tools.ietf.org/html/rfc3875#section-4.1.9". Among others it says:

The server SHOULD set this variable. If the hostname is not
available for performance reasons or otherwise, the server MAY
substitute the REMOTE_ADDR value.

Apparently, waitress makes use of the last permission.
There might be a (waitress) configuration variable to change this.

Note, however, that domain restrictions (whether via address or name) are reliable only when you access Zope's web server directly. When you have a front end web server (as it is often the case in production environments), then REMOTE_HOST and REMOTE_ADDR contain information about this front end server, not the (real) client. In particular, that server will often run on the local host which can render "localhost" (or "127.0.0.1") domain limitations ineffective and therefore treacherous.

If you must rely on domain restrictions, I recommend to use features from ZPublisher.BeforeTraverse or a SiteAccess "access rule" to ensure that REMOTE_HOST and REMOTE_ADDR contain adequate values.

[georgpfolz]

Ok, good to know. I'm using this feature with IP-addresses anyway, except for 'localhost' until now :)

[d-maurer]

Georg Pfolz wrote at 2020-5-12 03:31 -0700:

Ok, good to know. I'm using this feature with IP-addresses anyway, except for 'localhost' until now :)

IP addresses are only reliable when you access Zope directly. The information which arrives at Zope identifies always the last HTTP agent. If you have a front end web server, then it identifies this web server (not the real client).