$return = entity_access('update', 'file', $entity); does not return anything as entity of type file does not have an access callback defined, so attempting to PUT a file always returns access denied.
Fixed by always returning TRUE for entities of type file in _uuid_services_entity_access():
// File does not seem to have an access callback by default.
if($entity_type == 'file' && user_access('save file information')) {
return TRUE;
}| Comment | File | Size | Author |
|---|---|---|---|
| #15 | uuid-fix-make-local-1469716-14.patch | 555 bytes | carlhinton |
| #6 | 1469716-entity-access-6.patch | 859 bytes | aspilicious |
| #2 | 1469716-entity-access-3.patch | 1.06 KB | aspilicious |
Comments
Comment #1
aspilicious commentedHmmm: http://drupalcontrib.org/api/drupal/contributions!entity!entity.module/f...
I don't think hacking away file is a good generic plan. If it returns NULL it means there is no access information available so we just should return true. Entity module (or core or whatever module that is responsible) should add a callback for files.
Or am I missing something?
Comment #2
aspilicious commentedAnd a patch, that implements #1
Comment #4
aspilicious commentedThat test always fails... even without this patch.
Comment #5
recidive commented@aspilicious: we need to add a check to see if $return is !== FALSE, or we are just giving access to everyone for everything.
Something like that:
or check for === NULL
Comment #6
aspilicious commentedYou're totaly correct!
Comment #7
aspilicious commentedComment #9
aspilicious commentedStupid tests, nothing to do with this patch
Comment #10
dixon_Hmm, I have my doubts here.
What if a module implements an access callback, and the access callback might be constructed in a way that it only returns
TRUEwhen access is to be given and nothing (NULL) in all other cases.NULLin that case would mean access denied, but here we will let this through.Maybe we should do something similar to what
entity_accessis doing -- fetch the entity info, check if we have'access callback'. If we don't, always returnTRUE. But if we do have an access callback return what that callback is giving us.Comment #11
recidive commented@dixon_ in the long run your solution looks the more appropriate.
Comment #12
dixon_I rolled and committed a patch with my logic explained in #10. I also took the opportunity to wrap more code in the
try {}statement to catch potential errors in other parts of the access callback.http://drupalcode.org/project/uuid.git/commit/22c3ae3f24e19ad411f14cb08b...
Thanks
Comment #14
dillix commentedThere is a mistake in uuid_services.module:
Should be:
Comment #15
carlhinton commentedHere's a patch to implement #14
Comment #16
carlhinton commentedComment #17
dillix commented+1 for RTBC
Comment #19
dkingofpa commented@dillix, @CarlHinton Please don't re-open a Closed (fixed) issue. Instead, you can open a new issue with your patch. Setting metadata back to the closed values.