Categories

MSG Developer FAQ

  • What skills do I require before attempting to do my own MSG installation or development?
    A complete understanding of MSG client and server systems requires knowledge of a range of core technologies, including Java, Tomcat, Servlets, JSP, HTML, JavaScript, AJAX, Jabber/XMPP, JDBC, LDAP, Openfire/Wildfire API. As a developer, you may need a good understanding of all of these things, but for installation it may be sufficient to just have some experience of configuration of Tomcat and Openfire servers. Before starting we suggest that you familiarize yourself with at least these two systems, both of these are opensource projects that are freely downloadable from http://tomcat.apache.org/ and http://www.igniterealtime.org/
  • What is Openfire/Wildfire?
    This is a multi-platform open-source Jabber/XMPP server, written in Java. See http://www.igniterealtime.org/
  • What’s the difference between Openfire and Wildfire?
    Not much. Openfire is just the newer name for the product as of version 3.3
  • What is buddyxml?
    buddyxml is a servlet that maintains a persistent connection to a Jabber/XMPP server for each user that logs in. This connection is maintained within an Apache Tomcat session object created for each user. The third party API used for handling the jabber connection is called jabberbeans, but it could be adapted to a more recent API such as JiveSoftware’s Smack library.
  • What is session attachment & why do I need it?
    In a nutshell this means, the process whereby an existing tomcat session can be discovered and used without requiring a session token to be maintained by the web browser. Normally, a session is ‘in effect’ lost once the session token that refers to it is lost (e.g. by closing the web browser). Now, imagine the scenario where you have logged into MSG using your web browser, and then you login using the same username using MSGAlert. You might hope that the web browser window that opens when you click on MSGAlert was attached to the same jabber connection that was created by the earlier login. So, to achieve this, the second time you login, your credentials are checked without creating a jabber connection, and then it looks up in a table to see if there are any existing sessions that belong to your username. If it finds one, it returns its session token, otherwise it creates a new jabber connection and returns the current session token.
  • How does authentication work for session attachment?
    Session attachment requires user authentication without going through the user XMPP/Jabber connection process (because this would create multiple IM sessions and confusing presence change information for your contacts). So, we require a ‘back door’ route for checking credentials, and this is provided by a service within the Wildfire Mashup plugin that we developed for the purpose. The base URL of the service used to check credentials is configured in the ‘wildfire-authenticators’ parameter in the buddyxml web.xml file. This parameter should be a comma separated list of host/URL pairs. For example,
    msg.open.ac.uk@http://localhost:9090,msg.mydomain.org@https://msg.mydomain.org:9091
    This tells buddyxml to check credentials for users logging into msg.open.ac.uk, by using the mashup service located at the base URL http://localhost:9090
    We recommend using the secure https mode for URLS other than to localhost.
  • How do I enable SSL connection for Tomcat and Openfire?
    Look at:
    http://tomcat.apache.org/tomcat-5.0-doc/ssl-howto.html
    and
    http://www.igniterealtime.org/builds/wildfire/docs/latest/documentation/ssl-guide.html
    Note that if the SSL certificate you buy for your server is not trusted by one of the default Certificate Authorities (CA) that Java is configured to trust, you may also need to install the root and intermediate certificates into the keystore you are making, or add them to Java’s cacerts file.
  • How do I configure Openfire to allow connection to and adding contacts from other IM systems?
    You need to download and install the gateway plugin from http://www.igniterealtime.org/projects/openfire/plugins.jsp
    The binary version of this plugin seems to only be available for the most recent version of Openfire, however the sources are included with each source distribution of Openfire, so if you need an older version of the plugin, you may need to build it from sources. (Which is relatively simple using provided ANT build scripts)
  • How do I build Openfire from sources?
    Make sure you have ‘Apache Ant’ and Sun’s Java Developers Kit (JDK 1.5 or later) installed.
    Download sources for the most recent version from:
    http://www.igniterealtime.org/downloads/source.jsp
    Unpack the download, go to the ‘build’ folder.
    Build the core system by entering the command: ant
    Build the optional plugins by entering the command: ant plugins
    Results of the build are put in a folder called ‘target’
    For further info: http://www.igniterealtime.org/builds/openfire/docs/latest/documentation/source-build.html
  • How would I go about adding a new authentication system?
    Openfire provides a flexible system for overriding the default provision for authentication, users and groups.
    e.g. for authentication see:
    http://www.igniterealtime.org/…../auth/AuthProvider.html
    Basically, you just implement the interface AuthProvider, configure openfire.xml with the classname of your implementation, and put a jar file containing your java classes into Openfire's lib folder.
  • Why isn't the source code viewer at msg.open.ac.uk/sources up-to-date?
    This viewer is only kept up-to-date manually by synchronizing with the CVS repository.
    Please email kmi-msg@open.ac.uk (no longer available) to request a manual update of the 'sources/repository' folder. Or you can retrieve the live versions directly from CVS yourself.
  • How do I build MSG's Openfire plugins, userwebadmin and mashup?
    Download modules WildfireMashupPlugin and WildfireUserWebAdminPlugin from the CVS repository.
    Put the source code for the plugins in the same place as the optional plugins within the Openfire sources, then build Openfire as described above. Note that if you are building plugins for Openfire version 3.3 or later, you may need to change some of the package name import statements to reflect the name change from wildfire to openfire.
  • What does wildfire-extras.jar do, and why do I need it?
    This JAR file contains MSG's custom providers for authentication, users and groups. It allows multiple authentication methods (possibly different for each user). Currently supporting Local, LDAP, SAMS and Moodle.
    It enforces a single user connection policy which prevents the user confusion that sometimes arises when messages are dispatched to a user with multiple connections.
    It uses a technique whereby externally provided users and groups are replicated as local users and groups by using Openfire's API. This helps improve efficiency of the server and allows external changes in users or groups to be immediately propagated to connected clients. This is a significant improvement on the built-in LDAP provider, which will only propagate User and Group changes to clients once the Openfire's internal cache of those objects expire (6hrs!).
  • How do I build MSG's wildfire-extras.jar file?
    Download module WildfireExtras from the CVS repository, then build with your favourite Java IDE or JDK. The sources refer to the openfire API, so you will need to add the openfire.jar file as a dependency in your project. You will find that file (or openfire.jar) in the Openfires lib folder. Note that if you are building against openfire.jar, you will need to change some of the java import statements that refer to the older API package name.
  • How does Single-Sign-On (SSO) work with MSG?
    When MSG is integrated into a web system such as a Portal or Moodle, we need a way to validate the identity of the user at the MSG server. The current implementation of SSO for Moodle integration requires session tokens to be transferred via the password parameter when logging into the MSG Server. The identity of the user is extracted and validated by our customizations to the MSG Server. The MSG server does this by reconstructing the Moodle session cookies and making an HTTP request back to the Moodle server to retrieve the userโ€™s identity.
  • Why doesnโ€™t SSO work with Wildfire 3.2 or later?
    It does! But you need to make a small change to the Wildfire server code.
    As of Wildfire 3.2 the username of a user logging in must be passed to the server. However, in our implementation of SSO, the username is computed by the server by validating session tokens. The class that needs modification is org.jivesoftware.wildfire.session.ClientSession. Differences between the following two files show what may need modification for versions later than the currently supported one.
    ClientSession.java (no longer available)
    ClientSession.java.original (no longer available)