Webservices . AJAX / capabilities

Webservices . AJAX / capabilities

by Simon Vart -
Number of replies: 5

When you define a service and its functions in services.php, you could define capabilities in two separates places : 

- In the service itself, in a requiredcapability  key

- In each functions, in a capabilities key (which is a list of comma-sepearated capabilities)

But, by testing and reading the code, the second way (declaration by functions) have no effect. The capabilities are displayed in the frontend interface of the webservice, but there is no verification. You *have* to test the capabilities in your function's code.

The capability (a single one) declared at the service level is the only one actually checked. 

First question : is my understanding correct ?

So, it means that you define a capability toward a group of functions (meaning, the service). But you could not define different capabilities at each function level (say, you could have a capability to see a data, and another one to delete this data, with two functions in the same service) .

Second question : is that correct.

Third question : is this plan to change ? Because I don't see the point having to code the capabilities at two different places.

Average of ratings: -
In reply to Simon Vart

Re: Webservices . AJAX / capabilities

by Simon Vart -

As a complement and after some testing, the only place where the capability test is effective is in the function itself. 

When declaring a capability at the service level, for a course context capability (and after bumping up the plugin version, then  upgrading, then emptied the cache), the capability is not taken into account.

I would recommand to always and only implement capability test in the function code itself, and ignore the declarations.

Average of ratings: -
In reply to Simon Vart

Re: Webservices . AJAX / capabilities

by Davo Smith -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

As far as I am aware, the capability declaration there is for information purposes, rather than to act as a restriction in and of itself. It is there so that when a site admin is allocating a webservice to a user, they can double-check that the user has the correct capabilities to use that webservice.

That does assume, of course, that the webservice correctly declares all the required capabilities and that the admin does that checking ...

Average of ratings: -
In reply to Davo Smith

Re: Webservices . AJAX / capabilities

by Simon Vart -

Thanks for you reply. I came to that conclusion myself. My issue with that it uses code as a documentation. 

Average of ratings: -
In reply to Simon Vart

Re: Webservices . AJAX / capabilities

by Davo Smith -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

I'm now curious to understand what you would regard as a better alternative to writing code to display details about which capabilities are required for a given webservice?

After all, if you want to change the capabilities required, you need to change the code, so why not have the documentation there as well?

Average of ratings: -
In reply to Davo Smith

Re: Webservices . AJAX / capabilities

by Simon Vart -

Well, I would rather have a capability declaration in the service or the function (either is fine, as we coud have one capability to access the service itself, and one capability per function, as needed), and enforce this declaration by having Moodle core checking the declared capability in its code.


This way the code and the documention are the same thing.


The current way allows to have a undocumented tested capability in the function (the code, say in libexternal.php) and a different declaration at the webservice level. The reason is the needs evolve, and one could miss to update the part of the code which is in fact a documentation (the webservice declaration) after upgarded the code of the function (which will be probably tested upon a given user).



Average of ratings: -