Doubt on "container_permissions_check" plugin hook

Here is the scenario,

  • User A created a parent entity (PE).
  • User B wants to create a child entity (CE) with container_guid as PE.
  • As expected, the CE is not getting saved since User B has no write access to PE
  • So I used the following container_permission_check

in my start.php

elgg_register_plugin_hook_handler('container_permissions_check', 'object', 'mysubtype_cpc');
function mysubtype_cpc($hook, $entity_type, $return, $params) {
$input = (int) get_input('mysubtypePermission');
if ($input == '1') {
return true;
}
return $return;
}

in my action file

set_input('mysubtypePermission', 1);
$entity = new ElggObject;
$entity->subtype = "mysubtype";
$entity->title = $title;
$entity->owner_guid = $user_guid;
$entity->container_guid = $parent->container_guid; // Not owned by the current user
$entity->access_id = $parent->access_id;
echo $entity->save();
set_input('mysubtypePermission', 0);

But now also its not creating the CE as expected. Whats wrong with it?

  • Your code is extremally unsafe! Anyone anywhere will be able to inject 'mysubtypePermission' parameter to override container access! You should check for exact use case you want to handle inside handler function and not use global state overrides like that.

    Are you running this action as logged in user?

  • @Pawel : I know that its unsafe to rely on inputs and users can bypass it by passing the mysubtypePermission as a parameter in url. But this is somthing I quickly wrapped to test the plugin hook.

    Yes, the User B is trying to create the CE after logging in.

  • I have no immediate idea what's wrong. I would try using var_dump and die to see if you enter your hook and return true as intended (registration looks fine) and if you do, that might mean there's some other handler that blocks you anyway, or you have completely different reason of not creating new entity.

  • when I am using print_r($params) with in mysubtype_cpc(); it is outputting the ElggUserObject (user B) twice. I think, one of them should be the container entity. right?

    Also forgot to mention that I am on 1.9

  • Update : Both $params['container'] and $params['user'] is the same ElggUser Object

  • Is it a bug on 1.9? because I cant see any buttons to create a subpage when I am in the pages plugin section too.

    • Create a top level page (TP) as user A. Read access and Write access = both are public.
    • Login as User B and go to TP. No button exists to create a subpage even though the write access is public. I can edit the page, but I cant add a subpage.
  • Anybody have an idea?

    @iionly : how you are managing this in your tidypics plugin?

  • You're setting the container_guid to be the $parent->container_guid

    It's likely that you want it to be the $parent->guid

    Chances are the $parent->container_guid is the $user->guid which you are seeing in your hook

  • I don't think the sub-page creation restrictions are a bug. It's simply the way it's currently implemented by checking write permissions on the container_guid of a page. For normal pages (and in case of normal albums in Tidypics) the container_guid is the user_guid of the user who created the page (or album). For group pages (group albums in Tidypics) the container_guid is the group's guid. So, group members have permission to create a subpage (add images to a group album).

    Within the expirationdate plugin and the userpoints plugin I use elgg_set_ignore_access() to give write permission to other users' entities within well-defined borders instead of using the permission hook (which was used in former version of these plugins for previous versions of Elgg).

Beginning Developers

Beginning Developers

This space is for newcomers, who wish to build a new plugin or to customize an existing one to their liking