2 Nov 2004 pipeman   » (Journeyer)

Testing Advogato's XMLRPC interface

I am currently implementing a tiny SOAP middleware for a client, and while reading up on SOAP I realized that Advogato has some simple XML-RPC services. So using Apache XML-RPC, and a smallish Java hack, my homepage now includes the latest diary entry from Advogato. Sweet! This is how it works: the code checks if /tmp/diary.cache exists. If it doesn't, it sets off to asynchronously fetch the latest diary from Advogato, while displaying a short note informing the user that the data is unavailable and an auto-refresh Javascript snippet reloading the page after a few seconds. When the XML-RPC requests are completed, the diary entry is stored in that file, and upon subsequent requests to the home page, the code will simply include the HTML found in the cache file. Every once in a while, a cron job deletes the cache. This way, I don't have to poll Advogato needlesssly to see if there is new data; I will only make the request if someone actually access the page. Yes, there are probably some race conditions and such, but this was what I could wrap up while waiting for the coffee to finish. :-)
update: I noticed that the time from Advogato that my Java code printed out was in some weird time zone, and somewhat surprised assumed that my JSP container had a broken locale/time zone setup. So I went about to manually point it to the time zone I wanted to use, but that didn't help: the time stamps were still many hours apart from my own local clock (which is UTC+1). After checking into what was actually sent over the wire behind the scenes of my XML-RPC calls, I noticed that the ISO 8601 time stamps didn't contain any time zone data. The XML-RPC client thus assumed that the received dateTime.iso8601 strings (eg. 20041102T11:32:32) were in the local time zone of the client computer. Appearantly, they are not, but rather in what I assume is some US time such as EST. I guess I should point this out to raph or whoever it was that developed the XML-RPC backend for Advogato, as it would be very helpful for people in different time zones to know what offset the returned time has. My guess is that all that has to be done is adding something like "-0500" (or whatever timezone Advogato uses) to the iso8601 string in order to make it possible for the XML-RPC client to correctly translate into something like a timezone-neutral DateTime object.

Securing my WLAN, sort of

Earlier this year, my WLAN PC Card for my laptop broke, since hardware hates me. I had been using a D-Link WLAN card together with a combined D-Link firewall/NAT gateway/WLAN access point until then, and since I don't exactly live in a high tech area where war driving is common, I had settled on using the 256-bit WEP encryption that the D-Link hardware provided (however aware that WEP in general isn't secure all, it probably keeps my average neighbor from peeking into my network).

When faced with being WLAN-less, I got to borrow an old spare card from a friend. Tre problem was, that the card in question was a stoneage-ish Lucent WaveLAN Bronze - i.e., quite slow and no encryption. So I was forced to accept that my wireless network would be wide open to anyone (or buy a new network adapter, which would cost me at least ten beers and is thus out of the question). Also, when trying out my new-old WLAN card, I noticed that one of my neighbors, too, had set up a wireless access point. No encryption, but a very friendly DHCP server and all - I could use his/her AP for my Internet surfing with a few mouse clicks.

Anyway, so I set out to secure my network with the assumption that it was untrusted. I have briefly mentioned this before: the solution was found in OpenVPN. Set up was a breeze - I configured my (wired) desktop computer as a server and a new private RFC1918 subnet, and let it hand out IP dynamic adresses in that range to the clients. So with OpenVPN, I had a secure authenticated channel between the laptop and the desktop, regardless of whether I was using my unencrypted home WLAN or an office broadband connection (well, assuming a firewall in the way doesn't block UDP port 5000). The next step was to assure that no war driver could use my WLAN for sending spam. That was quite easy: on my NAT box, I can configure the built-in firewall rules quite flexibly (it's not iptables or pf, but hey, it works): I can configure the rules per interface (WAN or LAN), source and destination adress and ports, and finally IP protocol. The end result looked something like this:

  1. ALLOW from SERVER to ANY/ANY
  2. ALLOW from LAN to GATEWAY port 53/UDP
  3. ALLOW from ANY 0.0.0.0/0 TO SERVER port 5000/UDP
  4. DENY FROM ANY TO ANY

Here, SERVER represent IP adress of the desktop computer and LAN includes both WLAN and Ethernet interfaces. The packets that travel from the WLAN interface to the Ethernet network isn't filtered at all. Basically, I only allow DNS to the gateway (which includes a DNS relay) and UDP port 5000 to the OpenVPN server. This way, someone connecting to my WLAN may use DNS (and can potentially use that through IP over DNS, but if they go through that hassle, they're worth the few kbit/sec they can get from it), and can connect to my desktop computer (which hopefully is quite secured even though it's a Windows 2000 box), but they can't leech warez or send spam using my broadband connection. Meanwhile, I connect to the SOCKS proxy on the VPN interface on the server machine (the SOCKS software denies connections on other interfaces), and through that proxy connect to anywhere on the Internet, with OpenVPN protecting my privacy for the parts that are wireless.

As an extra bonus, I can let friends that I trust take part in my VPN if we want a secure way of sharing files via otherwise insecure means (such as SMB) - all they have to do is set up a minimal OpenVPN configuration and get me to sign their public key. Also, an added level of obscureness, my laptop now connects to my Waste network through the VPN via the Waste node running on my desktop computer. As a friend put it: you should PGP-encrypt some files written in pig latin before sending them over the Waste network running on top of the VPN to be really sure Echelon gets something to chew on. :-)

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!