Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Comments
Comment #1
Ken Hawkins CreditAttribution: Ken Hawkins commentedHere's a patch.
Comment #2
praandy CreditAttribution: praandy commentedHi,
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.
Comment #3
lathan+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.
Comment #4
Jimbo Slice CreditAttribution: Jimbo Slice commented#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!
Comment #5
DuaelFrReading 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.
Comment #7
DuaelFrRerolled
Comment #8
afox CreditAttribution: afox commented@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.
Comment #9
DuaelFrI misunderstood the original issue sorry.
Thank you for including my fix :)
+1 RTBC for you !
Comment #10
Damien Tournoud CreditAttribution: Damien Tournoud commentedSounds reasonable to me.
Comment #11
t_en CreditAttribution: t_en commentedPatch 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.
Comment #12
Anonymous (not verified) CreditAttribution: Anonymous commentedWould be nice to get this pushed at least to dev. Works for me as well.
Comment #13
tigertrussell CreditAttribution: tigertrussell commentedI'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.
Comment #14
DuaelFrYou 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(...)
byentity_access() !== FALSE
.Comment #15
Damien Tournoud CreditAttribution: Damien Tournoud commentedMerged into 7.x-1.x.
Comment #17
Dave ReidI 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.
Comment #18
AdamPS CreditAttribution: AdamPS commentedThere is now a new issue #2292451: Make "update access implies view access" optional to make this behaviour optional.