Service method views.get returns access denied

Weird. It works fine for me. You have set up your services module permissions to allow anonymous access to services, haven't you?

... admin/user/permissions

I'm using Views 2 as well, but 6.x-2.x-rc1 ... updates to later release candidates caused handlers (amongst other things) to break because of the changes in API between rc1 and rc2, so you may be on to something there.

Ok, I can now second this!

We just upgraded for Views 6.x-2.1 - the problem is the views_access() function relied upon by views_service_get_access() (the access callback for views.get) has changed. You used to pass it a view object to check, but it now accepts no object - it assumes the view is already resident in memory somewhere. I'm still picking through how it works, with a view to supplying a patch.

Ah, brilliant! Thank you. I just posted a support request over in Views too. You couldn't rustle up a patch could you? If not, I'll work it out. =)

I'm not sure what you mean by "users $view->access() to validate" ...? My views (using Views 6.x-2.1) don't have this. The only place access appears is here:

view Object
(
    [display] => Array
        (
            [default] => views_display Object
                (
                    [display_options] => Array
                        (
                            [access] => Array
                                (
                                    [type] => none
                                    [role] => Array
                                        (
                                        )

                                    [perm] => 
                                )
                        )
                )
        )
)

Which would be $view->display['default']->display_options['access'] *and* is not a boolean so could not be used as an access callback...? :-/

Maybe there's been another change?

Me too!
http://views.doc.logrus.com/classview.html#996e7b183eb9d43ec9d535dbf897616a

This works: $view->access('default');

So I guess the service needs another optional parameter - 'display'. Or one can take the view that the default display will always be loaded?

Coincidentally, all of the below are valid:

// single display
$display = 'default';
$view->access($display);

// single display can also be expressed as an array
$display = array('default');
$view->access($display);

// multiple displays can be passed as an array
// if ANY of them return TRUE then access is granted
$displays = array(
    'default',
    'page',
    'block',
);
$view->access($displays);

And also, if you want to check the access to a display for a specific user, you could do something like this:

$display = 'default';
$thisuser = user_load($uid);
$view->access($displays, $thisuser);

Hmmm, I feel a blog post coming on! ;-)

Ok, patches attached! =)

In a nutshell:

1. New argument for views.get, display_id (terminology taken from Views to be consistent), accepting the display name to use.
2. views_service_get() function updated to accept $display_id and set the view object accordingly
3. views_service_get() documentation updated
4. views_service_get_access() function updated to use the correct access check and check access to the specific requested display_id ('default' if none specified)

They seem to work for me. Please review.

IMPORTANT: Kitten killing patch de-listed and will be re-posted elsewhere.

I always forget to change the status! =)

I tried that and it wasn't working, hence the lines you highlight. I think it's because of the API.

The problem is this, AFAIK:

When you make a method call over XMP-RPC you must provide an XML element for all arguments. I think this is exposes a small bug in the Services module. In effect, it forces you to send $default_id = '', which you would expect the Services module to ignore and use defaults instead. It does not - instead it passes the empty string on.

Consequently, normally you would be correct but in this case those lines *are* required, to substitute the empty string the Services module passes on from your method call with the string of 'default', and it won't work without them. It receives a string (albeit empty) from the Services module, thus ignores the default value you set and breaks. =(

Hmm, ok - so what is the point of the "Optional" parameter in the Services API for hook_service() then? Is this for other server types? From what you're saying NOTHING is optional with XML-RPC (which was my experience anyway - I guess this is by design...?)

Anyway, thanks - I'll update the patch. I don't have access to the code today, so I'll do it tomorrow. =)

Gotcha. Makes perfect sense! Thanks!

I think I need to update a few of my other services, now I properly understand what optional is for in the API and how it should be implemented. =)

Ok, new version of the .inc file patch attached. Please re-review, if you get a chance. =)

IMPORTANT: Kitten killing patch de-listed and will be re-posted elsewhere.

Here comes a patch fixing this issue.
I first tried out greg.harvey's patch - but I don't like that it breaks my current API-calls.

Adding display_id as a parameter to the view.get service is as far as I understand out of the scope of this issue.

My patch only fixes the access denied problem - if the display_id should be configurable another issue should be started for that I think.

This is a code issue btw.

Fair enough - I did a bit of kitten killing there. I'll create a feature request and post my patch there.

I haven't applied yours, but it's so simple it *looks* fine. Won't change the status though having not actually tried to apply it and use it - I'm using my patch now, because I need the extra functionality anyway. =)

Looking for the previously discussed patch? Go here: http://drupal.org/node/339754

OK I'm lost

What did you guys figure out?

I can't get this module to work

hey hey #25 has the answer

-  return views_access($view);
+  return $view->access('default');

This fixes it. Well done mate.

That was posted 3 months ago - and I still downloaded a broken copy of this module from the project home page...

There has been no release in almost 6 months, and the module does not work. Is this project abandoned?

Hmm no, it is called having day jobs ;) If you want to help review patches and help the project move along that would great.

If I understand danielb correctly in #29 the patch I posted in #25 works for him - therefor I'm marking this as reviewed and tested

I've a feeling this is actually superceded by other changes to the module already committed to HEAD, but I'm not sure without checking...

No this fixed in the current dev version for 6.x. I will attempt to get this patch up in the next few days.

Committed to D6 dev #171827

hi, I'm still having trouble with the services views.get. I am using services 6.x-2.x-dev. I have all permissions open. I tried the suggested patch but it failed. Can someone help me please?

hi, I'm still having trouble with the services views.get. I am using services 6.x-2.x-dev. I have all permissions open. I tried the suggested patch but it failed. Can someone help me please?

similar to post #37, I'm still having problems with Access Denied when using views.get via XMLRPC, both through the durpal service browser and through a php test client. I'm able to access both the node and file services via the test client but always get Access Denied when attempting a views.get. I'm running Views 6.x-2.11 and Services version 6.x-2.2. I've checked the view_services.inc and it has this function:

function views_service_get_access($view_name) {
  $view = views_get_view($view_name);
  if (empty($view)) {
    return FALSE;
  }
  return $view->access('default');
}

My view has Access: Unrestricted.
The Views Service is enabled.

When I go to UserManagement->Permissions, there is no option to set permission for views_service module but there are permissions for node_services, file_services, user_services etc. Should there be permissions for view_services and if so, how do I enable it.

Juice

After tracing through the code, I found that the _services_keyauth_authenticate_call in services/auth/services_keyauth.inc did a query to the db looking for a value in the services_key_permissions table. On my install, there was no value for the views.get method. I inserted a record into the db with the service key and method name:

INSERT INTO services_key_permissions (`kid`, `method`) VALUES ('yourkeyhere', 'views.get');

After doing this, I realized that there were options under the Administrator/SiteBuilding/Services/Key/Edit that displays which methods the key has permissions to perform. So make sure if your using key authentication to make sure your key has permissions for the services you want to use. Hope this helps someone else.

Juice

To whom it may concearn I still had problems with this patch, I had to fix it with the hook_perm because also when the view was not found the given error was 401 (access denied) instead of 404 (Not Found).

Post a new issue instead of bumping old fixed ones.

@kmox83: That bug has been fixed in http://drupal.org/project/services_views