Moodle 2.0 : some questions that need to be considered if we want to have web services available for client side Flash / Java / js etc

Moodle 2.0 : some questions that need to be considered if we want to have web services available for client side Flash / Java / js etc

由Jamie Pratt發表於
Number of replies: 18
Hi all,

Have been working on a test client in Flex 3 for the web services. Right now it seems that development of web services has mainly been concerned with the first of the two use cases below :

  • administrating your moodle web site using an external application of some type. Administering users, courses etc.
  • using web services for client side code embedded in a web page served to the user to communicate with the server.
Am not sure if it is envisaged that the new web services framework should be usable for the second use case. I would like to help make this possible.

I think that to enable developers to be able to build client side dynamic code that communicates through web services we need to do two things.


Enable authentication through passing a token into applet/object embedded in the web page

In the case that web services are used by an external application I understand it is planned that a username and password is entered into the external app and then sent by a web service to the server as a web service call, then an authentication token is sent back as the result from the web service call. The token is then passed along with all subsequent service calls to identify the user.

In the case that an applet or object is embedded into the page possibly the same token could be passed directly into the applet/object. This would mean including the token in the html that is used to embed the object would include appropriate tags to pass the token into the applet / object along with the url of the web services. We need a function to call in php that would return such a token so that developers can write php that embeds applets/object into the page. This token would be a randomly generated string of some sort, which is temporarily valid.

Associate a context with a authentication token

It would seem a good thing to associate a context with the authentication token. This would mean that we know all web service calls from for example client side code in an activity, block, etc is related to that activity/block. The token has been generated on the server side and when the web services related to the activity/block etc are called then we know that these calls are from this activity and web service calls cannot be spoofed to interfere with other activities.

External apps could allow the user to log in with appropriate user details to get access to the whole system.

Limiting the web services that can be called from within client side code embedded in an activity / block html - not essential but desirable??

It would seem that if code is called from within an activity / block - code that uses this mechanism of having a token passed directly into the activity will never need to call the web services designed to be used by an admin to manage the moodle web site.

I think that web services designed to be called from client side code should be in a different file in the mod/{activity} or block/{blockname} directories than external.php. external.php will be used for administrative type web service functions. Code callable from within a client side app will look for a file of another file name in the mod/{activity} or block/{blockname} directories which will be used in the same way. Only the web services exposed in this file will be available to the client side code.

Of course access to web services is already controlled by checking capabilities of the user. And applets/object embedded in a web page and passed a token to access web services will not hopefully include malicious code but this will provide an extra level of protection and seperation seems sensible as the functionality needed is fundamentally different.

Client side apps for site administration

We might like to allow some client side apps full access to all web services that the user has access to. We can have the function that is used to generate the token have an optional parameter for a context id. If no context id is passed then the client side app is allowed full access to all web services in external.php files.

Use of SESSION from web services for client side apps

Interestingly since web service calls from the Flash client for example are passed through the web browser the same http cookies are passed to the server along with the web service request as with other http requests from the browser. So the same $SESSION is automatically available for use by Moodle core code as is available in all over scripts in Moodle. But presumably we are going to override the use of the $SESSION variable for web services and ignore the cookies passed along with web services requests from Flash.

評比平均分數： -
In reply to Jamie Pratt

Re: Moodle 2.0 : some questions that need to be considered if we want to have web services available for client side Flash / Java / js etc

由Jérôme Mouneyrac發表於
Hi Jamie,
thanks for this great post.
if I understand, for the second use case, your main concern is to know where is embedded the client app. And so the client app can know the user, the course...

I'm not sure that writing the token into the HTML would be good. The Moodle user would easily know about the token.

It would probably be better than the embedded object receive a course name/user name/... by url when it's called. Then it authenticates like any other "admin" app (the first use case).

Maybe can you give a real example of the second use case that would not work with the current WS implementation?


評比平均分數： -
In reply to Jérôme Mouneyrac

Re: Moodle 2.0 : some questions that need to be considered if we want to have web services available for client side Flash / Java / js etc

