So what’s the problem with that, you think? The problem is that almost all Flash applications can be hacked very easily and most developers are not aware of that.

As a reminder of how vulnerable Flash applications are, this post aims to raise awareness for these issues. In a case study, it shows how a Flash-based game and its server side high score can be tricked within a few minutes using free tools only.

Disclaimer

This post is meant to raise awareness for the vulnerabilities of Flash-based applications. It is not a hacking tutorial or how-to. For that reason, I will not describe all steps in great detail, but only sketch the basic steps.

1. Introduction

1.1. The problem with Flash applications

Flash applications are similar to normal Windows/Linux executables: Like normal programs, their source code is compiled to a binary format and later executed on the client machine. The major difference to .exe or Linux binaries is that decompiling is a lot easier: while a C or C++ compiler translates the source code into machine code, i.e. CPU instructions, SWF files contain the ActionScript code in plain text. That is with the right tools, extracting the complete code is a no-brainer!

Combining this with the fact that sniffing into the client-server communication is also not the most difficult task, one can easily simulate the Flash client with own code snippets and scripts, and thereby send forged requests to the server.

1.2. Checksums as a solution?

Most application developers at least know that the client-server communication can be sniffed into. As an attempt to make it more difficult for people to send forged requests to the server, applications mostly use a message authentication code (MAC) or some other checksum-based mechanism. So instead of sending a plain text update query to the server (1), the application creates a hash by concatenating the user input with (to the user unknown) other data (2):

This mechanism is completely based on the fact that the user does not know how the checksum is created. While this approach is very effective in regular applications, it completely fails in Flash programs: disassembling a Windows or Linux binary is very difficult and requires know how in assembler. Decompiling SWF files, however, is fairly easy and can be done in under a minute. That is retrieving the code that generates the checksum is only a matter of seconds.

1.3. Tools and basic approach

The following steps present a generic approach on how any Flash application can be exploited like described above.

Required Tools:

• Firebug: Firefox plugin for basic communication sniffing
• Sothink Flash Decompiler: required to extract ActionScript code (trial version is sufficient)
• Wireshark: required for detailed communication sniffing (byte-for-byte)

Generic Approach:

1. Enable Firebug and start sniffing with Wireshark.
2. Go to the target web site and play the game or use the application.
3. Look at the communication of the Flash application with the server. If there are any parts of the requests that cannot be recreated without the source code, e.g. checksums, download the important SWF files and decompile them.
4. Analyze the ActionScript code and find the part which creates the checksum.
5. Make a script that generates the same request with arbitrary input data, e.g. any score or name. For this script, the checksum algorithm from the ActionScript code can be used (or recreated).

2. Case study: a car parking game (with high score)

Our local newspaper Mannheimer Morgen recently hosted a competition in which users had to park a (virtual) car into different parking spots without damaging the car and with minimal fuel usage. Prizes were a safety training and concert tickets. While in this case the score of the participants did not decide who won (winners were drawn by lot), the winner in other competitions might be the one with the best score. Please note that I did not take part in this competition and I did under no circumstances try to win the prizes.

Parking Game: The target application in this case is a game called “Parking”.

2.1. Capture the client-server communication

Following the instructions from above, the first step is to capture the communication between the Flash client and the server. In this case, we are particularly interested in how to add our name with an arbitrary score to the high score list.

Firebug:
Using Firebug, we can see three interesting requests:

• savescore.swf is the part of the client that is responsible for sending the score to the server.
• serverdate-read.php is called by savescore.swf for no obvious reason – very suspicious. We will later see that the result is used in the checksum generation.
• highscore-write.php is also called by savescore.swf and actually writes the user’s score to the database on the server.

Firebug identifies the interesting files and requests.
In this case, three requests are relevant for the high score forgery.

What is particularly important is the two parameters __ctrl and controlvalue. Both are obviously generated by some checksum function in the savescore.swf-file. So the next step is to decompile the SWF file and look for the checksum-generating function.

Wireshark:
If we additionally enable Wireshark, we can get a plain text (or hex) representation of the HTTP request-response cycle. That is particularly important if one wants to forge a request in a way that it cannot be detected by the server.

