Restricted access results with user entityreference

Same issue, using newsletter module, now all newsletters are named "Restricted access".
I reverted the update, because of this bug.

Here is the issue: SA-CONTRIB-2013-096 - Entity reference - Access bypass

Amitaibu fixed it. Maybe there is a better way to fix this?

I was just fixing another issue that I thought was related to this and noticed your bug. It ended up not being particularly relevant to me, but I was thinking about plausible solutions to your issue anyway.

It seems like "entity" module (probably not "entity reference", because "entity" is the one making this access call) maybe could implement a new permission like what you've discussed here, and then check both that and the "access user profiles" permission.

But I also feel a little bit like you've got kind of an edge-case scenario, no? Have you considered actually just giving the access, and then if you really need to, do a hook_menu_alter to change the access callback for "/user/%" to something custom?

The changes made don't reflect the function entity_access:

* @return boolean
* Whether access is allowed or not. If the entity type does not specify any
* access information, NULL is returned.

As such running a simple boolean check is probably not quite right (as null in this case would be captured as false). In the case where a custom entity is defined without any access methods, NULL would be what is returned - I've submitted a patch with a 1 line change ensuring the value is false and not null.

Oh, is this the same issue, then? It looked to be more complicated here.

I made another issue explicitly for that issue, with a patch, although mine is more verbose: #2180379: Entity reference "Restricted access" label where there should be none

I just thought I should chime in that after updating on Friday, I have now run into this issue on two different sites so far today. I am going to try giving access to profiles as a workaround but my users really should not have the ability to view each others profiles on these sites.