由Jamie Pratt發表於
Hi Jerome,

We need some secure way of having the object/applet log itself in.

We cannot pass the username and password to the object/applet through html, this would give away the password. We can pass a token to the client app through html. The token would be temporarily valid. A different random string token would be generated for web service 'session' started. The token would have at least an associated :

  • userid
  • last access time
  • contextid might be a good idea too.
I would presume actually Petr is going to somehow rewrite session handling so that Moodle can handle sessions for web services as well as for serving html pages to a web browser. I would propose that there be 2 ways to start a web services session :
  • either a function is called on the server directly to request the token to pass into the client side embedded app through html.
  • a web service is called with the username and password to log in with and the token is passed back to the client as the result of the web service.
Jamie
評比平均分數： -
In reply to Jamie Pratt

Re: Moodle 2.0 : some questions that need to be considered if we want to have web services available for client side Flash / Java / js etc

由Jérôme Mouneyrac發表於
Here is a summary of a recent conversation between Jamie and me:

The current Moodle WS implementation is:
The client app (embedded or not) calls an authentication method with a username/password. The client app receives a token back and calls other web service functions with this token.

The way it works for a client app user:
The user signs up for a Moodle web service account on a Moodle site. He enters his username/password into the client app, thus giving the client app his ws rights. The client app can choose to save or not the username/password.

Problem: for embedded app, everytime the page is refreshed, the authentication method needs to be called. So the embedded client app needs to save the username/password somewhere. Not easy...


Jamie suggestion is:
The embedded app reads a token from HTML page and gains user capabilities. In the Moodle administration panel, we'll have an embedded application manager, in order to add trusted embedded application.
Client apps should use the user's capabilities then authenticate with normal user accounts.
The advantage is that it is easier to retrieve information about what the user is doing, but moreover the embedded app doesn't need authentication.

Jamie don't hesitate to complete this summary if I missed something.

評比平均分數： -
In reply to Jérôme Mouneyrac

Re: Moodle 2.0 : some questions that need to be considered if we want to have web services available for client side Flash / Java / js etc

由Martin Dougiamas發表於
Core developers的相片 Documentation writers的相片 Moodle HQ的相片 Particularly helpful Moodlers的相片 Plugin developers的相片 Testers的相片
Hmm, a token like that in the HTML (which I presume is directly accessible from something like Flash) could easily be stolen no? (eg do quick "view source" on the teacher's computer when they aren't looking)

And what happens if the embedded application is malicious ... eg a student got an admin to look at something they inserted ... I guess the application could run web service functions as an admin?

評比平均分數： -
In reply to Martin Dougiamas

Re: Moodle 2.0 : some questions that need to be considered if we want to have web services available for client side Flash / Java / js etc

由Jamie Pratt發表於
Hmm, a token like that in the HTML (which I presume is directly accessible from something like Flash) could easily be stolen no? (eg do quick "view source" on the teacher's computer when they aren't looking)

It would be temporarily valid only for that session.

But this is a potential problem, I think quite a small one. What would someone do with this token? If they have the expertise to do something like that then they might also have the expertise to steal the session id from the teacher's cookies.

Maybe for this reason we should use the existing cookies which we already use. Flash in a browser sends it's web service requests through the browser and I hope in 100% of cases the regular cookies are sent along with the web service requests.

And what happens if the embedded application is malicious ... eg a student got an admin to look at something they inserted ... I guess the application could run web service functions as an admin?

Passing a token into the Flash movie would require writing php code to call a function on the server and then output the html which embeds the Flash with a parameter passing the token. User uploaded Flash files would have no access to the token.

Martin Langhoff, I and others previously discussed this method of authenticating a web service request here.
評比平均分數： -
In reply to Jérôme Mouneyrac

Re: Moodle 2.0 : some questions that need to be considered if we want to have web services available for client side Flash / Java / js etc

由Jamie Pratt發表於
Some corrections :