2.2. Decompile the SWF file and find the checksum algorithm

Using the SWF Decompiler software (trial version is sufficient), the savescore.swf can be examined very closely. Most of the applications are not very complex and the relevant code pieces are found very easily.

When analyzing savescore.swf, the two parts in which the checksums are created are found at different positions in the file. The __ctrl parameter is generated by taking a MD5 hash over the two concatenated values of score and email. The controlvalue parameter is created in a similar fashion and involves the previously queried serverdate.

The __ctrl parameter is a hash value over two of the variable input parameters.
The controlvalue parameter is created similarly.

2.3. Write a script

Once it is clear how the checksums are generated, the puzzle is solved. The only thing left is to write a script that allows entering arbitrary input values, and using the previously determined checksum-mechanisms to generate a MAC.

Here is a short excerpt of how this could look like (using PHP):

$score = "999.999";
$email = "nobody@example.com";
 
$data = array(
	"__ctrl" => md5($score.$email), 
	...
	"score" => $score,
	"controlvalue" => md5(...), 
	...
);
 
foreach($data as $k=>$v) 
	$data_enc[] = urlencode($k)."=".urlencode($v);
 
$req = "POST /parking/highscore-write.php HTTP/1.1\r\n"
     . "Host: www.morgenweb.de\r\n"
     ...
     . join("&",$data_enc);
 
$fp = fsockopen("www.morgenweb.de", 80);
fwrite($fp, $req);
while ($line = fgets($fp)) { }	
fclose($fp);

3. Conclusion

This blog post introduced a common way to outsmart Flash applications and games. It demonstrated that by sniffing into client-server communication and decompiling SWF files, many Flash applications can be misused. Using the example of a Flash game, the post showed that SWF cannot be compared to Windows/Linux binaries, but must rather be seen as JavaScript-like client code.

Even though this post only demonstrated this using a rather harmless game, more serious misuse is also possible. Flash-based music streaming sites such as Simfy, Spotify Grooveshark are affected as well. They all use a similar mechanism for their Flash-based music player. Using the approach presented above combined with tools like rtmpdump can potentially harm their services significantly.

Flash once was a great way for bringing a little dynamic in the Web 1.0, but is no outdated. With various JavaScript frameworks and HTML5 on the way, Flash is going to retire soon. Developers and companies must be aware of the flaws of Flash and adjust their services accordingly to make sure that they cannot be misused.

But what happens if you accidentally commit a password or other sensitive information to a repository? This post explains how to remove this confidential data permanently from the repository by simply overwriting it in old revisions, i.e. without having to remove revisions or create a new repository.

1. Introduction

1.1. Disclaimer

The following actions might lead to data loss. I am not responsible for anything that goes wrong because of my description.

1.2. Requirements

It is absolutely necessary to have root access to the SVN respository. That is not only through the svnadmin command, but full command line access to the files, particularly to the “repos” directory.

If you do not have root access to the repository, you cannot remove any data from the repository! In that case, contact your SVN administrator.

1.3. Example Scenario

For this example, let’s assume you accidentally committed the file config.cfg with a plain text password 123secret a while ago (in revision 12). The repository is currently at revision 25 and you just realized that the password was in there all the time:

# Config file "config.cfg"
username = someone
password = 123secret
...

2. Local machine: Identify the affected revisions in the working copy

2.1. Fix and commit the affected file

The following commands are performed on your local machine within the working copy of the project, i.e. on the client machine.

Before we start tinkering and forging the SVN history and its repository, first fix the affected file and commit a new revision to the repository. In most cases, people are not going to look in old revisions of a config file, so the faster you commit a new version, the less likely it is that someone sees it!

$ cd ~/Dev/yourproject
$ vi config.cfg
# Change password to something else
$ svn commit -m "config update"
...
Transmitting file data .
Committed revision 26.

2.2. Identify the affected file versions locally

In most cases you will probably realize right away that you just committed something confidential to the SVN repository. In this case, you only have to fix one single version of that file and is pretty clear which revision is affected.

