I'm dealing with a site where certain node type remain unpublished but editors are allowed to edit (but not view) these posts.

However Entity Reference balks at these users, throwing an error in a popup dialog with the core bit of text "You are not authorized to access this page."

I modified Entity Reference to allow return of the results list if the user has update privileges also (presently it's just view).

In function entityreference_autocomplete_callback_get_matches

    if (!$entity || ( (!entity_access('view', $entity_type, $entity)) && (!entity_access('update', $entity_type, $entity)) ) ) {

This would seem to not pose a security risk as being able to edit a node is generally higher than viewing.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Ken Hawkins’s picture

Status: Active » Needs review
FileSize
610 bytes

Here's a patch.

praandy’s picture

Hi,
my editors has privileges on a content type via OG.
And with
if (!$entity || (!entity_access('view', $entity_type, $entity) ) {
and with the patch
if (!$entity || ( (!entity_access('view', $entity_type, $entity)) && (!entity_access('update', $entity_type, $entity)) ) ) {

they receive "Access denied".

I let only:
if (!$entity) {

and it works.

lathan’s picture

+1 this solved the issue of "access denied" ajax error messages for me.

in my case I'm using eck content type with a reference down to users.

Jimbo Slice’s picture

#2 worked for me. It fixed the error I was getting: "An AJAX HTTP error occurred. HTTP Result Code: 403". I was getting this popup on EDIT only on entity reference fields for all users besides user1. Thanks praandy!

DuaelFr’s picture

Title: Access denied: Entity Reference should also allow on node edit permission » Access denied: misuage of entity_access for entities without access callback (non core property)
Priority: Normal » Major
FileSize
1.39 KB

Reading entity_access comments, this function can return TRUE, FALSE... or NULL if no access callback has been defined on the entity. This property is not described in the core hook_entity_info so a lot of entities may not define it (including core ones).

The attached patch fixes the two entity_access calls made by entityreference.

This patch is part of the #1day1patch initiative.

Status: Needs review » Needs work
DuaelFr’s picture

Rerolled

afox’s picture

Title: Access denied: misuage of entity_access for entities without access callback (non core property) » Access denied: Entity Reference should also allow on node edit permission
FileSize
1.99 KB

@DuaelFr, your patch doesn't take into account the original post comment. Users might have the ability to edit the content, but not view it. Your patch does fix another issue in the same line of code, but doesn't answer the original issue. Since your solution is related to a different issue, let's not change the subject of the post. However, I did include your fix in this patch too.

DuaelFr’s picture

I misunderstood the original issue sorry.
Thank you for including my fix :)

+1 RTBC for you !

Damien Tournoud’s picture

Status: Needs review » Reviewed & tested by the community

Sounds reasonable to me.

t_en’s picture

Patch in #8 works fine.
It seems to me that the problem is more general than what the issue summary implies. In my case, I got the 403 error message when accessing any field on an image with an entity reference, connected to a view used for autocompletion. Also with user 1.

Anonymous’s picture

Would be nice to get this pushed at least to dev. Works for me as well.

tigertrussell’s picture

I'm getting this error trying to integrate the Goals Module with some Entity Reference stuff. I'd really, really prefer to not have to use checkboxes, and instead to use the sleek Autocomplete Widget.

But I don't think this patch is going to fix anything for me... I debugged this step-by-step, and it appears that the Goal entity does not have an 'access_callback' defined, so this particular call to entity_access will always return false for me on an edit.

It works PERFECTLY when I'm creating new content, but won't let me modify content.

Is the only way around this to define an access callback for the Goal entity? It seems like maybe the default behavior shouldn't be to deny a request, if there's no access callback defined. I feel like many developers would expect for the behavior to default to user_access, like the menu router does. I don't understand enough about how Drupal treats its permissions to know if this is even a viable option, but I'm just spitballing here.

Anyway, I'm interested in more thoughts. Until then I guess I'll modify the Goal entity to have an access callback so that Administrators, at least, can edit a Goal.

DuaelFr’s picture

You should probably ask the Goals module to put this "access callback" key in their entity definition or you could try to convince Entity API to consider no access callback as an allowed access.

If your entity have no access callback, entity_access() will return NULL, not FALSE. That's why we changed our conditions here to replace !entity_access(...) by entity_access() !== FALSE.

Damien Tournoud’s picture

Status: Reviewed & tested by the community » Fixed

Merged into 7.x-1.x.

Status: Fixed » Closed (fixed)

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

Dave Reid’s picture

Issue summary: View changes

I really wish this was an optional behavior. I don't like this change since when I view a node that might refer to unpublished, but future-scheduled nodes in an entity reference field, this means I can see them now and doesn't match the expectation of what a normal user would see.

AdamPS’s picture