Closed (fixed)
Project:
Protected Node
Version:
6.x-1.5
Component:
Code
Priority:
Major
Category:
Bug report
Assigned:
Reporter:
Created:
5 Aug 2010 at 22:06 UTC
Updated:
1 May 2011 at 01:41 UTC
Summary: Editing of protected nodes is not protected
Steps to reproduce:
1.) Create a protected node
2.) With user who has "edit" permissions for the content type of the protected node, go directly to the edit URL of the protected node (http://host.domain/node/#/edit)
Expected Behavior: User should be presented with a password dialog to access the edit page for the protected node
Actual Behavior: User is able to edit the node without entering the node password
While the description for the node specifically says "view the node or download an attachment", it seems reasonable to expect that editing a node should be protected if viewing is protected.
Comments
Comment #1
MrVictor commentedActually I'm searching for the opposite functionality. No password for viewing but a password for editing! Is there such a module? This module could probably easily be converted into one...?
Comment #2
Marc Bijl commented@MrVicto: this one (content access module) might solve your problem: http://drupal.org/project/content_access
Comment #3
AlexisWilke commentedGarret Huntress,
I do agree that if you cannot view without the password, then you should not be allowed to edit. However, if you have edit rights, shouldn't you have view rights?
Frankly, the password seems rather weak since all the users will know the password (it's a unique password for a node, so many users/people may know it, right?)
Anyway, I guess both ways should be supported:
1) If you need the password to view a node, then you should be asked for the password no matter what access you are attempting (delete would certainly have the same issue, although you don't see the content other than the title in that case.)
2) If you have write access to the node, by-pass the password requirement altogether.
Does that make sense?
From what I can think of, (2) could make use of a new permission, if you are so authorized, then that it, you see/edit/delete; and if not fall back on the behavior defined in (1).
Thank you.
Alexis Wilke
--- edit 2011/04/15:
P.S. I'm about to change the drupal_goto() moving it from the hook_nodeapi() to the hook_init() function. The hook_nodeapi() call cannot be used for drupal_goto(), only to tweak the content of the node (i.e. body, teaser, title--although what about other fields such as CCK fields?! <- note to myself.)
Comment #4
AlexisWilke commentedOkay, as I said, my technique works just fine. node/#/edit and node/#/delete are now protected as expected. Actually, anything from any module will be protected in the same way. (node/#/clone from the clone module, node/#/edit/components from the webform module, etc.)
Thank you.
Alexis Wilke