Fix authentication error viewing ZMI with a user defined outside of zope root #1196
Conversation
perrinjerome
force-pushed
the
fix/zmi_sub_folder
branch
from
9eb54ae to
c8c52a1
Compare
|
Jérome Perrin wrote at 2024-2-16 22:23 -0800:
Your PR changes the URL the ZMI resources are accessed with
taking into account the authentication path.
While this solves the problem you have observed,
it seems suboptimal to me: quite complex and less HTTP cache efficient.
I would prefer a different approach: make the necessary resources
public.
@dataflake
I am aware that this goes against
"#1166 (comment)"
but is it really a security concern to have public access to the CSS and JS
resources of the ZMI?
|
|
Thank you
Yes, this is a bit complex. Frankly, I would also prefer to make the resources public, I don't see why they need to be protected. |
|
I absolutely don't like publishing a whole bunch of JS out of a basic Zope install that none of us can audit for issues. |
|
To expand on my earlier answer, I don't care about the CSS. I am concerned about the JS. If this was just a few script files we maintained ourselves that would be OK. But we have several megabytes of stuff in there, including the full Ace editor package, bootstrap, jquery and fontawesome. None of us has any idea what all that code does. Just publishing it freely for convenience seems a bad trade-off for me. Jerome's solution looks OK to me, it preserves the safety barrier. I don't think caching is really a valid concern. We're talking a ZMI, an application that requires authentication everywhere. It doesn't make much sense to try and cache things there. |
|
You probably understood that, but I want to clarify this about the caching concerns: My first naive idea was to make the resources relatives to the current folder. This would have fixed the original issue, but it would have been really bad for cache, because each folder visited in the ZMI would use different URLs for js and css. By making the resources relative to the authentication path like it's implemented here, each admin user always uses the same URLs for js and css, so they can be cached in the browser cache. |
|
I resolved a conflict, it would be good to decide something here. @dataflake approved a previous version of the changes. The argument that it's better to be safe and not publish javascript that we don't know sounds reasonable (at least the risk is limited to ZMI). @d-maurer you're also OK ? I don't really have another idea how to fix this. |
|
Jérome Perrin wrote at 2024-2-27 01:23 -0800:
I resolved a conflict, it would be good to decide something here. @dataflake approved a previous version of the changes. The argument that it's better to be safe and not publish javascript that we don't know sounds reasonable (at least the risk is limited to ZMI).
@d-maurer you're also OK ?
I am not convinced by @dataflake 's arguments but do not care
enough. Go ahead.
|
|
Thank both of you |
|
This fixes the problem for the normal case, so thanks. But this gives wrong urls when using virtual hosting. A Zope Manager gets this link in the head: A Plone manager gets this link in the head: I opened a new issue #1203 and show a partial fix so the urls are correct. But even with correct links, I get an Unauthorized when using virtual hosting, so the root cause is not really this PR. |
The previous approach from zopefoundation#1196 was not correct when using virtual host, because AUTHENTICATION_PATH is not usable in virtual host contexts. This uses a different approach, by making the js and css path subscribers take care of generating the URLs with the authentication path prepended using request API aware of virtual hosting.
The previous approach from #1196 was not correct when using virtual host, because AUTHENTICATION_PATH is not usable in virtual host contexts. This uses a different approach, by making the js and css path subscribers take care of generating the URLs with the authentication path prepended using request API aware of virtual hosting.
The previous approach from #1196 was not correct when using virtual host, because AUTHENTICATION_PATH is not usable in virtual host contexts. This uses a different approach, by making the js and css path subscribers take care of generating the URLs with the authentication path prepended using request API aware of virtual hosting.
…1204) * ZMI: re-implement the logic to prepend authentication path The previous approach from #1196 was not correct when using virtual host, because AUTHENTICATION_PATH is not usable in virtual host contexts. This uses a different approach, by making the js and css path subscribers take care of generating the URLs with the authentication path prepended using request API aware of virtual hosting. * ZMI: use /++resource++logo/ for public resources /++resource++zmi/logo/ and /++resource++logo/ is the same folder on disk, the former is protected by Manage portal and the later is public. Protected resources were problematic, because we want to serve them from the root, but the manager user might not have permission on the root. * ZMI: include zmi.localstorage.api.js using js subscriber Using this approach we serve a resource relative to the path where user is authenticated. * copyright.dtml: update bootstrap URL This was referencing an old URL. Co-authored-by: Maurits van Rees <[email protected]>
Fixes #1195