Do you know what, I managed to push that patch into the wrong issue (had 2 issues open, and was late-ish); that said still applicable in part. If there is a permissions issue with the user object this maybe best raised in entity api modules bug tracker (the module alters the access to the metadata in question), as it is advising you do (or don't) have permission to that specific metadata.

One option could further be to implement some configuration at field config level allowing for you to pick if the field should obey metadata security, although that seems like a bit of an odd thing to introduce.

I ran into this issue with a field to entity reference redirects.

Rolled against 7.x-1.1. After applying the patch, the jQuery autopopulate dropdown stopped displaying properly, though I could arrow key down and select an item, the item didn't save properly and the selected Redirect reference e.g. "(11)" wasn't there when opening the node to edit.

sujomuc, I'm not sure exactly what administrator page you are referring to, would you mind posting the relative path where you found this setting?

Same problem here for an entity that returns NULL on entity_access!
I'll lift this up as major because it's a problem for quite a lot of entities and does not correctly implement the entity_access return values, I think.

My concrete example is an entity from the data_entity.module!

Thanks sujomuc.

I realize now that I actually don't have any more -Restricted Access- results in my Entity Reference field, however I am simply not getting any results returned with labels. This is probably no longer related to this issue and is more of an issue to do with Entity Referencing Redirects. Screen shot attached, but I'll be searching for/making another issue to investigate this further.

Patch in #6 works for me.

Patch also works for me.

+1 commit

For #2, the issue was recently fixed in the Newsletter module 7.x-1.0-beta10 release.

Hmmm... I wonder if SA-CONTRIB-2013-096 - Entity reference - Access bypass might be too heavy handed an approach?

I have an entity reference field to a CiviCRM Contact type's display name; so it's a contact id number that results in that contacts display name. The problem with the existing security model is that in order for anyone beyond an administrative user to view that field, they must have administrative rights for CiviCRM which isn't what we want them to have.

Is there some method we can use to make the security more granular and adjustable?

How to just hide —Restricted access— options from dropdown? I am developing a module with custom entities. Am I doing something wrong or is it wrong behaviour of entityreference module?

I am building out a new D7 CMS. I came across this issue in a User-based Entity Reference autocomplete widget (user 1 shows up as 'Restricted access' in the widget.) I applied the patch from #6 to entityreference module, but user 1 still shows up as 'Restricted access' in the autocomplete widget.

Enabling (content creator) user's permission for 'View user profiles' works for me - I now see user 1's name in the ajax dropdown for the widget, but the patch seems to have no effect. While enabling user profile viewing for my content creator is not really an issue, I wonder if the patch has conditions.

Aside from applying the patch, is there anything else that needs to be done for this to work?

Thanks.

I stepped through PHP code, I discovered two issues.

Firstly, if my hook_entity_info() returns arrays without 'access callback', entity_access() doesn't call any access callback function, and returns void. This is despite the documentation stating that 'access callback' defaults to user_access().

Secondly, if my hook_entity_info() returns arrays with 'access callback' set to 'user_access', entity_access() passes $entity where user_access() is expecting $account (the second parameter).

My solution is to define my own access callback like this. It just calls user_access() but with the correct parameters.

function mymodule_entity_access($op, $entity = null, $account = null, $entity_type = '') {
    return user_access($op, $account);
}

and my hook_entity_info() looks like this:

function mymodule_entity_info() {
    return array(
        'my_entity'  => array(
            'label'            => t('My Entity'),
            'controller class' => 'MyEntityController',
            'base table'       => 'my_entity',
            'static cache'     => true,
            'fieldable'        => false,
            'entity keys'      => array(
                'id'    => 'meid',
                'label' => 'name',
            ),
            'access callback' => 'mymodule_entity_access',
        )
    );
}

I hope this helps someone overcome this issue.

Michael

I tried what @Freightdev suggested in #24, I even went as far as setting my custom access callback function to just
"return true;" and am still getting - Restricted Access - to my custom entity type.

Actually ignore my last comment. I just reviewed the code for my custom entity, and I wasn't providing and entity label callback. Adding the Access Callback fixed the issue and the entityrefernce fields are working for me, just without the lable callback they were only loading blank labels. Thanks @Freightdev

#24 worked for me too. Thanks

#24 worked for me too. I forgot too to implement label callback. With permissions and labels control, entity references run ok.

Re-rolled patch #6 to work with latest version.

This issue actually seems to affect entity references in general, not only to user entities. I use module countries which creates a country entity and my entity reference to those countries shows the same - Restricted Access - message. Should the title be changed to reflect this?

Given the broader scope of this I am surprised that not more people have tried to see this committed.

Patch #29 fixes my issue. Would really appreciate this to get committed. Thanks!

Patch #29 works for me too.

I encountered this problem using an entityreference field (7.x-1.5) to a user with the widget 'Draggable table'.

The patches in #6 and #29 did not solve the issue, but changing the widget to 'Autocomplete' did.

Hi @tvb AFAIK the Draggable table widget comes from the entity queue module and not entityreference, however it falls foul in the same way in terms of validating entity_access, perhaps might be worth creating a new issue (even referencing this issue from it).

I encountered the same problem. I have a custom content type 'Institution'. Users belong to an institution. Therefore, user profiles have an entity reference field to this content type. It is a required field, displayed with widget select list.
In the 'create account' page, the required field 'Institution' select list shows all options as 'Restricted Access'.
I assume because a new user who registers at that moment of course still is anonymous, and anonymous users don't have the 'view published content' permission on this site.

• I tried module 'Node view permissions' to specifically allow anonymous users view access to the content type 'Institution', with no success.
• I tried patch #29 with no success.*
• I tried changing wizard 'select list' to 'autocomplete' as stated in #33 but with no succes.

I ended up unchecking 'required' for the field to allow new users to create an account.
But I subscribe to #31 that this issue should get more attention to be addressed.

*(Btw, running the patch gave the following response in the terminal:
"patch unexpectedly ends in middle of line
Hunk #1 succeeded at 309 with fuzz 1."
But when viewing the code the patch seems to have worked fine. I also don't manage to see something wrong in the patch, but have only little experience yet with this.

hi

thanks for this patch .. #29 looks to be working for me too on entityreference dev version.

@tvb and @opgobee can you please try patching the dev version instead, clear all cache and test again ?

I think we need to think about this change and any unintended consequences that might arise. Because as it stands it will essentially treat NULL as an access granted. Versus now as it's defaulting to an access denied.

Is one assumption better than the other? Should it be instead that entities from other modules have access callbacks explicitly defined or not. The docs in the Entity API module don't make things any clearer either.

boolean Whether access is allowed or not. If the entity type does not specify any access information, NULL is returned.

People could interpret that either way as you'd need to explicitly allow or deny.

Or I'm overthinking this. Feedback would be great.