-
Notifications
You must be signed in to change notification settings - Fork 332
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
Consider reworking default access rules for editing pages. #3014
Comments
I have tested and reproduced - you don't even need the Only having the Edit: have just tested with files, the problem is not present there. |
Tracing this through, I think the default permission set is to allow anyone you can log-in to the CMS to be able to edit pages on the site: So falling through the return static::getPermissionChecker()
->canEdit($this->ID, $member); which then eventually falls back to: SiteConfig::current_site_config()->canEditPages($member); which goes to Logged-In Users as the default type, set here: https://github.com/silverstripe/silverstripe-siteconfig/blob/5/code/SiteConfig.php#L49 class SiteConfig extends DataObject implements PermissionProvider, TemplateGlobalProvider
{
private static $db = [
"Title" => "Varchar(255)",
"Tagline" => "Varchar(255)",
"CanViewType" => "Enum('Anyone, LoggedInUsers, OnlyTheseUsers, OnlyTheseMembers', 'Anyone')",
"CanEditType" => "Enum('LoggedInUsers, OnlyTheseUsers, OnlyTheseMembers', 'LoggedInUsers')",
"CanCreateTopLevelType" => "Enum('LoggedInUsers, OnlyTheseUsers, OnlyTheseMembers', 'LoggedInUsers')",
]; So - this is working as intended, it seems - though the implication is that In my mind there are a few options here: a) change the default CanEditType to a group, set it to content-authors There are probably others, but that's just off the top of my head. In the meantime, the workaround is to change that top-level setting so that it's not inherited down. |
Thank you for the investigation @andrewandante! As you noted, this is working as currently intended - though it's not the first time someone has reported this, so it's clearly a source of confusion and perhaps it's time we think about changing how this works. @amolswnz If this wasn't working as intended, it would have been a security problem and should have been reported through the security process - please read that so you know what to do next time. |
For now I'm going to change the title of this so that anyone who stumbles across it doesn't freak out. |
I wonder if there's a way to rethink how permissions are represented on a page. Even with the "inherited from above" permission, it's not that obvious actually who has permissions on that page. Would be cool to see some sort of icon, or descriptive line, that tells the users exactly what the "computed" access is for the page. Something along the lines of:
I'm pretty sure that's hard to surface though 😅 |
SiteConfig "Who can edit pages on this site?" is a double up on permissions. If we select "Only these groups", it lists "Groups with global edit permissions" which is saying that all groups with "Edit" permissions can edit pages on site 🔁 |
Module version(s) affected
5.2.0
Description
Users with "View any page" can publish, unpublish, archive, edit any page.
How to reproduce
Possible Solution
This code seems to be the culprit in
SiteTree.php
Additional Context
No response
Validations
silverstripe/installer
(with any code examples you've provided)The text was updated successfully, but these errors were encountered: