Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allowedRolesAndUsers: View or Access contents information? #3924

Open
erral opened this issue Mar 7, 2024 · 2 comments
Open

allowedRolesAndUsers: View or Access contents information? #3924

erral opened this issue Mar 7, 2024 · 2 comments

Comments

@erral
Copy link
Sponsor Member

erral commented Mar 7, 2024

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.

I also think that the PR was wrong.

@rber474

@rber474
Copy link
Member

rber474 commented Mar 7, 2024

As an expansion to what @erral pointed:

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.

@jensens
Copy link
Sponsor Member

jensens commented Jun 12, 2024

Good question!

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants