Platform server (web-application) for the MLE
To use the full power of the MLE you will need a platform server. A platform server is a standard web server application, which is adapted to the interfaces of the MLE. It doesn't matter which web server and which programming language you use to create your own platform server, as long as you support the interfaces described in this document.
The main goal of the platform server is to provide the client (MLE) with content. Usually this content consists out of MLE-XML documents (see the MLE-XML specification for details), binaries and content-packages (eg: learning objects, see the MLE-Content packaging specification for details). Furthermore the platform server should interact with the messaging server and should provide the possibility for the mobile client to send new messages to other clients.
Here you can download a sample platform server written in PHP and adapt this web application to your needs. No matter if you want to use the MLE for mobile learning or for any other mobile service you can use this sample server as a start.
This sample PHP platform server is also very good to understand how a platform server communicates with the MLE, how the interfaces are realized in PHP and how to interacte with the messaging server. So even if you don't plan to write the platform server in PHP, take a look on this sample platform server.
Why do I need a platform server?
- If you want to use the authentification feature of the MLE. The MLE sends the user and password data only to valid platform servers. A normal HTTP request doesn't contain the user-data.
- You get access to additional HTTP headers with detailed information about the client
- The linking to ressources is much easier then the linking to HTTP-ressources
- If you want to use the MLE editor to create MLE-XML documents over a graphical user interface
You access a ressource on the platform-server via the link-type "m".
Useually all HTTP requests to the platform-server are HTTP-GET request, the only exception are uploads, which are useually send as HTTP-POST requests (this can be customized).
Access types by the MLE for platform servers:
There are two different ways the MLE can access a platform server, which are defined on the client side by the build-property "project.mlp.servertypes" (you can define this property in your build property file, eg: "ressources/projects/build_project_sample.properties"):
|<link type="m" url="pages/welcome.php" ...>||http://yoursever.com/?xml=pages/welcome.php|
|<image type="m" url="data/image.png">||http://yoursever.com/?bin=data/image.png|
|<button type="d" action="data/sample.zip" ...>||http://yoursever.com/?content=data/sample.png|
|<link type="m" url="pages/welcome.php" ...>||http://yoursever.com/xml/pages/welcome.php|
|<image type="m" url="data/image.png">||http://yoursever.com/bin/data/image.png|
|<button type="d" action="data/sample.zip" ...>||http://yoursever.com/content/data/sample.png|
As you can see, both platform server-URLs are the same, but the generation of the URLs are different. What access type you use is up to you, don't forget to set the "project.mlp.servertypes" property correctly. The sample PHP platform server works with the "project.mlp.servertypes=true" setting.
The previous examples already showed that there are three main access-types:
|xml||Expects a MLE-XML document. Don't forget to set the content-type to "text/xml".|
|bin||Expects a binary (like an image). Don't forget to set the content-type and the content-length correctly.|
|content||Expects a binary content package (a ZIP file). Don't forget to set the content-type ("application/zip") and the content-length correctly.|
Whatever the main service of your platform server is (mobile learning or any other mobile service), you will implement your service with MLE-XML documents, which are accessed over the "xml"-GET-request. To enable dynamic and client specific output, you won't use static MLE-XML documents. Instead you will use scripts to generate dynamic XML output. For example the sample PHP platform server includes PHP-scripts for the most "xml"-requests, which generate dynamic XML output. The client (MLE) doesn't care if you return a static file or if you generate the XML code on the fly. Here are some examples for "xml"-requests (work for the other two request types as well), which use additional request parameters:
|LINK-Tag URL value:||HTTP request (servertype=false):||HTTP request (servertype=true):|
|url=“pages/start.php?param1= value1¶m2=value2“||...?xml=pages/start.php¶m1= value1¶m2=value2||../xml/pages/start.php?param1= value1¶m2=value2|
|url=“index.xml&p1=v1“||...?xml=index.xml&p1=v1||Error! Invalid URL: .../xml/index.xml&p1=v1|
As you can see in these examples you have to escape the "&" to "&" in your URL-values. The last example "index.xml&p1=v1" is an error, because the parameters don't start with an "?". Nevertheless this still works for the servertype=false, but not for the other one, as you can see in the example.
Authentification of the client:
The user authentication is done with two request-headers:
- „MLIBERA_USERNAME“ --> contains the username
- „MLIBERA_PASSWORD“ --> contains the password
- "MLIBERA_AUTH_KEY" --> contains the dynamic key need for the authentication mode 2 and 3
These headers are always sent, at each request, but it is recommended to to the authentication the first time and then store the authenticated user in the session.
The MLE has currently four build-in authentication modes:
- Mode 0: password is hashed with MD5 (standard)
- Mode 1: password is transfered in plain text
- Mode 2: password is hashed with MD5, than a dynamic key is added; afterwards this new text is again hashed with MD5
- Mode 3: password is plain text, to which a dynamic key is added; afterwards this new text is hashed with MD5
For the authentication mode 2 and 3 the gateway server generates a random key which is sent to the MLE after the connection was opened (the password is encrypted with this key). Due the reason that the gateway server doesn't know which authentication mode the MLE is using, this header variable is always sent to the destination server, no matter which password mode the MLE is using.
The mode 2 und 3 are actually the safest way for authentication, because even if someone listens to the internet traffic, the password can't be reused later. In this case the password is bound to the dynamic key and therefore only valid for the current session.
Note: To use the mode 2 und 3 you have to use the MLE Gateway Server (see the additional HTTP-headers for details)! If you wan't to use a custom encryption of the password (on the client side of course) or if you want to know, how to set the authentication mode on the client, take a look at this page.
A complete authentication example can be found here.
Additional HTTP Headers:
The MLE sends additional HTTP headers only to platform servers. These headers are very useful to do further client customization. You can find the list here.
Things to take care of:
- Always set the "content-type"-response header (most web-servers set the content-type to "text/html" by default, this leads to errors on the MLE client! So if you transfer XML content set the content-type header to "text/xml".)
- Always set the "content-length"-response header
Example for PHP:
// output text $content= ....; // text data header('Content-Type: text/xml;charset=UTF-8'); header( 'Content-Length: ' . strlen( $content ) ); echo $content; // or for the output of an image $file = ....; // file URL header('Content-Type: image/png'); header( 'Content-Length: ' . filesize( $file ) ); $f = fopen($file,"rb"); fpassthru($f); fclose($f);
Multiple Platform servers:
You can use multiple platform servers on your client, here is a configuration example for three platform servers:
project.mlp.urls="http://localhost/mleserver/","http://localhost:8080/mobile/","http://elibera.com/testing/mleserver/" project.mlp.servernames="server","mlp","testing" project.mlp.servertypes=false,true,false
You distinguish between multiple platform servers by adding the servername to the link-type, for example:
<link type="m|server" url="pages/welcome.php" ... --> will access "http://localhost/mleserver/", whereas
<link type="m|mlp" url="pages/welcome.php" ... --> will access "http://localhost:8080/mobile/".
You just have to write the servername once. After you have accessed your platform server the first time you can use the normal link type="m", because the MLE connects than to the last used platform server.
Integrating the WYSIWYG-MLE-Editor in your platform:
The MLE- „What You See Is What You Get“ Editor allows the user to create MLE-XML documents without the need to know XML or the MLE-XML specification. It is a simply graphical editor to create documents with nearly every feature the MLE-XML specification offers. Even images and other binaries can be used (and uploaded) with this editor. The result of this editor is always a ZIP archive created after the content packaging specification.
Your platform must offer the required interfaces to the editor to load and store these ZIP packages. Furthermore your platform server must provide the logic to store the content on the server and to deliver it to the user (access-type for content packages is always the "content"-type!). How you integrate the MLE editor into your platform server you can find out here.
The matter of caching:
The MLE Gateway Server handles the HTTP-caching headers defined by the HTTP-standard. Furthermore there exists an additional HTTP-response header to tell the client to cache this response for the rest of the session. Just set the response header "MLIBERA_CACHE" to the value "true".