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

MrVictor’s picture

Actually 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...?

Marc Bijl’s picture

@MrVicto: this one (content access module) might solve your problem: http://drupal.org/project/content_access

AlexisWilke’s picture

Garret 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.)

AlexisWilke’s picture

Assigned: Unassigned » AlexisWilke
Status: Active » Fixed

Okay, 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

Status: Fixed » Closed (fixed)

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