Problem/Motivation

If you allow anonymous users to create content on your site, you may want to allow them to edit their own content as well. Because there is a permission for doing so, "Edit own [content-type]", that you can click to give to the Anonymous role, you would assume that if you set that permission that the logic of that would work as expected: An individual anonymous user can edit their own node, presumably based on session.

You would probably not expect that Drupal considers all anonymous users to be a single user 0 and made no provisions for this setting so that by granting this permission you are allowing all anonymous users to edit each other's content (woops).

I propose there is a bug here in that the permission does not do what it says it will do.

Steps to reproduce

Proposed resolution

Add descriptions to the edit and delete own content for anonymous

Note that anonymous users with this permission are able to edit any content created by any anonymous user.
Note that anonymous users with this permission are able to delete any content created by any anonymous user.

Remaining tasks

Reroll patch
Review
Commit

User interface changes

Yes, additional text on permission page

TBA - add before and after screenshots

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

Comments

mdupont’s picture

Indeed. There is no way to uniquely differentiate anonymous users (they are, well, anonymous) and Drupal tries not to create sessions for anonymous users. Users not familiar with Drupal will likely be confused and it can lead to a security risk. At least the checkbox could be disabled for anonymous user.

droplet’s picture

Category: bug » task
Issue tags: +Needs usability review

"presumably based on session"

no, Im not.

mdupont’s picture

Category: task » bug

I think this is a bug report rather than a task. While it may seem logical to an experienced Drupal user that anonymous users can't be distinguished from each other, it may not be obvious to newcomers and might lead to errors or even security issues.

To prevent that, at least a warning should figure on the permissions page about "own" permissions. Something like this in the header : "Warning: permissions applying to distinct users, such as Edit own content, should be carefully granted to the Anonymous user role. Anonymous users can't be distinguished from each other, therefore with such a permission any user which is not logged in will be able to act on content published by any other anonymous user".

bryancasler’s picture

I had a similar problem where a user could remove them self as the author, this was problematic because unknown to them this was associating the content with user 0 (ie the anonymous user). That then opened up a world of problems.

Bojhan’s picture

Issue tags: -Needs usability review

Doesn't need review

jody lynn’s picture

I think we need to remove or disable the 'edit own x' permission checkboxes for anonymous users. Adding warning text around it just makes the page more wordy and may be ignored.

Everett Zufelt’s picture

Agreed that this could be confusing for some users, but there is a potential use-case (anonymous wiki, etc.). Can we just slap the standard "Security implication" warning on this and call it fixed?

jody lynn’s picture

So, the use-case is that you want anonymous users to be able to edit nodes created by other anonymous users but not created by authenticated users? I guess that can happen.

I think a security warning would be fine. Much less crazy than trying to remove or disable one checkbox on the page. (Reversed position :) )

jody lynn’s picture

Status: Active » Needs review
StatusFileSize
new1.03 KB

I added a description to the 'edit own' and 'delete own' permissions. I felt that adding 'restrict access' would be confusing as in general these are not permissions with security implications.

Everett Zufelt’s picture

#9: 1198120.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, 1198120.patch, failed testing.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

Issue summary: View changes
Issue tags: +Bug Smash Initiative, +Needs reroll

Triaged during a BugSmash group triage meeting.

Mile23 noted that this issue is old enough to drive :-)
larowlan said that "the patch needs to propagate those changes to the node permissions class. But I think the solution is the best we can do."

edit: adding quotes

ravi.shankar’s picture

Status: Needs work » Needs review
Issue tags: -Needs reroll
StatusFileSize
new1.08 KB
new2.28 KB

Added reroll of patch #9 on Drupal 9.4.x. and removed needs reroll tag.

borisson_’s picture

Status: Needs review » Reviewed & tested by the community

This change looks great, this is only adding a new string so no changes to any translations and since we are only adding a description I'm sure we don't need to add tests for this either. LGTM.

  • catch committed a463605 on 10.0.x
    Issue #1198120 by ravi.shankar, Jody Lynn, mdupont, Everett Zufelt,...
  • catch committed 82cf652 on 10.1.x
    Issue #1198120 by ravi.shankar, Jody Lynn, mdupont, Everett Zufelt,...
  • catch committed c085304 on 9.5.x
    Issue #1198120 by ravi.shankar, Jody Lynn, mdupont, Everett Zufelt,...
catch’s picture

Version: 9.4.x-dev » 9.5.x-dev
Status: Reviewed & tested by the community » Fixed

Agreed this is a good change, the 'anonymous user' concept doesn't exist everywhere so making it explicit with some help text, in the context of where it could cause a problem, is a good plan.

Committed/pushed to 10.1.x and cherry-picked back through to 9.5.x, thanks!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.