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 placeE.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:Allow passing in a string in place of $object (e.g. the TypeName).Put metadata about the object in the $capability. E.g. elgg_can(create PageObject, $currentUser, null, $group).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?
In my permissions API, how do I handle objects that don't exist?
api;api design;permissions
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.