node/add lists out all modules on the site that the user has permission to create. This list should additionally check that the node/add/$type menu path is accessible, otherwise, the page generates dead links to these inaccessible paths.

I've attached a patch that adds this check to the node_add function when no $type is specified.

CommentFileSizeAuthor
#1 node_add_menu_security_0.patch959 bytesjavanaut
node_add_menu_security.patch949 bytesjavanaut

Comments

javanaut’s picture

javanaut commented
StatusFileSize
new node_add_menu_security_0.patch959 bytes

I realized that some node modules don't define a menu path for node/add/$type, so this version of the patch accommodates such modules by allowing the link to be displayed if no such path is defined.

dries’s picture

dries commented

Won't commit. The menu system details should not be carried out to the node system. Marking this 'active'.

How can I reproduce this problem (preferably with HEAD)?

javanaut’s picture

javanaut commented

I can't seem to find the thread that it was discussed on, but I was trying to override what node_access('create',$type) returns on a dynamic, contextual basis. I believe it was Ber who suggested that menu paths were the way to go to override this, just override the node/add/$type path. The menu looks fine, but node/add still lists out these restricted links.

One way to exercise this bug would be to grant a user access to create blog nodes, then create a path pointing to node/add/blog that denies access to that path for the user, then go to node/add. You'll still see a link to add a blog node, but when you click on it, you'll get "access denied". The relativity.module makes use of this type of feature.

So, is this assumption correct that the menu access setting is the primary security specifier for this type of action, or should there be a way to dynamically override what node_access('create',$type) returns dynamically?

killes@www.drop.org’s picture

killes@www.drop.org commented

@Dries: Create yourself an account with "site administrator" permissions. Go to node/add. You'll see "Create story", but are not allowed to actually create one. i think that is actually a story module bug. Same applies for page module.

jonbob’s picture

jonbob commented

There is no way to override these menu paths at this time, though that is a valid feature request. I wouldn't classify it as a bug. When a module can provide a service, and the user has access to the service, the service is simply available. I think we need a different way to allow this kind of selective disabling of features, if we are going to.

As for killes' issue, that is actually different; the story module should be using node_access() rather than user_access() in its page hook.

javanaut’s picture

javanaut commented

"There is no way to override these menu paths at this time"

There is no absolute way to do so. It is currently overridden in module-name alphabetic order. A module named zzmodule.module would override the menu items defined in aamodule.module of the same path.

There has been at least one proposed solution (by me) for the menu prioritization here:
http://drupal.org/files/issues/menu_prioritize.patch as part of http://drupal.org/node/17386

I suppose this issue could use some thought and perhaps discussion on the topic. It seems like a bug to me, but I could see that if node module was never intended to know about menus, it wouldn't reference menu data when doing its business. The other argument is that the menu access value is the defacto security access specifier for a path and that all code should respect this when generating links (so that no dead links are displayed).

dopry’s picture

dopry commented
Status: Active » Fixed

This has been fixed in CVS.. Just tested with a user will all permissions, except create book page... I goto node add I see story, but no book page.

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)