In services_controller_execute() there is this code

  $original_user = $user;
  $old_state = drupal_save_session();
  drupal_save_session(FALSE);
  $user = drupal_anonymous_user();

which seems to negate the use of the login service since the access callback is now dealing with the anonymous user. This seem particulary progmatic if you define access arguments and let the callback default to user_access().

Can someone please explain the logic of forcing the anonymous user?

Thanks

Comments

voxpelli’s picture

voxpelli commented
Status: Active » Fixed

Due to some security vulnerabilities involving eg. CSRF-attacks against Services API:s we've changed Services to completely rely on authentication mechanisms to define what user a method should execute as - if no authentication mechanism alters the user then all Services calls are anonymous.

There's a new authentication mechanism that restores the old session based authentication. You should however be aware that certain combinations of request formats, session based authentication and resources will make your API vulnerable to CSRF-attacks.

sitiveni’s picture

sitiveni commented

Hi there, got a follow up question/remark to authentication in services_controller_execute(): what's the intention behind running this final bit of code in function services_controller_execute():

  if (session_save_session($user) === FALSE) {
    $user = $original_user;
    session_save_session($old_state);  
  }

Function session_save_session() (renamed to drupal_save_session()) expects parameter $status to be either TRUE or FALSE:

/**
 * Determine whether to save session data of the current request.
 *
 * This function allows the caller to temporarily disable writing of session data,
 * should the request end while performing potentially dangerous operations, such as
 * manipulating the global $user object.  See http://drupal.org/node/218104 for usage
 *
 * @param $status
 *   Disables writing of session data when FALSE, (re-)enables writing when TRUE.
 * @return
 *   FALSE if writing session data has been disabled. Otherwise, TRUE.
 */
function session_save_session($status = NULL) {
  static $save_session = TRUE;
  if (isset($status)) {
    $save_session = $status;
  }
  return ($save_session);
}

So when calling session_save_session() with the user object and verifying then on FALSE, the code in the condition will never get executed.
Isn't the idea to switch back to the original user after the execution process? So wouldn't it make sense to set the user back to the original user in any case (no condition, just execute the code)?

Not sure if I get the meaning of it; I'm open for explanation. Thanks

This affects version 6.x-3.0-rc2 (also dev); haven't checked D7.

voxpelli’s picture

voxpelli commented

I'm not sure how it works on D6 - the intention is to restore the old user unless the user has been logged in or logged out or something like that.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.