You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I want to raise again the discussion that happened in the closed #2723 PR regarding the use of Access contents information permission in the Catalog filtering instead of View.
In that discussion it was said that it is better to have a new issue and discuss it here instead of discussing there.
The whole point is that the catalog patch was modified in order to check for Access contents information permission instead of View when doing the catalog request.
It looks like the change was made in order to be able to query for metadata of content that the user is not allowed to View, contrary to the docstring of the said function itself.
A private website, where some contents can indeed be published for anonymous users, has defined a workflow in which, when in a published state, only authenticated users have access to the content.
In the published workflow state, it is defined that "Access contents information" and "View" are not associated with "Anonymous".
However, if the index "allowedRolesAndUsers" uses the permission "Access contents information", catalog searches will return results. For example, if there is a portlet displaying such content, the anonymous user shouldn't obtain it, but does.
Another example is navigation; if a user doesn't have access to a content, they shouldn't be able to see it in the menu.
Basically, actual behaviour acts as an unrestrictedSearch.
The initial idea (as far as I know) is, Access contents information allows to show the metadata from a catalog brain, but does not allow to get the object itself. View allows read-only access to the full object. At least this is what I learned 20+ years ago.
Unfortunately this is completely undocumented in CMFCore, where the permission Access contents information was introduced. And the usage of it in CMFCore is does not give any good hints about it's meaning and we may have used it totally wrong all the time.
So, before we change anything here we should define and document a policy about the usage of both permissions.
Given we use View in future, I would start dropping/deprecating the usage of Access Content Information everywhere and use exclusively View. This would simplify our security model a lot and reduces confusion and mistakes.
I want to raise again the discussion that happened in the closed #2723 PR regarding the use of
Access contents information
permission in the Catalog filtering instead ofView
.In that discussion it was said that it is better to have a new issue and discuss it here instead of discussing there.
The whole point is that the catalog patch was modified in order to check for
Access contents information
permission instead ofView
when doing the catalog request.It looks like the change was made in order to be able to query for metadata of content that the user is not allowed to View, contrary to the docstring of the said function itself.
I also think that the PR was wrong.
@rber474
The text was updated successfully, but these errors were encountered: