Elgg is designing a permissions API loosely around the Activity Streams model. The user API could look (roughly) like:

function elgg_can($capability, $subject = null, $object = null, $target = null) { ... }
  • $capability is a string
  • $subject is a user object
  • $object is the object acted upon
  • $target is the context in which the action would take place

E.g. Can the current user edit the title of an object?

if (elgg_can('edit title', $currentUser, $someObject)) {

I'd like to know a good way to handle asking for permission to create objects. If the object doesn't yet exist, then the permissions system can't know anything about it, so there's a chicken-egg problem with a few obvious solutions:

  1. Allow passing in a string in place of $object (e.g. the TypeName).
  2. Put metadata about the object in the $capability. E.g. elgg_can("create PageObject", $currentUser, null, $group).
  3. Have the API user create the object then pass it into the API to decide if it should be allowed to continue existing.

Am I missing another obvious solution? Are there permissions models similar to this (that one could reasonably call successful) that handle this?

  • If you consider the objects class as a permissions target, you're good to go. Jul 15, 2013 at 20:54
  • @RobvanderVeer Why the target? See the new option #1 in the question.
    – Steve Clay
    Jul 15, 2013 at 21:06
  • i did not mean $target, just 'the thing that you'd like to secure'. Using a metaphor: not a key to a book, but a key for all books in this library. In your API that would be $object. To create a file, you need write access to the folder, as an example. Jul 15, 2013 at 21:51
  • I see. I guess I'm trying to allow the API to say, "You can create a text file in this folder, but not a directory".
    – Steve Clay
    Jul 15, 2013 at 22:46
  • 1
    in that case: creating a file should be a different permission from creating a folder. Jul 16, 2013 at 6:54

2 Answers 2


Are you sure that this is truly a permissions issue?

There are plenty of existing object-level security models, both role-based and policy-based, the most obvious example of which is the ACL. Each object may have its own permissions, which makes sense. But there is no permission for "create this object", there is only a permission for "create an object". There might be restrictions around the type of object a user can create, but that's usually about as far as it goes.

Of course, the actual operation of creating an object may fail for other reasons. For example, the object might be considered a duplicate, or might have some invalid data or violate some important rule (a tweet being too long, for example). Not being able to, let's say, add a photo to a photo album that you don't own, is more about validation of the request than permissions on the (nonexistent) object.

Of the options you propose, #2 is probably closest to modeling the actual permissions without also providing information it can't possibly know for sure at the time (i.e. whether or not creation of an object will succeed). There is no object when doing the permission check, so if a user can only create certain types of objects then there should be a different permission for each type.

You might also want to consider that an ultra-generic, one-size-fits-all function is often problematic for exactly this reason - there's always some scenarios that just don't fit, and if you try to make them fit, you end up with an ambiguous or hard-to-use specification. For example, shouldn't a user be able to ask the question, "What types of objects can I create in this location?" instead of having to figure it out one-by-one? I obviously don't know as much about the domain as you do, but just consider the possibility that you might be trying to fit 10 pounds into a 5-pound bag. If the API would be cleaner by having 2 or 3 or 10 functions instead of just 1, then expanding it might be the best answer.

  • Good points. The question doesn't always have to be "can I do this specific action?"
    – Steve Clay
    Sep 16, 2013 at 13:07

Use the Prototype pattern. In this pattern, you create a new object by cloning a prototype. Obviously that requires the prototype to exist. Not an unreasonable limitation usually, as no user can create random objects out of thin air. elgg_can("create BFG9000") is unlikely to work for you :P

Since the prototype must exist, it can have access rights.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.