Finding out how to embed a Java applet in current major browsers is quite a task. Lots of pages still suggest using the <applet> tag and describe how to use the mayscript attribute to allow communication between Java and JavaScript. Other pages recommend using this mysterious mayscript attribute even in <embed> and <object> tags. I think there is a lot of voodoo out there, attributes which sound important but are not necessary at all...

So I started studying this stuff by myself. My goal was embedding a Java applet on a page which must work in Internet Explorer 7+, Google Chrome, Firefox, Opera and Safari. The applet must receive an applet parameter and must communicate with JavaScript in both directions.

Today I finished moving the main batch of old projects from my own server to Github: ThreeDee (JavaScript), ThreeDee (Java), Jollada, GraMath, Scilter, crypt4j, Pherialize, JSP Math Taglib, Supervise Tools, Wasteland Suite, wludata

Some of these projects are pretty old but I think they are still worth keeping. Some other projects went to /dev/null instead because I couldn't find any reason why they should waste space on any server. For the projects which had web pages here on Ailis I configured permanent redirects so old external links may still work for some time.

I just finished publishing TwoDee, a small, fast and simple 2D scene graph vector engine for JavaScript based on the HTML 5 canvas technology. This is the library used in my WebOS game Destroids which earned me $10,000 in one of the Palm Hot Apps Contests last year.

WebOS (The operating system of the Palm Pre and Palm Pixi phones) has a built-in messaging application but unfortunately it only supports Google Talk and AIM out of the box. It's a shame that Palm has not enabled more protocols and especially generic XMPP support. The used library (libpurple) supports everything so it's only missing in the GUI.

Google Talk uses XMPP so in theory it should work with any other XMPP server but unfortunately Palm has put this nasty code in the LibpurpleAdapter (which is used as a connector between the GUI and the low-level libpurple):

if (strcmp(prplProtocolId, "prpl-jabber") == 0
    && g_str_has_suffix(transportFriendlyUserName, "@gmail.com") == FALSE
    && g_str_has_suffix(transportFriendlyUserName, "@googlemail.com") == FALSE)
{
    // Special case for gmail... don't try to connect to mydomain.com if the
    // username is me@mydomain.com. They might not have
    // setup the SRV record. Always connect to gmail. 
    purple_account_set_string(account, "connect_server", "talk.google.com");
}

This code means: If the protocol is Jabber (XMPP) and the entered username does NOT end with @gmail.com or @googlemail.com then the XMPP server is hardcoded to talk.google.com. So if you enter a username like johndoe@jabber.org then the Messaging app does not connect to jabber.org but instead it connects to talk.google.com because of the above code. So we must get rid of this code somehow.

With some knowledge about assembler you might be able to toggle some logic in the binary so the above if statement always evaluates to false but there is a much easier solution. You just need to replace the string "connect_server" with some invalid string. I use "nonnect_server". The result is that the line simply sets some unused property and therefore simply does nothing.

Since WebOS 2 the LibpurpleAdapter program is renamed to imlibpurpletransport. In the following step-by-step instructions I will mention both variants for WebOS 1 and WebOS 2.

fail2ban is a software which can be used to monitor service log files and ban IP addresses which executed a brute force attack or tried to use the mail server as a spam relay. In the default configuration in Debian GNU/Linux only SSH login attempts are monitored which works pretty nice. But when you try to add more services then you may run into the problem that fail2ban no longer starts up correctly. The log file contains errors like this:

fail2ban.actions.action: ERROR  iptables -N fail2ban-ssh
iptables -A fail2ban-ssh -j RETURN
iptables -I INPUT -p tcp -m multiport --dports ssh -j fail2ban-ssh returned 200

I searched on the net but only found more victims of this problem, no solution. So I analyzed what was going on here and I finally figured it out.