Ticket #13793 (confirmed Bug)
Access to acquired content should not be allowed.
Reported by: | gotcha | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 5.0 |
Component: | Unknown | Version: | |
Keywords: | Cc: | esteele, davisagli, mj, matthewwilkes, eleddy, spereverde, mamico |
Description (last modified by gotcha) (diff)
Let's imagine the following initial content structure:
root \ - news - department \ news
A user stores root/department/news URL in a bookmark.
Another user deletes the news item under department.
Later, the first user uses his bookmark. With Plone 4.3.2, he gets a page back displaying the root news acquired content.
With no sign that the content item he was looking for has actually been deleted.
Further, if he is inattentive and by chance (?), he has permissions on this news item at the root, he may even delete or start to modify the wrong content item.
When browsing to this URL, the user should actually get a 404.
Change History
comment:3 Changed 2 years ago by gotcha
- Cc esteele, davisagli, mj, matthewwilkes added
Fix in https://github.com/plone/Products.CMFPlone/commit/e20ea907d2854ee7ad41e9953b64889ee7431b49 was reverted because it broke some tests and use cases.
I propose to improve the fix by allowing publication of content through "explicit acquisition": publication of content through acquisition would not be allowed (by raising NotFound) except if content item provides IPublishableThroughAcquisition.
This would imply fixing sites that currently rely on publication through implicit acquisition. IOW, it might require a PLIP in order to be introduced in Plone 5.
comment:4 Changed 2 years ago by gotcha
Fix was moved to https://github.com/plone/Products.CMFPlone/tree/publication-through-explicit-acquisition
Discussion on plone-dev : http://comments.gmane.org/gmane.comp.web.zope.plone.devel/33304
comment:6 Changed 2 years ago by spereverde
As I understand from reading this on the plone-dev mailinglist, there is already some consensus that this should be added to Plone 5. Godefroid already made some code changes as requested and is waiting for feedback on this.
Could somebody please review this ticket and accept it and add a version? We will need to fix this in our own setup somehow soon, but would at least like to have some idea if this will get accepted by the community or not...
comment:7 Changed 2 years ago by esteele
- Status changed from new to confirmed
- Version 4.3 deleted
- Milestone changed from 4.x to 5.0
I'd prefer to hold this until 5.0. I don't feel good about it going into 4.3.
comment:8 Changed 2 years ago by gotcha
5.0 is fine for me. What is the process to get it into 5.0 ?
comment:9 Changed 2 years ago by davisagli
In my opinion you could just go ahead and make the same change to the branches used by Plone 5, as long as you don't leave tests failing (so either fix tests, or remove them if they are no longer relevant).
comment:10 follow-up: ↓ 11 Changed 18 months ago by thet
Gotcha's "publication-through-explicit-acquisition" branch on CMFPlone ( https://github.com/plone/Products.CMFPlone/tree/publication-through-explicit-acquisition ) looks quite good to me. If there are no bad side-effects, we should include this in Plone 5.
I repackaged the branch into a seperate package for easier testing in real environments: https://github.com/collective/collective.explicitacquisition I'm currently testing it in a Plone 4.3 based site. I'm wondering, if there are no side effects on skin resource acquisition?
Note, there is also this attempt to solve the problem described here: https://github.com/collective/experimental.noacquisition I prefer gotcha's event subscriber method, but experimental.noacquisition mentions that it doesn't work, when there is another custom traversal adapter at the end of the request.
Another attempt to isolate ISite objects (but only them) from each other is: https://github.com/collective/collective.siteisolation
comment:11 in reply to: ↑ 10 Changed 15 months ago by mamico
Replying to thet:
Note, there is also this attempt to solve the problem described here: https://github.com/collective/experimental.noacquisition I prefer gotcha's event subscriber method, but experimental.noacquisition mentions that it doesn't work, when there is another custom traversal adapter at the end of the request.
Just my two cents.
I wrote experimental.noacquisition because I found some problems with the IPubAfterTraversal subscriber method, the cause in general is the complexity to check if there is an unwanted implicit acquisition at the end of the request using request's PARENT and context's physicalPath, checking during traverse is really very simplest.
Two examples of problems with IPubAfterTraversal's approach: traversal name adapter (see https://github.com/collective/experimental.noacquisition/blob/master/src/experimental/noacquisition/tests/test_bad_acquisition.py#L73), wrong context on errors (see https://github.com/collective/collective.explicitacquisition/issues/1).
I currently use experimental.noacquisition in production on many sites Plone 4.*.
comment:13 Changed 5 months ago by hvelarde
we've been bitten by this one recently on one of our biggest sites; IMO this is a nasty and dangerous bug and the priority should be raised.