Moodle

Hello,

Any advance in this task ?

Are you planning to add authentication data at every call, thus modifying the parameters required by the WS calls, or having them in some session data, thus modifying every function implementation to check for these data ?

In any case, you would have to sent to WS login/password data in some sort of login/logout call .

How do you plan to support "ticket based authentication" such as CAS or Shiboleth ?

Since WS calls are going to be used by external developpers to sync their information systems with Moodle, you will have to provide them with an admin login/password access to be able to create/modify Moodle entities ; this could be a major security issue since they could use this access in standard Moodle interactive mode. One possible solution could be to have a "web service only" authentication plugin, maybe with IP addresses restriction ?

Cheers.

In my planification I expect to have a proposal and working code running by mid Jan 2009. Then we need to discuss this code with skodak and the rest.
We will consider what you suggest, but thiese issues should be addressed in another level.
Cheers

You must pay a particular attention to setting correctly the global variable $USER at every WS call.
I am having some reports of failure of my SOAP implementation against Moodle 1.9 due to the fact that many calls in datalib and accesslib now relies on $USER and superbly ignore an $userid parameter such as :

• get_my_courses
• has_capability
  ...

This was not a problem in "interactive mode" but is critical with WS when currently logged in user is quite often different of the user to which the WS call applies...

Cheers.

Assigning this to Jerome, though he will need some help with the new sessions that Petr's been working on.

A basic spec is currently here: http://docs.moodle.org/en/Development:Web_services#Authentication

This is a little different from the auth/webservices plugin we talked about yesterday, Petr, but after a bit of pushback from Eloy I think it's probably enough. Did we forget anything?

committing basic auth plugin, you can use ->user_login_webservice($username, $password) to authenticate from web service directly for now
later we need to add ip restrictions and maybe some wrapper function

hi Jerome,
1/ please do not use "moodle" in lang strings
2/ we are not usually putting underscores into string names

the rest looks fine

also the valid until can not be disabled in the new UI, right?

Thanks Petr

I think because the function description are a bit special: the string key should be equal to the function name.
It would be good that the guy translating do not do any error. Maybe seeing not common keys will make him think that these strings are special.
Otherwise if you really want I can remove underscores. Removing "moodle" from the key is wrong because it just makes a special case. I mean the string key are the function name. If the function name start with 'moodle' so the key should start with 'moodle'. Making a special case : 1. add more code 2. create confusion for a new ws developer: why did the function name lost the 'moodle' part?

Good catch for the Valid Until field. I though about that then forgot to implement.

right! sorry, I forgot about the function names here

oh,but then the name of the function or anything else defined in services.php must be stored in the language pack of the component, not some new file

oh, I just noticed you replaced the form for web service setting with custom html - this is a strict no, no, reverting; instead you have to create new formslib element for capability selection if needed, this change caused major regressions - the build-in services must not be modified!

also please use standard help icons in forms instead of long explanation texts - removing from lang pack too for now

I am going to reshuffle the files in admin directory a bit, I did not expect there will be so many of them needed,going to fix some incorrect hardcoded admin paths at the same time

Petr, I'm looking at the reverting 3 comments back. Fixing the regression that allowed editing of built-in services is fair enough, but was it really necessary to just suddenly remove all the code to create the capability selection? Since we don't just create new formslib elements every single time we have some special need, shouldn't we have a talk about if that element is useful beyond this one case and and how it should work?

aah, yes it was very necessary - the problem is we can not use tim's new output lib classes for making of real forms - it was clearly not designed for that.

and yes, the new capability selection element is the right direction.

fixing fatal installation error caused by the new mandatory timecreated field

I think we can close this issue as authentication has been defined, implemented and the specification are written.