In other cases, however, the affected file might be in the repository for many revisions before you realize it. If this is the case, there might be multiple revisions of the file in the repository and each of these versions needs to be fixed. To identify the possibly affected versions of the file, you can peak into the logs:

$ svn log config.cfg
------------------------------------------------------------------------
r22 | someone | 2011-01-25 01:36:12 +0100 (Tue, 25 Jan 2011) | 1 line
 
update xy config
------------------------------------------------------------------------
r12 | someone | 2011-01-05 00:45:19 +0100 (Wed, 05 Jan 2011) | 1 line
 
added connection details to config
------------------------------------------------------------------------
...

In this case, the file has been altered in the two revisions 12 and 22. Both might include the password and are stored in the repository, i.e. both potentially need to be corrected.

2.3. Get MD5 checksums of the affected versions

SVN ensures the integrity of its repository by saving MD5 checksums of all the files and its versions. Since it is now clear which revisions might be affected, you need to get the current checksums of these file versions and calculate checksums for the new corrected (“forged”) versions. In short, you need to do the following for each affected version:

• Retrieve the version and calculate its MD5 checksum
• Make a copy of file, replace the confidential information with “x”s and calculate the MD5 checksum of the new file.
• Remember or copy all the checksums and versions into a file.

In this example, we’ll have to get the checksums for revisions 12 and 22 of the config.cfg-file. The code below only shows what to do for revision 22; revision 12 is analogue:

# Get current checksum of revision 22
$ svn --revision 22 config.cfg
...
At revision 22.
$ md5sum config.cfg
0e28c6c8342649c290400567130f657b  config.cfg
 
# Correct the file and get new checksum
$ cp config.cfg /tmp/config.cfg-22
$ vi /tmp/config.cfg-22
# Overwrite the password with "xxxxxxxxx" (same length as the old password!!)
$ md5sum /tmp/config.cfg-22
459a78e2eae02b28f810f9fdebdc5b52  /tmp/config.cfg-22
 
# Repeat this for revision 12

3. SVN repository: Correct the affected files

In this step, we finally start altering the repository. All the actions are performed on the server machine as root user inside the actual SVN repository directory, so be sure not to confuse it with you local machine.

3.1. Make a repository backup

Creating some sort of backup is crucial, since we are about to change the binary revision files of the Subversion repository. The easiest way to do this is to backup the whole repository folder of your project, e.g. /path/to/svn/repos/yourproject. However, if its total size is too big you can also choose to only backup the files identified in 3.2.

# Make backup of project; Note the "-a" parameter to keep the permissions.
$ mkdir /backups
$ cp -a /path/to/svn/repos/yourproject /backups

3.2. Verify affected versions

After the backup, we need to verify that we really need to change all the versions we identified earlier. To do that, navigate to the “revs” folder inside the repository and grep for the password:

$ cd /path/to/svn/repos/yourproject/db/revs/0
$ grep 123secret *
Binary file 12 matches
Binary file 22 matches

The matching files are the revisions that contain the password, and hence also the files that need to be “corrected”. Note that sometimes not all the versions identified through the “svn log” command appear in this list. That is because when the file is simply moved and not changed or other parts of it were altered, its contents will not be stored in the SVN revision file.

3.3. Replace the password and checksums

Since the SVN revision files are binary, we need a hex editor to edit them. Hence install hexedit, and then simply replace the password and checksums like identified before:

$ apt-get install hexedit
 
$ hexedit 22
# Hex editor opens the file for revision 22
# Replace passwords and checksums
 
# Repeat this for revision 12

Hexedit is not the easiest editor to use. So here is a step-by-step of what you need to do:

• Hit TAB, then CTRL-S to search
• Enter the password 123secret and hit return
• Overwrite the password with xxxxxxxxx (same length!)
• Hit CTRL-S, then “Y” to save
• Repeat 1-4 for each occurance of the password.
• Do the same for the old checksum “0e28c6c8342649c290400567130f657b”, and replace it with the new one “f85abfd8b63fa7ab68abc9364f2d339e”
• Hit CTRL-X to quit
• Repeat this for all affected revisions

