|
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 :
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. 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.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
Sub-task
Resolved
Major
 |
|
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.