Jamie suggestion is:
The embedded app reads a token from HTML page and gains user capabilities. In the Moodle administration panel, we'll have an embedded application manager, in order to add trusted embedded application.
Client apps should use the user's capabilities then authenticate with normal user accounts. the client will authenticate with the token.
The advantage is that it is easier to retrieve information about what the user is doing, but moreover the embedded app doesn't need authentication.
評比平均分數： -
In reply to Jamie Pratt

Re: Moodle 2.0 : some questions that need to be considered if we want to have web services available for client side Flash / Java / js etc

由Jamie Pratt發表於
I'm going to discuss this through skype with folks from Moodle HQ in a minute. Thought I would take the time to write a summary of my thoughts here first.

What I want us to do

Make it easy to have embedded apps communicate with Moodle. Each time the user loads a page with an embedded Flash object / other client side code they should not have to enter their password.

The embedded apps might be used in the following places for example :

  • blocks
  • activities
  • quiz reports
  • questions in quizzes
  • admin tools
  • etc

How can we do this

I think there are two options to consider :

  • Use existing cookies
    • advantage of this is that it is easy.
    • PROBABLY will work with all browsers and client side code that might want to use web services.
  • Use a token passed into the embedded client code.
    • danger the token could be stolen by a user who views source.
    • must put a if fork in config.php to deal with the token and ignore the usual cookies. But this must be done anyway for external apps that use web services.

Actual Mechanics - step by step of a web service call and authentication for an embedded app

  • The php page with the embedded app is called.
  • In the php script a function is called to generate a token :
    • this include an array of functions that the token allows access to. Eg. [0]=>'user/' => 'get_users',[1]=>'forum/' => 'get_forums', [3]=>'mod/{modname}/' => '*',
    • we restrict the access as much as possible.
    • Probably for an activity or block for example the token would only allow access to the services for that block.
  • The token is passed into the clientside app through appropriate html - in the case of Flash through Flashvars.
  • When the client calls the web service the token is passed as well as 'credentials'.
  • Moodle recognizes the user from the token. Config.php has a fork in it and sets up the USER and SESSION variables appropriately using the token and not the cookies - tricky.


Security

In order to minimize security risk :

  • we can make the tokens expire afer a certain period of inactivity of the client app.
  • we can limit the services that the token allows access to. I would suggest that we limit by path of external.php and also to functions within the external.php file.

Keeping other data on server side

It is usually the case that module id and such is passed to Moodle in the url. In the case of web service calls I think it would be a good idea to store perhaps the contextid on the server side associated with the token. This would increase security.

So for example for grading an activity we have a web service {activityname}_grade(). Since we have already stored the context id on the server we know the grade is passed is for such and such an activity. We do not pass the contextid as a parameter in the web service call and a web service call cannot be spoofed to pass a grade for another activity once the user has a token.
評比平均分數： -
In reply to Jamie Pratt

Re: Moodle 2.0 : some questions that need to be considered if we want to have web services available for client side Flash / Java / js etc

由Ludo (Marc Alier)發表於
Hi Jamie!
I beliebe that embedded apps can be done with the IMS LTI 2.0 (learning technologies for interoperability) that is being released very soon. Jordi Piguillem developed a implementation of an earlier version called SimpleLTI as his google summer of code. I will be posting some documentation this week.
Cheers!
L.
評比平均分數： -
In reply to Ludo (Marc Alier)

Re: Moodle 2.0 : some questions that need to be considered if we want to have web services available for client side Flash / Java / js etc

由Brian Jorgensen發表於
Hey, Ludo:


Is there a Moodle IMS LTI consumer available anywhere to play with?


Thanks,

Brian
評比平均分數： -
In reply to Brian Jorgensen

Re: Moodle 2.0 : some questions that need to be considered if we want to have web services available for client side Flash / Java / js etc

由Tim Hunt發表於
Core developers的相片 Documentation writers的相片 Particularly helpful Moodlers的相片 Peer reviewers的相片 Plugin developers的相片
Are you talking about IMS Learning Tools Interoperability? I keep meaning to read that spec, but always seem to have something better to do.