That’s the complete magic. If checked out, the revisions 12 and 22 (and of course also their succeeding versions) will show xxxxxxxxx instead of the initially committed password.

4. Test locally

Now test locally if you can switch between revisions and every works without error messages:

$ svn --revision 12 update
...
At revision 12.
$ grep password config.cfg
password = xxxxxxxxx

If you did everything as the tutorial says, you shouldn’t get any errors. If you forgot to replace checksums or you changed something that you weren’t supposed to change in the SVN revision file, you might get an error like below. However, if that happens, you can always go back to your backup and try it again…

$ svn --revision 12 update
svn: Checksum mismatch while reading representation:
   expected:  f85abfd8b63fa7ab68abc9364f2d339e
     actual:  de6f581d115197baebc43c3975b9e396

5. Bash history cleanup

In step 3.2. we typed the plain text password in the bash. As you might know, this leaves traces in the ~/.bash_history file. Delete them by opening the files and then by simply removing the according lines. Make sure that you do not use the search function of VIM, since that has a history on its own. If you do, delete the history of VIM in ~/.viminfo.

$ vi ~/.bash_history
# Remove everything that contains the password
# Do NOT use the search function, but search manually!

For developers, context-awareness can be both a blessing and a curse. While the mobile operating systems iPhone OS and Android come with relatively good sensor-support, the vast majority of devices deal with Java ME’s basic and heterogeneous sensor functionalities.

The Aware Context API (ACAPI) aims to bridge this gap by providing a framework for building context aware applications for mobile devices based on Java ME. In this article, I’d like to introduce ACAPI, its structure and usage briefly. Please feel free to comment.

1. Motivation and Goals

ACAPI is designed to allow easy and homogeneous access to the different sensors of the mobile device. It creates an abstraction between the available sensors and their usage so that developers can focus on the business logic rather than on how to use the sensor implementations.

Example: A mobile application shall notify the user if another (previously defined) person comes into his or her range, e.g. if the boss arrives at the office.

Using the standard Java ME interfaces, developers have to get to know the different APIs and write a lot of code to solve this or similar problems. In this use case, the application needs to determine its position (the office), monitor the available devices around it (the phone of the boss) and be able to notify the user when both events occur.

The Aware Context API aims to solve this reoccurring problem with an easy-to-use event-based framework that allows defining rules for available sensor data. Using ACAPI, the given example can be solved easily by defining a rule and an action that is triggered when the rule matches:

• Rule: Wi-Fi “OfficeWLAN” available AND Bluetooth device “BossPhone” available
• Action: Notify user, e.g. by playing a sound

2. Development Team and Scope

The ACAPI project was developed within the scope of a team project as part of the curriculum of a Master of Science Degree at the University of Mannheim. The project was a team-effort, carried out over a 1-year duration at the Chair of Business Administration and Information Systems, under the supervision of Prof. Armin Heinzl and his research assistants Erik Hemmer and Sebastian Stuckenberg.

The project team consisted of Lars Bakker, Philipp Heckel (myself), Obie Modisane, Benjamin Schubert and Moritz Wächter.

3. Aware Context API (ACAPI)

The Aware Context API is well-structured and is very easy to understand. It is easily extendible and supports a broad range of devices. It is mainly based on Java ME, but has native parts whenever needed (e.g. for Wi-Fi, battery or telephony).

3.1. ACAPI Structure

ACAPI is horizontally structured into 3 different layers:

• Sensor: On the lowest level, the sensors gather data about the current status and context of the phone. A Wi-Fi sensor, for instance, collects available devices and it issues an event whenever the data changes. Applications can either hook themselves directly into the sensor events or use higher abstractions (conditions and rules).
• Condition: In order to evaluate a single sensor, conditions compare the sensor’s properties to given values. They can become either true or false. A location condition, for example, becomes true if the phone gets into the range of certain coordinates. Similar to a sensor, a condition issues an event when the value changes (from true to false, or vice versa).
• Rule: To express more than one condition, rules can combine conditions to a more complex logical expression. In the above example, the rule only matches if both conditions match (“in the office” and “boss phone available”).

