Object Authorization
From SLIS Second Life Wiki
- Note: this page refers to authorizing course-based objects. For user-centric objects, such as the Sloodle Toolbar, see the User Object Authorization page.
Object authorization is an alternative to the Prim Password security method for Sloodle objects. Instead of having a single password for all objects in the course/site to use, the teacher or administrator must explicitly authorize an individual object whenever it is going to be used. If the object's key (UUID) changes (e.g. duplication, deletion etc.), then it must be re-authorized.
Note that object authorization is performed slightly differently depending on which version of Sloodle you are using. In Sloodle 0.3, objects are authorized for specific courses, and this can be done by anybody who is a teacher on that course. In older versions, objects were authorized for the entire site, and this could only be done by administrators.
Contents |
Object Specific Key
At the heart of the object authorization process is the object-specific key. This is a combination of the object's UUID, and numeric password (normally 9 digits). It takes the format "UUID|password", for example:
abcdefgh-1234-5678-ijkl-mnopqrstuvwx|123456789
The string as a whole is typically stored and passed in a variable/parameter called 'sloodlepwd'. Any script handling passwords like this should automatically tell the different between an object-specific key, and a Prim Password (the prim password does not contain the UUID).
Sloodle 0.3
Sloodle Versions: 0.3 (?)
Authorizing an Object
Object authorization is the recommended approach to security in Sloodle 0.3, and it will be automatically performed for you on tools which are rezzed using the Sloodle Set (although you will still need to configure them). If you rez an object manually (e.g. from your inventory) then you must touch it to initiate authorization. You must then chat the URL of your Moodle address, starting with "http", but without a slash (/) or a file (*.php) at the end. For example:
http://www.sloodle.org
You can also chat it on channel 1, so that you don't disturb others, e.g.:
/1 http://www.myeducationalsite.org/moodle
The tool will then confirm that it can communicate with the Moodle site, and will then give you a URL. Load the URL in your browser, and login to Moodle if necessary. You will then see a page with a box listing all the courses on which you are a teacher/administrator, and which can be used with Sloodle. Below each course will be a list of the Sloodle Controller Modules in that course -- select which one you would like to connect to. Click on the submit button at the bottom of the page to complete authorization. You will then be forwarded to the web configuration page.
Note: below the box of courses, there is a question asking if you want to authorize the object. Normally leave that set to "Yes", however, if you decide not to authorize the object, select "No" and click the submit button. This will delete the object from the database.
Viewing Authorized Objects
If you would like to view, delete or re-configure any objects which have been authorized for a course, then navigate to that course's main page. There should be at least one Sloodle Controller Module on the course, so click on it, and on the subsequent page, you will see a list of objects at the bottom.
Re-configuring
Click on the object name to go to its configuration page where you will see its current settings, and change them. Please note, however, that the object in-world will not automatically download this new configuration. You will need to force it to retrieve a new configuration.
The simplest way to do this is to reset the main LSL script. You can do this if you right-click the object, click "Edit", select the "Contents" tab, and double-click the script whose name begins with "sloodle_mod_". The script should open up, at which point click the "Reset" button at the bottom right, close the script, and close the edit window. Finally, touch the tool, and it will report that it is requesting its configuration, and then you can begin using it again.
Deleting
You can also delete objects by ticking the checkboxes to the side, and clicking the delete button at the bottom. Deleting authorized objects will prevent that object from accessing your Moodle site by deleting its password and configuration data from the database. This will not alter the tool in Second Life, except that it will no longer be able to communicate with Moodle. You can re-authorise the object by resetting or re-rezzing it and starting the authorisation process again.
Authorization Expiry
It is important to note that authorized objects will 'expire' after a period of inactivity. The duration can be changed in the Sloodle Module Configuration (which must be done by an administrator), but is 7 days by default. A tool is considered inactive if it is not rezzed or being used at all for 7 days. Any tool which still exists in-world (i.e. has not been deleted) will normally notify Moodle 2 or 3 times per day that it is still active.
Sloodle 0.19, 0.2, 0.21
Sloodle Versions: 0.19,0.2,0.21 (?)
Older versions of Sloodle had a much more basic object authorization system. The only Sloodle tool which supported it was the Sloodle Set (version 0.71 and earlier). Additionally, each object was authorized to access the entire Moodle site, and the authorization never expired.
Authorizing an Object
To initiate authorization of the Sloodle Set, you have to touch the slanted control panel, select "Set Moodle", and chat the address of your Moodle site on chat channel 1, e.g.:
http://www.sloodle.org
You will then be given a URL, which you should load in your browser and login to Moodle if necessary. You will see a page identifying the object your are authorizing. Click the "Yes" button to authorize the object.
Developer Information
The security is implemented in a similar way to Prim Password security, except that the passwords are per-object instead of per-Controller (Sloodle 0.3) or per-site (Sloodle <= 0.21). When an object connects to a Sloodle script in Moodle, the Sloodle system attempts to 'authenticate' the request. It does this by checking the 'sloodlepwd' parameter -- if it is simply a numerical password, then it is treated as a Prim Password. However, if it contains a UUID as well (in the format "UUID|password"), then Sloodle looks up the table of active objects for an object identified by the UUID, and checks if the password matches.
In Sloodle 0.3, the objects are authorized for individual Sloodle Controller Modules, and so a further check is initiated to make sure that the object is not trying to connect to an unauthorised Controller. The Controller being accessed is identified by its course module ID in the 'sloodlecontrollerid' HTTP parameter. Furthermore, whenever the system attempts to load a Moode module (such as a chatroom or glossary), it will ensure that the module is in the same course as the Controller.
Password Creation
In Sloodle version before 0.3, the Moodle site would send an XMLRPC message to the Sloodle object, containing its new password. However, in Sloodle 0.3, the object itself generates it own password, and sends it to Moodle. This is much more secure, as the password is not passed into Second Life at all, reducing the likelihood of unauthorised interception.
| This page is part of the Sloodle documentation | |||
|---|---|---|---|
| SloodleDocs Home | User Documentation | Administrator Documentation | Developer Documentation | Sloodle Wiki Home | |||
