Session authentication getting Access Denied when calling node.save after 2.2-to-2.3 upgrade

Subscribing

If you look at the CVS commit messages

http://drupal.org/project/cvs/109640

Then you may be able to start tracing your problem back to one of those commits. I think this is the easiest way to see what has changed recently. I will try and test this sometime soon, but I'm still trying to get settled in after my overseas move so perhaps marcingy or kylebrowning can find the time.

Subscribing

Does the large number of subscribers in a short period of time mean others are having this problem?

Yes, I'm developing a service module based on services. I'm using PHPXMLRPC for the client to test the service, yesterday it worked fine, but today after the update I got 'access denied'. Here is my code in the client side:

...
$auth_session_id = new xmlrpcval($auth_session_id, 'string');
$m = new xmlrpcmsg('mymodule.mymethod', array($auth_session_id));
$c = new xmlrpc_client('/services/xmlrpc', 'myhost', 80);
$result = $c->send($m);
...

And this is the code in the server side:

function mymethod() {
global $user;

module_load_include('inc', 'views_service');
$result = views_service_get('view_name', 'default', array($user->uid));
return $result;
}

Before the update $user in mymethod was the $auth_session_id user, but today is anonymous user, so I've got 'access denied'.

P.D: Sorry for my bad english.

I can confirm this problem when using the deployment module.
node.save and system.cacheClearAll give an access denied error.
system.connect and user.login however do work.

The bug is due the incorrect handling of sessions when using xmlrpc client (the session is never set and due to the update of line 866 in services.module this problem has surfaced)

A quick solution is to comment out line 872 in service.module

  //session_save_session(FALSE);

I also have this problem after upgrading to 6.x-2.3: "Access denied" when trying to call methods that were working under 6.x-2.2.

zeger can you elaborate? im not sure i understand what you're getting at. I recommend that people DO NOT comment out line 872. There are very good security reasons that line exists.

I'm in the same boat as the OP, but the method that is failing for me is views.get. Permissions and everything worked fine until the 6.x-2.3 upgrade. Now I get the "access denied" error unless I change the view's permissions and grant access to the view to "anonymous user." [Using REST server].

OK i think ive figured this out.
The issue was in node_service module.
Let me know if it works

It would help if everyone gave a list of what methods are working in 2.2 and which ones are not working in 2.3.
Ive tested all of the endpoints with anonymous and logged in user with permmission for certain endpoints

Access denied errors are there when that user(anonymous or not) does not have permission to execute that function. By allowing them permissions on the permission page I no longer see that error.

With the applied patch, everything seems to be working correctly.

@Edonnely I believe that is working as intended. If you told the view to have certain permissions to check against, its going to do that. You are saying it was working in 2.2 though, can you give me anymore informaiton?

I can confirm that the problem persists.

I'm using node.save that worked in 6.x-2.2 and now is giving access denied.

miraclegr, did you apply that patch?

Yes I did.

What I'm trying to do is create a new node of type x.
I've given permission to authenticated users to create node type x.

I am experiencing this problem with custom service methods defined via hook_service(). I suspect the problem is deeper than the node_service module.

I don't use session auth so none of the testing I did used it but I believe the problem is in around this area

// Check if it really loaded the user.
  if (isset($user->sid) && $user->sid != $sessid) {
    services_session_unload($backup);
    return NULL;
  }

And was added by http://drupal.org/node/931184 - I might be wrong but it is the only change that affects session handling.

I'm thinking it should infact be

// Check if it really loaded the user.
  if (!isset($user->sid) || $user->sid != $sessid) {
    services_session_unload($backup);
    return NULL;
  }

Just to report my testing with this - I am also seeing this problem after upgrading the services module. I am using a php script with curl to connect to Drupal Services. I am able to get a user with user.login but when I call node.get I see the access denied error now. I have tried both as user 1 and a user that should have access to the node. Inside the Drupal services interface I can supply an nid on the node.get form for the server I am using (json_server) at admin/build/services/browse/node.get and it does return the node. My php script worked until I upgraded the module.

I believe marcingy is right in #18, although I think it has to be

// Check if it really loaded the user.
  if (!isset($user->sid) || isset($user->sid) && $user->sid != $sessid) {
    services_session_unload($backup);
    return NULL;
  }

Otherwise you'll be back to getting the warning this code was changed to fix in the first place. Going to try and do some testing on this tonight.

OK here's a new patch. I tested the released 6.3 and got access denied, then with this patch everything worked. Please test and report back. If everything is good I will roll a new release.

Thanks all.

should it be

if (!isset($user->sid) || (isset($user->sid && $user->sid != $sessid)) {

While functinally the same I like the extra set of parens because it is more explicit and clear. New patch attached.

I also feel like my above patch in #12 still applies to fixing part of this issue, can we get both patches rolled into one?

Attached is 1 patch with both patches :P

I'd like to see one more of the people in this issue testing the patch then I think I'm ready to go.

Same as above patch just removes a stray space. As with Heyrocker this looks good to go once we have some more testing feedback.

Subscribing. I'm finding that session data is not getting saved to the sessions table upon user.login or user.get. The table always shows the user as being anonymous. I explained it a little more in detail here: http://drupal.org/node/988018

@Jay Matwichuk can you test the above patch as it should result in user.login recreating session table entries.

The patch in #28?

(thanks for the response by the way)

Yeah well actually the patch in #26 or #28 as they are the same except for an extra space character ;)

Subscribing

Patch in #28 fixed the problem for me. All my services seem to be working properly, although I do not use the Node Service module. Thanks for your efforts.

The patch in #28 has fixed my problem. My authenticated session data is now being saved to the sessions table in the database. I don't use the node_services though, so I cannot comment on whether that is working or not.

Patch in #28 fixes the problem here! Lets get a commit!

@kylebrowning (comment #13)

My site has no publicly-available information and only serves pages to authorized users. The views also have availability set only to authorized users. In 2.2, if a user was not logged in, the view would not be served by the REST server, while if he/she were logged in, it would be served. With 2.3, even logged-in users get the "Access Denied" error when calling views.get.

EDIT: I applied the patch, though, and it is working! Much thanks!

Have you tried the patch in #28? or just the one in #13?

You're right, I had only tried the patch with half the fix. Thanks! Working now, I edited the above to avoid future confusion.

I think this is RTBC, soo Ill mark it as such.

OK this issue has been fixed and a new release has been done. Upgrade to 2.3 for the fix for this issue. Thanks all.

He meant 2.4, marking this as fixed