ACAPI Structure (simplified and incomplete!): The Aware Context API is layer-based. Each of the components is easily extendible and has event listeners to react on changes. This chart shows the interdependence of the different layers.

Using this layered structure, ACAPI fundamentally changes the development strategy of mobile applications. Instead of predefining a screen and/or process flow, applications are event-driven. Whenever a rule changes its state (match vs. no match), the application can react by displaying a different screen, notifying the user, or by performing other actions.

Besides the horizontal division, the API is also vertically divided in the two logical parts Boolean and Fuzzy. While the Boolean part assumes correct sensors, the Fuzzy conditions and rules take measurement errors and inaccuracy into account. While the Boolean conditions and rules can only become true or false, their Fuzzy counterparts implement a score-based system that only triggers when a certain threshold is reached. This is particularly relevant for sensors that supply accuracy data, e.g. GPS sensors.

3.2. Implemented Sensors

The current code base of ACAPI includes several predefined sensors, including the most common: Bluetooth and GPS. Most sensors are entirely based on Java ME and will work on any phone that supports the corresponding JSR. However, since Java ME does not provide access to some functionalities, a few native implementations are required (e.g. for Wi-Fi, battery status or telephony status).

The following sensors are already implemented:

• Battery Sensor (native S60): This sensor monitors the status of the battery (%) and the charger (enum value, e.g. on-battery, or plugged-in). There is currently only a Symbian S60 implementation for this sensor since Java ME does not allow access to the battery data.
• Bluetooth Sensor: This sensor monitors available devices, e.g. phones or laptops. It can react on joining or leaving devices.
• Custom Sensor: This sensor allows the integration of business logic in ACAPI, so that rules do not only include actual sensor data, but also virtual business sensor data.
• Location Sensor (GPS and Wi-Fi; partially native S60): This sensor monitors the position and the speed. It uses GPS and Wi-Fi triangulation to get a fast and accurate position. Since Java ME does not allow access to the wireless sensor, the Wi-Fi part is native S60 code.
• Noise Level Sensor: This sensor monitors the noise level (in decibels) of the surrounding area.
• Time Sensor: This sensor delivers the current time and can react on date and time changes.
• Wireless Sensor (native S60): This sensor monitors the available Wi-Fi devices, i.e. access points. It can react on joining and leaving devices. In combination with a web service, it can be used to estimate the position.

There are many other possible sensors that could be implemented using the available abstract classes. Examples include an orientation sensor (react on device movement) or a telephony sensor (react on calls, SMS etc.).

4. Example Usage

Having discussed the structure of the Aware Context API, the following section elaborates the above-mentioned example even further. It explains the scenario and shows specific example code.

4.1. Example Scenario and Code

As already briefly mentioned above, the example scenario for demonstrating the API is very simple: The application shall display a warning message and play a warning sound when the boss arrives at the office.

The two conditions depicted in the diagram above are combined in one Boolean rule, i.e. the rule only becomes true if both of the conditions match.

Similar to the API concept, its actual usage is also very simple. The following code snippet shows how to implement the above example in a regular Java ME application.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

// Conditions
Condition inOffice = new WirelessNearCondition("OfficeWLAN");
Condition bossPhone = new BluetoothNearCondition("BossPhone");
 
// The two conditions create one rule
Rule bossDetectionRule = new BooleanRule();
bossDetectionRule.addCondition(inOffice);
bossDetectionRule.addCondition(bossPhone);
 
// React when the rule matches
bossDetectionRule.addRuleListener(new RuleListener() {
   public void ruleChanged(Rule rule, boolean matches) {
     if (matches) {
        playWarningSound();
        displayWarningMessage("Warning: boss has arrived!");
     }
}});
 
// Activate rule
bossDetectionRule.setActive(true);

In lines 2-3, the specific conditions are created. Since both conditions represent very generic cases (Bluetooth/WLAN device in range), ACAPI provides predefined conditions for them. In cases where more complex tests are desired, conditions can be extended via simple Java inheritance. Lines 6-8 combine the two conditions to a single Boolean rule, i.e. a rule that becomes either true or false depending on the status of its conditions. Since the application is supposed to react on changes in this particular rule, it registers itself as a listener in lines 11-17. When the rule is activated (line 20), it tells its conditions to register themselves at the corresponding sensors, which in turn get activated (if not already running). After this initialization, ACAPI notifies all registered listeners whenever the rule changes.

