跨站点 URL 给出了奇怪的组合
我有两个由相同克隆设置提供服务的克隆站点，每个站点都由两个不同的域名访问，这些域名指向相同的 IP 地址。 apache 前端具有虚拟主机和 mod_proxy 设置，以将 URL 定位到适当的克隆站点。总之：
DNS:
mysite1.com -> my machine's IP address
mysite2.com -> ditto
Plone:
2 Plone sites: site1, site2
Apache:
2 virtual hosts defined:
ProxyPass / http://localhost:8080/VirtualHostBase/http/mysite1.com:80/site1/VirtualHostRoot/
ProxyPassReverse / http://localhost:8080/VirtualHostBase/http/mysite1.com:80/site1/VirtualHostRoot/
and
ProxyPass / http://localhost:8080/VirtualHostBase/http/mysite2.com:80/site2/VirtualHostRoot/
ProxyPassReverse / http://localhost:8080/VirtualHostBase/http/mysite2.com:80/site2/VirtualHostRoot/
这使得 URL mysite1.com 可以转到克隆“site1”，而 mysite2.com 可以转到克隆“site2”。
这一切都有效。
但是，如果在浏览器中访问：mysite1.com/site2，那么我会获取 site2 的内容以及每个站点的主题的一些元素。同样，如果我访问 mysite2.com/site1，那么我会得到两个网站的内容和主题的混合。
我知道这些 URL 在任何地方都不可见 - 只是我输入它们 - 我只是担心这种串扰确实发生，因此对于每个站点中的不同安全域有什么影响？
I have two plone sites being served up by the same plone setup, each accessed by two different domain names, which point to the same IP address. An apache front end has virtual hosts and mod_proxy set up to target the URLs to the appropiate plone sites. In summary:
DNS:
mysite1.com -> my machine's IP address
mysite2.com -> ditto
Plone:
2 Plone sites: site1, site2
Apache:
2 virtual hosts defined:
ProxyPass / http://localhost:8080/VirtualHostBase/http/mysite1.com:80/site1/VirtualHostRoot/
ProxyPassReverse / http://localhost:8080/VirtualHostBase/http/mysite1.com:80/site1/VirtualHostRoot/
and
ProxyPass / http://localhost:8080/VirtualHostBase/http/mysite2.com:80/site2/VirtualHostRoot/
ProxyPassReverse / http://localhost:8080/VirtualHostBase/http/mysite2.com:80/site2/VirtualHostRoot/
This allows the URL mysite1.com to go to plone "site1" and mysite2.com to go to plone "site2".
All this works.
However if in a browser I visit: mysite1.com/site2 then I get the contents of site2 with some elements of the theme from each site. Likewise if I visit mysite2.com/site1 then I get a mix up of content and themes from the two sites.
I know that these URLs are not visible anywhere - it's just me typing them in - I just worry that this cross-talk does happen, and therefore what implication are there for different security domains that I have in each site?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您所经历的称为收购；属性继承自对象的容器而不是其类层次结构。
您无需担心这会消除您站点的安全遏制。 site1 或 site2 中定义的用户不会获得访问所获取站点的额外权限，并且只能通过这种方式访问匿名（公共）信息和方法。
如果您使用在顶层定义的用户访问任一站点（因此根 Zope 对象包含这两个站点），那么您可以访问任一站点上的受保护信息，无论是否已获取。
串扰的唯一风险是，如果您的站点依赖于能够访问与其他站点对象具有相同 id 的外观方法或对象，并且该外观方法或对象已消失（例如，已删除）。然后，您的代码最终可能会访问所获取的站点对象，从而产生不可预测的结果，因为所获取的站点显然与您的代码所期望的不同。对于皮肤方法等，安全性不会允许您造成任何伤害。浏览器视图和其他 python 级代码当然最终可能会造成损害，但这应该是相当罕见的情况组合。如果您的网站没有可能与网站内容冲突的 ID，则无需担心这一点。
What you are experiencing is called Acquisition; attributes inherited from an object's containment rather than from it's class hierarchy.
You do not need to worry that this removes the security containment from your sites. Users defined in either site1 or site2 do not gain additional permissions to access the acquired site, and only anonymous (public) information and methods can be accessed this way.
If you access either site with a user defined at the top level (so the root Zope object containing the two sites), then you can access protected information on either site, acquired or not.
The only risk at cross-talk, is if your sites rely on being able to access a skin method or object with the same id as the other site object, and that skin method or object is gone (deleted, for example). Your code could then end up accessing the acquired site object instead, with unpredictable results as the acquired site is obviously not the same thing as your code would expect. For skin methods and such, security would not permit you from doing any harm. Browser views and other python-level code, could of course end up doing harm, but this should be quite a rare combination of circumstances. If your sites do not have ids likely to clash with your site contents there is no need to be concerned about this.
这就是收购的祝福/诅咒。 这里是一个解决方案。
That's the bless/curse of Acquisition. Here 's a solution.