File entity values fail on deployment

Getting this example same error.

Anyone have any idea?

Dug deeper and I have attached screenshots. This only happens when trying to push a piece of content with a file field attached to it. Regular nodes with just title, body push and deploy 100% fine.

For some strange reason though when I push a piece of content with a file attached we get access denied in our json.

Screen 1:
This is a shot of Recent Logs on destination server after attempted a content push that has a file attached. You can see where the UUIDEntityException occurs as described above by kbasarab. We can see that a session is successfully opened for my admin user (super user account.)

If I go click on Calling server: rest_server_server we go to Screen 2.

Screen 2:
Click on location to examine the json we see the following on Screen 3.

Screen 3:
Access denied for user admin ?!

If I open any of the above calls in Screen 1 - E.g Passed Arguments: Array and click on the LOCATION to view the json it still says Access Denied. So this makes sense that it is posting the UUIDEntityException because it is being passed a json object which only contains ["Access denied for user admin"] and it is not finding the entity UUID.

What could be causing this? If I don't change any settings but push a piece of content with just title, body everything works flawlessly!

Thanks in advance!

More Updates:
It appears this is an issue with the current Services module. I am using the latest dev version of Services (2012 July 17th.)

If I go to the Services module folder and open the file services.runtime.inc and comment out the following lines (#144-148):

// Call default or custom access callback.
  if (call_user_func_array($controller['access callback'], $access_arguments) != TRUE) {
    return services_error(t('Access denied for user @user', array(
      '@user' => isset($user->name) ? $user->name : 'anonymous', 
    )), 401);
  }

then everything works flawlessly again and I see the image gets deployed from staging to production!

I took a look at what the $controller['access callback'] value is when trying to deploy a content type that includes file and it is calling _uuid_services_entity_access. This as far as I've gotten. Still investigating...

So I guess it's related to UUID module now? and perhaps directly related to this issue:

http://drupal.org/node/1469716

Appears that it is not resolved since the Services check is failing and returning false ?

I can't comment on the Rules issue as I'm not using the rules module yet, but scary to know there's more problems incoming there! :)

I've gotten around the problem by using a hack solution I described in #4 above: http://drupal.org/node/1469716

Basically inside /modules/uuid/uuid_services/uuid_services.module find the following function / code block:

function _uuid_services_entity_access($op, $args) {
  try {
    // Fetch the information we have to work with.
    $entity_type = $args[0];

...and directly below the above I have added:

if($entity_type == 'file') {
      return TRUE;
}

This is identical to the hack described in the issue posted at http://drupal.org/node/1469716 and it fixes the problem by forcing true return. It's horrible as a solution and I'll want to put together a proper patch as soon as I isolate the actual cause of the issue.

I'm still looking but have isolated it to this code block within the same _uuid_services_entity_access($op, $args) function above.
Basically the below code is within a try / catch code block and it is failing and throwing an exception, thereby forcing the errors. It is never reaching the bottom of the try block to return a value (...so far only seems to occur with file entities)

// Load functions always deal with multiple entities. So does this lookup
    // function. But in practice this will always only be one id.
    $entity_ids = entity_get_id_by_uuid($entity_type, array($args[1]));
    $entity = NULL;
    if (!empty($args[2])) {
      $entity = entity_create($entity_type, $args[2]);
      // We have to make the entity local (i.e. only have local references), for
      // access functions to work on it.
      entity_make_entity_local($entity_type, $entity);
    }
    // Fetch the local entity if we've got an id.
    elseif (!empty($entity_id)) {
      $entities = entity_load($entity_type, $entity_ids);
      $entity = reset($entities);
    }

Applying skal's fix (described in #6) on the endpoint works for me.
Thanks, skal.

Create patch described in #6

Had the exact same log entries and the patch worked.

The patch worked for me as well

I got below error after apply #9 patch

PDOException: SQLSTATE[HY000]: General error: 1366 Incorrect integer value: 'cecbfceb-81f0-74a4-a5b2-4953758432f5' for column 'fid' at row 1: INSERT INTO {file_usage} (fid, module, type, id, count) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4); Array ( [:db_insert_placeholder_0] => cecbfceb-81f0-74a4-a5b2-4953758432f5 [:db_insert_placeholder_1] => file [:db_insert_placeholder_2] => node [:db_insert_placeholder_3] => 1594 [:db_insert_placeholder_4] => 1 ) in file_usage_add() (Zeile 664 von //includes/file.inc).

This issue still seems to exist.

Reading the post here: http://drupal.org/node/1469716, suggests that the patch suggested in 6 opens up a security hole - unless I've misread/misunderstood.

Has anyone managed to get around this without hacking? Seems like a massive issue since deploying images isn't exactly an unlikely use case.

Happy to put some testing into this if someone has some time to think about how to resolve the issue.

Well, we met this error and this problem come from UUID conflict, so if in your source server generated UUID already, then you should not generate UUID again on destination server.

So this is my solution for this :

Source server : we generate UUID once time. Then get db dump, after that we create destination server with this DB dump.
So UUID will be sync between source server and destination server and you shouldn't get this error again.

Cheers

Related issue: #1820822: deploying content type with a filefield returns 404 Not found: Could not find the controller. . I'm also getting 404 controller not found, but details in the logs are different... it's a different issue, but might be related.

#1324970: Image fields don't work Patch at #24
#1390708: Fix crash with reference to missing entity

Access callback assigned for any entity is _uuid_services_entity_access which is calling a specific function for each type of entity:

if (($info = entity_get_info()) && isset($info[$entity_type]['access callback'])) {
      return $info[$entity_type]['access callback']($op, $entity, NULL, $entity_type);
    }

for files the callback is entity_metadata_file_access() function which gets $op parameter with value 'update'.

After a quick view over function code it seems that it will always return FALSE.

function entity_metadata_file_access($op, $file = NULL, $account = NULL, $entity_type) {
  // We can only check access for the current user, so return FALSE on other accounts.
  global $user;
  if ($op == 'view' && isset($file) && (!isset($account) || $user->uid == $account->uid)) {
    // Invoke hook_file_download() to obtain access information.
    foreach (module_implements('file_download') as $module) {
      $result = module_invoke($module, 'file_download', $file->uri);
      if ($result == -1) {
        return FALSE;
      }
    }
    return TRUE;
  }
  return FALSE;
}

A quick fix without altering the contrib modules would be to implement hook_services_resources_alter() in a custom module
and set:

function my_module_services_resources_alter() {
  $resources['file']['operations']['delete']['access callback'] = 'custom_access_file';
  $resources['file']['operations']['retrieve']['access callback'] = 'custom_access_file';
  $resources['file']['operations']['update']['access callback'] = 'custom_access_file';
}

and make that callback return TRUE or implement a better function.

function custom_access_file() {
  return TRUE;
}

after that you should re-save the endpoint on target server.

There is a bug in:

 elseif (!empty($entity_id)) {
      $entities = entity_load($entity_type, $entity_ids);
      $entity = reset($entities);
    }

Should be:

elseif (!empty($entity_ids)) {
      $entities = entity_load($entity_type, $entity_ids);
      $entity = reset($entities);
    }

And after that no patch needed!!!

Do you mean #6 not needed as well ?

Keith

I'm pretty sure #18 is a bug, but it's not the cause of the issue fixed by #6.

You either need the fix in #6, or do what is suggested in #17.

Neither of which get to the root of the issue. Would it perhaps be up to file entity to implement the access callback suggested in #17?

This is related: #1778484: UUID Services for file should not use the update method.

There seems to be an issue with the PUT http method used by deploy, and file entities and UUID.

By editing uuid.entity.inc with the following I was able to prevent this error

function entity_uuid_save($entity_type, $entity) {
  // This function, and this function only, depends on the entity module.
  if (!module_exists('entity')) {
    throw new UuidEntityException(t('Calling %function requires the Entity API module (!link).', array('%function' => __FUNCTION__, '!link' => 'http://drupal.org/project/entity')));
  }
  $info = entity_get_info($entity_type);
  $uuid_key = $info['entity keys']['uuid'];
  if (empty($entity->{$uuid_key}) || !uuid_is_valid($entity->{$uuid_key})) {
    watchdog('Entity UUID', 'Attempted to save an entity with an invalid UUID', array(), WATCHDOG_ERROR);
    return FALSE;
  }

  entity_make_entity_local($entity_type, $entity);

  // Save the entity.
  $result = entity_save($entity_type, $entity);

The code amounts to an early bail on saving an entity where it has no UUID or an invalid UUID.
Such problems are mostly caused by services or caching issues.

Patch for #22

Patch for #22

Third time lucky

The attached patch combines that found at http://drupal.org/node/1469716 with #25 above

#27 works, but is against the uuid project, maybe move it?

Updating patch to latest dev and also looks like 1469716 was committed already.

This bug appears because default file entity doesn't have 'creation callback' which needs for entity_create() function.
Installation of File Entity module (https://drupal.org/project/file_entity) solves this problem.

xopoc: does the installation of the file_entity module solve this problem with or without the patches in this thread?

In either case, the .info file needs to reflect the dependency on file_entity.

Committed. Thanks!