Depending on the status of the rules and conditions, i.e. on the device context, the application can change its appearance, behavior or internal state. In this case, it only plays a warning sound and displays a warning message (lines 14-15).

4.2. Proof-of-Concept Application

In order to test the implemented sensors and the rules engine of ACAPI, we developed a proof-of-concept application that implements a more sophisticated context driven use case.

A field service automation application that reacts upon the context the worker is in at the moment. This can be nicely done with the ACAPI and has a value for businesses. However, as this part of our project is not open source, I will not go into more detail here.

5. Future Work and Conclusion

The Aware Context API provides a framework for building context-aware applications for mobile devices based on Java ME. By providing uniform interfaces to different sensors, the library allows the development of context-driven applications.

The idea and structure of ACAPI are very solid, however, the actual implementation is in a very early development stage. While most sensors and Boolean conditions/rules are already working on the test devices, the Fuzzy conditions and rules are yet to be implemented. The native part only covers Symbian S60 so far and lacks of stability. Hence, the future work will include the implementation of missing parts, testing as well as the documentation.

A. Download and License

ACAPI will be released as open source, possibly under GPL or a Creative Commons license. Since we have not finished cleaning up the code and commenting everything, the code is not available for download as yet.

However, since it will be open source anyway, I will give out the code upon request.

The Kademlia Protocol

Kademlia is based on four simple remote procedure calls (RPCs) and guarantees a very fast and lightweight exchange of information by using the connection-less UDP instead of TCP. Every node as well as every entry of the DHT is tagged with an identifier, called node ID or key. By XORing identifiers, one can calculate the distance between them and is hence able to walk through the network knowing whether one is near or far to a specific node. This so called XOR metric makes it possible to group the entries of the DHT around the K closest nodes to the entry’s key. An entry with the key 10, for instance, will be stored at the nodes with a node ID close to 10.

Kademlia + PKI = KadS: The Secure Extension

In my Bachelor thesis, I am going to extend Kademlia from a simple peer-to-peer protocol to a trusted and secure network. The proposed KadS network is almost identical to the Kademlia network, i.e. it consists of the described RPCs and implements the same XOR metric. The major extension to the protocol is that every node is equipped with a public/private key-pair signed by a trusted CA. This extends the normal Kademlia network to a public key infrastructure (PKI) in which every communication is encrypted, every node can be trusted and only verified nodes can participate in the network.

Every connection is synchronously encrypted with a session key which is created and exchanged in a handshake procedure when two nodes first meet. That is, a node has a different session key for the connection with each node it knows in the network. The handshake is similar to the one used in other software except for the fact that both clients exchange their public key and need to verify each others identity. After a successful handshake, two nodes are able to exchange lightweight encrypted messages using the session key and the basic protocol applies

An application: The distributed URL blacklisting service

As an application to the proposed KadS network, I chose a distributed URL blacklisting service. Please read more in my Bachelor thesis exposé, or simply download the whole thesis:

Blacklisting Malicious Web Sites using a Secure Version of the DHT Protocol Kademlia.

For the customer interface of Silversun, I wanted to use RC as the internal web mail application and therefore had to embed it into my system. To avoid that the customer has to log in twice (customer interface and Roundcube), I had to simulate the login request with a PHP script.

Updates

November 2008: After the comment of Matias, I reviewed the code and fixed some issues. Now it should work properly even with the newest Roundcube version (0.2-beta). The class file itself contains installation instructions. Please read them carefully.

March 2009: Just tested the script with version 0.2.1 and it works like a charm, at least for my installation.

December 2009: Diego just confirmed (via e-mail) that the script also works for 0.3.1 without modification.

May 2010: I just tested the scripts with Roundcube 0.4-beta, and it still works without modification. I also added the section Debugging make it easier to figure out what’s wrong.

