Monthly Archives: April 2013

Two-legged OAuth between PHP and JIRA

If you want to use the JIRA REST API without storing plain-text passwords in your application, you need to use OAuth. If you want the application to directly talk to JIRA without binding it to a JIRA user account, you need to use 2-legged OAuth. JIRA requires RSA keys for 2-legged OAuth. Zend_OAuth supports RSA-signed requests, but this is somewhat undocumented. Also, the Java OAuth library used by JIRA appears to have a bug that requires the field oauth_token in the Authorization header to be present but blank for 2-legged authentication (if it’s not present, it raises uncaught exceptions…). Lastly, you have to use the exact server name that JIRA thinks it has. Finding out all this took me quite a while, so here is the full code:

PHP Code

require_once 'Zend/Oauth.php';
require_once 'Zend/Oauth/Consumer.php';
require_once 'Zend/Crypt/Rsa/Key/Private.php';
require_once 'Zend/Crypt/Rsa/Key/Public.php';
$jql = 'project = KB';
$max = 50;
$server = ''; // this must not be http://localhost:8080. It must match the proxyName, proxyPort and Context configured in ./conf/server.xml in JIRA. Otherwise you get signature_invalid exceptions
$query = array('jql' => $jql, 'startAt' => '0', 'maxResults' => $max, 'fields' => 'summary,assignee,duedate,priority')
$privkey = new Zend_Crypt_Rsa_Key_Private('jira.pem');
$pubkey = new Zend_Crypt_Rsa_Key_Public('');
$consumer = 'samplescript';
$query['oauth_token'] = ''; // otherwise you get uncaught net.oauth.OAuthProblemException: signature_invalid exceptions
$oauth_config = array(
 'consumerKey' => $consumer,
 'rsaPrivateKey' => $privkey,
 'rsaPublicKey' => $pubkey,
 'signatureMethod' => 'RSA-SHA1',
 'siteUrl' => $server . '/plugins/servlet/oauth',
 'requestScheme' => Zend_Oauth::REQUEST_SCHEME_QUERYSTRING,
$oauth = new Zend_Oauth_Consumer($oauth_config);
$token = new Zend_Oauth_Token_Access(); // 2-legged authentication doesn't use tokens, but this is the only way to get a HTTP Client that sets the proper Authorization headers
$client = $token->getHttpClient($oauth_config, $url);
$client->setUri(sprintf('%s/search', $url));
$json = json_decode($client->request()->getBody());

Generating the keys

openssl genrsa -out jira.pem 1024
openssl rsa -in jira.pem -pubout -out

Registering them with JIRA

Go to the JIRA Administration, click Plugins, then Application Links.

Click Add Application Link, enter your server URL, enter the name of your application and select Generic Application.

Now configure it: got to Incoming Authentication, set a Consumer Key (I used samplescript above), set a name and paste the contents of into the box. Now check 

JIRA OAuth configuration

OpenWRT hardware recommendation: TP-Link TL-WDR3600

I recently replaced my WiFi access point, an ancient Linksys WRT54G v3.1. I was looking for something that supported simultaneous dualband, multiple SSIDs, and VLANs. I also wanted something that could run OpenWRT.

I ended up buying the TP-Link TL-WDR3600 because it met all these criteria and was available for less than 50 €. After using it for a few months, I can definitely recommend it: The wireless coverage is good, it supports Multi-SSID just fine, and the internal switch is fully VLAN-capable (and easy to configure using the OpenWRT LuCI web interface).

My only complaint is that in the 5 GHz band (5150 MHz – 5250 MHz), OpenWRT limits me to 50 mW of output power (the Linux kernel has a limit of 100 mW), even though I could legally run up to 200 mW. These lowest four channels of the 5 GHz Wifi band don’t even require TPC (transmission power control) or DFS (radar detection) in Germany, making the limitation completely unnecessary.

The TL-WDR3500, TL-WDR4300 and TL-WDR4310 are identical to the TL-WDR3600 save the radio module, so the instructions here should apply to them as well.

Here’s a short how-to on getting started with OpenWRT on the WDR3600:

Installing OpenWRT

Hook up your computer to an Ethernet port on the WDR3600.

Download openwrt-ar71xx-generic-tl-wdr3600-v1-squashfs-factory.bin and upload it using the factory web interface at (do not rename the file or it might not update).

After it reboots, renew your DHCP lease (OpenWRT uses a different subnet by default) and telnet There, run passwd to set a password, then hit Ctrl-D to disconnect. Now you can ssh root@

The first thing to do is backup the bootloader and ART partition, just in case:
dd if=/dev/$(grep '"art"' /proc/mtd | cut -c 1-4) of=/tmp/art.backup
dd if=/dev/$(grep '"u-boot"' /proc/mtd | cut -c 1-4) of=/tmp/u-boot.backup

Now you can scp root@*.backup ~/Desktop to get them off the device.

Next, install the web interface:
opkg update
opkg install luci
/etc/init.d/uhttpd enable
/etc/init.d/uhttpd start

Now you can easily configure everything the way you want it (but please don’t ask questions in the comments about the specific configuration: the OpenWRT forums are a much better place for that).

Upgrading OpenWRT

cd /tmp
md5sum openwrt-ar71xx-generic-tl-wdr3600-v1-squashfs-sysupgrade.bin
# compare it against

sysupgrade -v openwrt-ar71xx-generic-tl-wdr3600-v1-squashfs-sysupgrade.bin
The device will eventually reboot and come up with the new firmware. Your configuration should still be present.

Failsafe mode

If you’ve locked yourself out, it’s easy to get back in: unplug the device, plug it back in and as soon as one of the LEDs on the front starts flashing, push and hold the WDS button. Release it when that LED starts flashing a lot faster.

Now, set your computer to a static IP of 192.168.1.x with a subnet mask of and telnet Now you can reset your password (passwd), change configuration variables (uci), or do a factory reset (firstboot). When you’re done, reboot -f to return to the normal operation mode.


It is possible to brick your device with OpenWRT. All the commands above are provided without warranty, so use at your own risk; if you don’t know what your doing, don’t do it.

Also, it’s not that easy to get back to the original TP-Link firmware (which you would definitely need to to if you wanted to return the device to TP-Link for warranty repair.

Note that depending on local laws, flashing an alternative firmware may void your warranty altogether. Even if it does not, screwing up such a flash process yourself is sure to void the warranty anywhere…

Xserve RAID and Atto Thunderlink FC 1082 are incompatible if used without an FC switch

We’re running a 2006 Xserve RAID at the university. Our old server was a 2006 Xserve with an Apple 2 Gbit Fibre Channel card. When we recently got a new Mac mini server to replace, we ordered an Atto Thunderlink FC 1082 to interface with the RAID. The Promise SANLink would have been a possible alternative, but the Thunderlink is capable of 8 Gbit/s, thus future-proofing our investment.

Unfortunately, when I hooked up the Thunderlink straight to the Xserve RAID using an Apple Fibre Channel Copper Cable, neither the Xserve RAID Admin utility nor the Mac mini showed a connection. After some googling around, it appears as if the Xserve RAID is not capable of negotiating links with HBAs that are capable of more than 2 Gbit/s. Turns out also says that you shouldn’t use their 4 Gbit card with the Xserve RAID: HT1769.

Since the RAID has been working fine for quite a while with two HP servers running VMWare ESXi with Qlogic QLE2460 controllers connected through a Qlogic SANbox 5200 2 Gbit FC switch, and I knew the Thunderlink worked with that switch, I simply used an FC Copper Cable between the Thunderlink and the switch and one between the switch and the RAID, configured the zoning, et voilà, the array mounted on the Mac mini.