I know of two cases of external programs being used as "program" resources: webwork and brainstorm.
Are there any more?
The original code for this was contributed, and I never had much time to look at it. I was just documenting it though, and I feel like I want to clean it up somewhat, including changing some variable names.
This would break any current use of the program resource, but will hopefully make it easier to use in future applications.
My proposed list of the information to be sent to external applications is:
moodle_navigation: current crumb trail as a serialized, encoded array
moodle_resource: the resource id
moodle_username: current username
moodle_firstname: current user's firstname
moodle_lastname: current user's lastname
moodle_password: based on a password defined when creating the resource definition. This would be hashed together with the username and sent as a md5 (eg md5($username.$password) ). At the other end, the program could recreate the hash and compare it for security.
All this would be sent via POST instead of GET.
Anything else that would be useful?
(Bi-directionality can wait for another day - there would be a mod/resource/program.php script for that).
Could you please include the "ID Number" in the variables to be passed? For courses where the instructor is tracking students by their student IDs, this would be invaluable. For example, I might want to have the outside resource write performance data to a separate (non-Moodle) database.
Absolutely, yes. Good idea.
Are you considering to mkae Moodle "aware" of the activities in these "program resources"?
For example if it is a single-student-activity-module, it would be nice if some sort of information exchange about the activity could take place. (The SCORM subset of the old AICC-standard...)
If I create a kind of resource with a built-in test, I would like to communicateback to Moodle that student with id=x did the test at time=y and got the score=z..
Moodle should show these results in the Moodle student overview.
(I am NOT asking for a complete CBT-structure: there are programs enough that can handle that, but their is no time and money enough in normal education institutes to develop complete tuned CBTs..)
With Moodle you arrange activities in a more loose way, so should be the student-result-overview ..
Yes, this is the bidirectionality I mentioned briefly. Mostly it would be returning grades.
Hi Martin,
Actually we had to hack the program resource code in v. 1.0.8.1 a bit to get it
to work with WeBWorK. We're now rewriting the interface as a separate module,
instead of interfacing with the program resource code. So I guess it really doesn't
matter for us how you rewrite this code.
However just a few comments on your proposed list of information to be passed to an
external program. In my interface with WeBWorK, it is much more convenient
to use a single password to the interface, instead of distinct passwords for
every URL which accesses the interface, as you are proposing. I don't want to
have course creators to have to enter this password every time they create
such a URL. Indeed for the sake of security, I don't want them to know this password.
I think you should allow this alternative means of setting up a password.
Also I pass the current time (at which the URL was invoked) and hash it with the
other information, to guard against replay attacks into WeBWorK.
Zig
Yes, good idea about the password. It should at least be an option.
Hi, Zig!
It's a year later, but we're actually re-implementing the Program resource module right now, it will make it easy to insert nearly any field from the user, course and config tables, plus a few other things. In addition you can pass these to any Moodle file as well outside URLs.
I'm interested in making this as secure as possible, though. What else can we add?
You mentioned hashing the time with other information to guard against replay attacks ... can you please explain this in more detail? How does it help?
If anyone else has any good ideas for encrypted methods for making a program link more secure, please come forth!
It's a year later, but we're actually re-implementing the Program resource module right now, it will make it easy to insert nearly any field from the user, course and config tables, plus a few other things. In addition you can pass these to any Moodle file as well outside URLs.
I'm interested in making this as secure as possible, though. What else can we add?
You mentioned hashing the time with other information to guard against replay attacks ... can you please explain this in more detail? How does it help?
If anyone else has any good ideas for encrypted methods for making a program link more secure, please come forth!
Hi Martin,
If someone were eavesdropping on the http exchange when a program resource is being invoked, the eavesdropper could save that information and resend it at some later time from his/her own computer. If this information didn't have same way of having its validity expired, the eavesdropper would have perpetual login access to the program resource.
In my webwork module, the http exchange includes the time of invocation sent in the clear and also hashed with the other login information. On the other end, the WeBWorK server looks at the time of invocation (sent in the clear) and if it is over 40 seconds old, rejects it. If not, it hashes the time of invocation into the other secure login information and compares the resulting hash with the one which was sent over by Moodle. Only then is the login to WeBWorK granted.
The relevant code on the Moodle end of the webwork module is
If someone were eavesdropping on the http exchange when a program resource is being invoked, the eavesdropper could save that information and resend it at some later time from his/her own computer. If this information didn't have same way of having its validity expired, the eavesdropper would have perpetual login access to the program resource.
In my webwork module, the http exchange includes the time of invocation sent in the clear and also hashed with the other login information. On the other end, the WeBWorK server looks at the time of invocation (sent in the clear) and if it is over 40 seconds old, rejects it. If not, it hashes the time of invocation into the other secure login information and compares the resulting hash with the one which was sent over by Moodle. Only then is the login to WeBWorK granted.
The relevant code on the Moodle end of the webwork module is
if ($webwork->type == GATEWAY) {
$temp .= urlencode(md5("My top secret" .$temptime. urlencode($USER->username) . $webwork->quiz_time));
} else {
$temp .= urlencode(md5("My top secret" .$temptime. urlencode($USER->username)));
}
in http://cvs.sourceforge.net/viewcvs.py/moodle/contrib/webwork/moodle/mod/webwork/view.php?rev=1.2&view=auto
(The GATEWAY version (for a WeBWorK quiz) also has the amount of time allowed for the quiz added to the hash.)
The corresponding code on WeBWorK end of the webwork module is
my $digest0 = "My top secret";
[deletia]
my $moodle_user = $q->param("extern_usr");
my $moodle_name = $q->param("extern_nam");
my $moodle_time = $q->param("extern_tim");
my $moodle_md5 = $q->param("extern_pwd");
my $time = time();
my $digest = md5_hex($digest0 . $moodle_time . $moodle_user);
in
http://cvs.sourceforge.net/viewcvs.py/moodle/contrib/webwork/webwork/system/cgi/cgi-scripts/moodle2wwk.pl?rev=1.2&view=auto
(for homework assignments) and similar code in http://cvs.sourceforge.net/viewcvs.py/moodle/contrib/webwork/webwork/system/cgi/cgi-scripts/moodle2gway.pl?rev=1.2&view=auto (for quizes).
As an additional security measure, it would also be worthwhile to allow the client IP address to be part of the information to be hashed.
Hope this helps,
Zig
Thanks, Zig, very helpful!
I like the idea of using the client IP in particular, since that's something that can be easily determined at both ends without sending any data like the time over in the clear.
So, for a simplified system, how about if the standard secret key is an md5 hash of:
That should be enough, yes?
I like the idea of using the client IP in particular, since that's something that can be easily determined at both ends without sending any data like the time over in the clear.
So, for a simplified system, how about if the standard secret key is an md5 hash of:
- a phrase set by the admin for the whole site ($CFG->resource_secretphrase) and
- the IP of the current user?
That should be enough, yes?
I think the username should also be part of the hash. Otherwise, I think it should work great.
The problem is that the username is no longer always sent (and even when it is, then presumably anyone intercepting the request would then also have this information).
Hi Martin!
When you refer to Client IP, does that mean a user could only utilize the programs from specific computers??
WP1
When you refer to Client IP, does that mean a user could only utilize the programs from specific computers??
WP1
No, it's just one way to confirm that the person arriving at the resource is the same person who clicked on the link within Moodle.
Just a proposal
add moodle_lang: Prefered natural language for the user.
-- Sven.-Erik Tiberg --
Hi
Would like to suggest
moodle_userCat ; User category [ teatcher | student | guest |... ]
Are there any need of variables to handle sessions data?
-- Sven Tiberg --
Hi
Pls. skip my last idea about a session parrameter. Like more to have a cookie paramneter.as session data only resides in one server, couldn't be used by external resoures as they are runniing on other servers. On the other hand cookies are stored in the clients computer and can be used by any resource on any server.
moodle_cookieID [ name of cookie consist of "moodle" + a timestamp ]
Our purpouse are to transfere information from one resource into the next, where the resources could be running on different server.
Example: a laboration to design a drivetrain in a car. more precicly the ratio of gears where you have to itterate the gear ratio layout over acceleration v.s.fueleconomy. This example can consists of a input page for gear ratio and two calculation modules, where the modules would use a common "area" (=cookie) of an array with gear ratios, a URLpointer to specific fuel consumption def. file, a URLpointer to vehicle parramters as CW, frontarea, weight, drive train masses a.s.o. and a URLpointer to a writeable history file. And maybee some more items.
Just a 0.50SKr suggestion.
Sven-Erik Tiberg
I am a bit confused... I would like to integrate various web applications in Moodle courses. This should give you an idea of the type of applications:
- an equation plotter (see also this discussion)
- multiple regression
- time series analysis
- lots of descriptive statistics apps
The idea is to have students do assignments with the online applications, based on datasets in a database (maintained by the web application). I would like to be able to do the following:
- record student analysis activity inside Moodle (the web applications should return information of the type of instruction, and the data that was used)
- allow students to upload data to the web application's database (Moodle should record the upload in the student's stats - the actual data is stored and maintained by the web app)
- the output of the web application (either html, xls, doc or pdf) should be displayed in a frame (or a pop-up window) - students should have the option to print, or store the output in their personal archive (stored by Moodle - teachers should be able to define the amount of storage space per student). Stored output can always be retrieved, copied, deleted, or transmitted to students/educators without the need to recompute (or reconnect to the web app). Educators can browse through the archives and leave 'comments'. It should be easy to refer to stored output in forums, etc..
What should I do to achieve this? If I am not mistaken the 'Program' interface is part of the Resource module. Wouldn't it be better to have a separate module? Also, it would be nice if we could have some sort of (PHP) wrapper code to make it easier for the web applications developers to make the web software available to students/Moodlers.
Is there anything I can do to make this work?
The new "program resources" are working well in development CVS now.
The changes are significant, and old-style program resources are not upgraded to the new system, so please redo your old program resources if you had any.
The way it works now is as extra parameters on the standard resource type for adding a file (both uploaded files and external URLs). There is a big list of data to choose from (suggestions for more are welcome!), and you can assign it any parameter name you like.
I expect to see this used a lot to pass information to Javascript and Flash files within Moodle, as well as external web sites.
Here is a simple example that may give you some idea of what is now possible.
The changes are significant, and old-style program resources are not upgraded to the new system, so please redo your old program resources if you had any.
The way it works now is as extra parameters on the standard resource type for adding a file (both uploaded files and external URLs). There is a big list of data to choose from (suggestions for more are welcome!), and you can assign it any parameter name you like.
I expect to see this used a lot to pass information to Javascript and Flash files within Moodle, as well as external web sites.
Here is a simple example that may give you some idea of what is now possible.
Hi Martin,
I just ran across this and got an idea: You know I have always wanted to be able to give students (instant) feedback/recommendations based on a quiz score. Would this work to do this? By passing their score to a "else if" javascript based on a range of scores that would bring up the feedback?
Thanks
Chardelle
Hi!
Does the solution with the javascript "else if" of Chardelle for the individual feedback on scores exist? If somebody has the solution for this, please, please be so kind and give it to me!
Thx
Thomas
We would love to have the sesisonid passed in. We would love to be able to correlate the tracking we do in our external python app with the sessionid in moodle (we don't need formal session management, just the unique sessionid)
We've made a slight mod to our version of the program resource which lets us keep the moodle header on top of our app (breadcrumbs...), to give the user a seemless experience (they don't know they've "left" moodle), they click around, and currently we have 2 seperate tracking databases.
We've made a slight mod to our version of the program resource which lets us keep the moodle header on top of our app (breadcrumbs...), to give the user a seemless experience (they don't know they've "left" moodle), they click around, and currently we have 2 seperate tracking databases.