March 2011: After Alex’ comment, I adjusted a small part of the script. It should now also work with Roundcube 0.5.1. It now handles the new request token correctly. The pre-0.5.1 script is still available for download here: RoundcubeLogin.pre-0.5.1.class.php

Prepare RC

To perform the Roundcube login via a web site, it is necessary to turn off the check_ip/ip_check option in the main.inc.php file, because our script (= server IP address) will send the login data and pass it to RC instead of the user’s browser (= user IP address).

The RoundcubeLogin class

This small class only consists of four functions and it shouldn’t be necessary to modify it in order to get the login to work.

• RoundcubeLogin.class.php
  Provides the functionality to login, logout and check the login status.
• rclogin.php
  A small script to test if everything works as expected.

The class provides four public methods:

• login($username, $password)
  Perform a login to the Roundcube mail system.
  Note: If the client is already logged in, the script will re-login the user (logout/login). To prevent this behaviour, use the isLoggedIn()-function.
  Returns: TRUE if the login suceeds, FALSE if the user/pass-combination is wrong
  Throws: May throw a RoundcubeLoginException if Roundcube sends an unexpected answer (that might happen if a new Roundcube version behaves differently)
• isLoggedIn()
  Checks whether the client/browser is logged in and has a valid Roundcube session.
  Returns: TRUE if the user is logged in, FALSE otherwise.
  Throws: May also throw a RoundcubeLoginException (see above).
• logout()
  Performs a logout on the current Roundcube session.
  Returns: TRUE if the logout was a success, FALSE otherwise.
  Throws: May also throw a RoundcubeLoginException (see above).
• redirect()
  Simply redirects to Roundcube.

Sample usage

The script below demonstrates how the class can be used. If the client is already logged in, it simply redirects the browser to the Roundcube application. If not, it performs a login and then redirects to Roundcube.

<?php
 
include "RoundcubeLogin.class.php";	
 
# Create RC login object.
# Note: The first parameter is the URL-path of the RC inst.,
#       NOT the file-system path
# e.g. http://host.com/path/to/roundcube/ --> "/path/to/roundcube"
$rcl = new RoundcubeLogin("/roundcube/", $debug);
 
try {
   # If we are already logged in, simply redirect
   if ($rcl->isLoggedIn())
      $rcl->redirect();
 
   # If not, try to login and simply redirect on success
   $rcl->login("some-email-address", "plain-text-password");
 
   if ($rcl->isLoggedIn())
      $rcl->redirect();
 
   # If the login fails, display an error message
   die("ERROR: Login failed due to a wrong user/pass combination.");
}
catch (RoundcubeLoginException $ex) {
   echo "ERROR: Technical problem, ".$ex->getMessage();
   $rcl->dumpDebugStack(); exit;
}
 
?>

Debugging

If you’re having problems with the RoundcubeLogin.class.php class itself, try using the rclogin.php-file for debugging: open the file in your browser (http://myhost/roundcube/rclogin.php), and take a look at the output. The RoundcubeLogin-class performs a series of request/response cycles and parses the output to figure out if you’re logged in.

Known issues:

1. No Roundcube installation found at ‘…’
   This error message is thrown if the path-value in the RoundcubeLogin constructur was not set correctly. It must be set to the part of the URL that represents the path, e.g. in case of http://myhost/roundcube/ you must create the object like this:

   $rcl = new RoundcubeLogin("/roundcube/");

2. Unable to determine login-status due to technical problems.
   This error can occur in the methods login(), logout() and isLoggedIn(). The RoundcubeLogin-class expects Roundcube to send certain headers in response to the login/logout-requests. If those headers could not be found, this error is thrown. Possible reasons are:
   • New RC version
   • Cookies must be enabled
   • ip_check/check_ip option in the main.inc.php must be false
3. Unable to determine the login status. Unable to continue due to technical problems.
   This error occurs if the script cannot determine if you are logged in or not, because the returned HTML code neither contains the login-form (= logged out) nor the message DIV (= logged in). This might happen if Roundcube changed the HTML-code.

I’m open for suggestions

Please feel free to post your comment or suggestions. That’s the only way to ensure that it works with all versions.