Can you summarise for us what LTI does, and how it would work in/with Moodle. Thanks.
評比平均分數： -
In reply to Tim Hunt

Re: Moodle 2.0 : some questions that need to be considered if we want to have web services available for client side Flash / Java / js etc

由Brian Jorgensen發表於
Hey, Tim:


Well, I was hoping Ludo or Jordi would jump in here, since they did the GSOC 2008 project; I have an offlist email pinging Ludo, but I think maybe Spain is on vacation right now.

smile

I thought IMS LTI came about as an extension of the coolness of the Rutgers Sakai linktool for visually embedding external apps right into Sakai: basically a tool that proxied basic auth credentials to an external app, and embedded the result into an iframe, but I could be wrong. (I've also emailed Chuck Sev to see if he would like to jump in here.)

A recent Sakai presentation looks like IMS LTI has grown to be more than basic auth plus embedding: slideshare.net.


Brian
評比平均分數： -
In reply to Tim Hunt

Re: Moodle 2.0 : some questions that need to be considered if we want to have web services available for client side Flash / Java / js etc

由Charles Severance發表於
Brian - thanks for the heads up. TIm, IMS LTI has two parts - Basic LTI and Full LTI. Basic LTI is launch-only and Full LTI does provisioning, launch, and run-time web services. Marc and Jordi are working on Basic LTI for Moodle 2.0.

Basic LTI essentially allows you to author a Basic LTI resource in a Moodle course like any other resource. In a sense, it is a "smart iFrame". When you select the resource, instead of just putting the URL in the iFrame, Moodle will generate a form with the user and course information and then sign that request using OAuth (www.oauth.net) and a key/secret stored by the instructor inside Moodle and then auto-post the form, sending the user and course data to the external tool.

OAuth is used by Google and Twitter to establish server-to-server identity and end-user identity. IMS LTI only is using the server-to-server part of OAuth. OAuth insures against replay attack, password guessing attack. Since OAuth is designed to pass through a user's browser, the data can be "viewed" without compromising security.

Basic LTI allows us to build lots of simple external tools for teaching and plug them into Moodle, Sakai, Blackboard, D2L, etc with the same integration (i.e. Basic LTI).

For all the LMS systems it means less need to install Moodle Modules, Sakai Tools or Building Blocks of "unknown quality" just to play with some tool in one class. It allows both the LMS developers and the LMS administrators to keep their systems clean and unmodified - while at the same time allowing teachers and learners far greater flexibility in the tools they can use in their courses.

It is my hope that this ushers in a new era where really cool learning-focused tools can be developed and used regardless of the LMS system in use at a campus.

I am hopeful that once we get Basic LTI support in all of the major LMS systems, then we can work on trading Learning Tools like trading cards. Instead of needing some PHP code installed in your system - you can add a new tool with a URL, Key, and Secret and a couple of clicks.

This is made even more exciting when we can create course cartridges with Basic LTI Launches embedded in them. This makes cartridges simpler, and smaller and yet allows very rich cartridges to be produced and distributed.

The status of LTI is that Basic LTI is about to be sent to the IMS Technical Advisory Board for review, approval, and release. The draft of the spec is only available to IMS members until it is approved and released as a final spec. There is a public discussion forum about IMS specs at:

http://www.imsglobal.org/community/forum/index.cfm?forumid=11

Let me know if you have any questions.
評比平均分數： -
In reply to Charles Severance

Re: Moodle 2.0 : some questions that need to be considered if we want to have web services available for client side Flash / Java / js etc

由Tim Hunt發表於
Core developers的相片 Documentation writers的相片 Particularly helpful Moodlers的相片 Peer reviewers的相片 Plugin developers的相片
Sounds useful.

Is Basic LTI a smart enough iframe that it can report as score back to the Moodle (or whatever) gradebook too? That is required for it t be a full answer to some recent integration requests I have seen in these forums.
評比平均分數： -
In reply to Tim Hunt

Re: Moodle 2.0 : some questions that need to be considered if we want to have web services available for client side Flash / Java / js etc

由Charles Severance發表於
Several answers 微笑

(1) No - Basic LTI focuses on the launch only and does not include provisions for standardized web service call backs. We kept things simple in Basic LTI to insure that it got into the shipping versions main LMS systems in the market as quickly as possible. Admittedly, once you have launch - the immediate next requirement is returning results.

(2) Maybe - If the LMS supported the IMS Learner Information Service (LIS) OutCome service - and the external tool was separately allowed to call the service, Basic LTI has a provision to include the LIS Result Identifier as part of the launch. There are no LMS systems that have LIS OutCome service on their roadmaps at this time.

(3) In Full LTI - there will be an Outcome service based on the LIS and Full LTI will include a mechanism to exchange security bits so that the tool can talk to these Full LTI run-time services. Full LTI is also not on any road map as best I know.

(4) Lots of LMS systems (Sakai included) slip some extension bits into the launch that provide information to call non-standard LMS specific web services. So Sakai slips a "sakai_session" value which is a signed session key which is used to talk to some specifically installed web services in Sakai. In the short term, Moodle should do the same (i.e. include some bits where appropriate to allow external tools to call back to Moodle when called form Moodle).

The last scenario (4) allows a standard launch and non-standard call-back. Full LTI moves us to a standard launch and call-back.

From a specification / standards perspective - the quickest way to get from here to the desired state is for us (IMS LTI Working Group) to get Full LTI out and ready to implement. Getting Basic LTI out early lets us all get a start on those tools that can handle a launch-only spec and inform the Full LTI development going forward.
評比平均分數： -
In reply to Tim Hunt

Re: Moodle 2.0 : some questions that need to be considered if we want to have web services available for client side Flash / Java / js etc

由Charles Severance發表於
Updating this thread a bit with recent events regarding IMS Basic LTI and Moodle.

- IMS Basic LTI was approved as a standard in June 2010

- There is a 1.9 module that passes the IMS Basic LTI certification test. Here is the site for that module:

http://code.google.com/p/basiclti4moodle/

- Here is a video of Moodle passing the IMS Basic LTI Certification test:

http://www.vimeo.com/9957979

- Marc Alier and Nikolas Galanis of UPC is porting the module to Moodle 2.0

- We are in the process of building some experimental support for Basic LTI Tools to return grades back to the Moodle Grade Book. A very early prototype of this code if here:

http://code.google.com/r/drchuck-simpleoutcomes/

Perhaps we should make a separate forum for Basic LTI in Moodle to have some ongoing discussions about this as it evolves.
評比平均分數： -
In reply to Brian Jorgensen

Re: Moodle 2.0 : some questions that need to be considered if we want to have web services available for client side Flash / Java / js etc

由Charles Severance發表於
Brian, while the spec for IMS Basic LTI is not yet available, a simple unofficial reference implementation in PHP and Java is available here:

http://code.google.com/p/ims-dev/

You can download and simply run the PHP code in a PHP server to play with both the LMS and Tool aspects of Basic LTI.

The PHP sample code will likely form the starting point for the Basic LTI in Moodle 2.0 as well as the Simple LTI Moodle Module.
評比平均分數： -
In reply to Brian Jorgensen

Re: Moodle 2.0 : some questions that need to be considered if we want to have web services available for client side Flash / Java / js etc

由Ludo (Marc Alier)發表於
Sorry for the long delay, I lost track of this thread for a while.
We are coding the IMS BAsicLTI consumer here http://code.google.com/p/basiclti4moodle/ Cheers
L.
評比平均分數： -
In reply to Ludo (Marc Alier)

Re: Moodle 2.0 : some questions that need to be considered if we want to have web services available for client side Flash / Java / js etc

由Lailatul Hidayah發表於
Thank you for the information. Then I will try SimpleLTI as my solution. Hope I can understand it soon. nice to be here ^_^
評比平均分數： -