I’ve been writing an API for a little project I’ve been working on for a while, and in searching for a not-horrible way to do OAuth1 authentication, I actually found a Python library that doesn’t suck.

Of course, it’s not perfect. I noticed today that it doesn’t actually handle HTTP error responses - it doesn’t even check the return code at all, just assumes that any response it’s given will be parseable. Which of course is not at all true in many cases - including in mine.

So of course I’ve forked it and am working on a fix.

Found another bug and made a pull request - this time in the ‘rauth’ library, which does OAuth in a reasonable sane way.

Except for this issue - I still have no idea why they’re trying to parse the OAuth response with a utility used for parsing HTTP requests, but hey, I guess if it works for them, fine. For me though, I need to replace their use of parse_utf8_qsl(s) with json.loads(s.decode()) because my response is proper JSON - shouldn’t OAuth responses be JSON anyway?

Whatever, it’s late.

EDIT: Okay so it turns out I was doing silly things like not reading the OAuth spec and the response should be a query-string type thing like oauth_token=foo&oauth_token_secret=bar instead, which is what the library parses just fine by default. Reading specs is a good plan, one I encourage everyone to do.

My pull request is still valid though, if you really must break the spec, they have the parser argument already, and it should work in a more sensible way.

Another bugfix for s3cmd.

Bugfix for s3cmd - some issues with command-line arguments not working when I needed them to.

Nearly 2 years to the day after I submitted this issue with the ‘draw9patch’ tool in the Android SDK to Google, the issue is still open.

I only mention this because it seems the owner of the ticket has changed today.

Way to go, Google.

Right so in the previous article I set up an IPSec VPN between Openswan and OpenBSD’s PF. The issue with it is that any time the OpenBSD end restarted, the Openswan end had no idea this occurred, and quit working with no notification of any sort. And just running ipsec auto --down $conn; ipsec auto --up $conn didn’t work, it actually created an additional flow and SAD on the OpenBSD side, and the tunnel wouldn’t become active.

So I’m going old-school. I’m going to write a stupid hacky script to ping the OpenBSD internal endpoint from the Openswan box, and when it goes unresponsive, run ipsec auto --replace $conn && ipsec auto --up $conn to bring the tunnel back up.

See? Openswan sucks.

Feel free, by the way, to prove otherwise.

I see the Google plus article format returned by their Python API has changed again. You will note the sidebar over on the right there only shows images and no articles now. I’m getting really tired of fixing this every month.

Probably I’ll just not bother soon, and remove that whole sidebar altogether.

There is a bug in nginx - patch your daemon or implement this workaround.

JWZ’s post today is awesome. I agree with him, far too many bugs are being ignored and that just sucks for us users. Especially when they get ignored for a very long time. When did we stop being good software engineers?

I use Finance::Currency::Convert::XE for the old perl version of an IRC bot, and recently xe.com updated their website, which broke XE.pm. This patch fixes it. XE.pm.diff

UPDATE: I submitted this as a bug, and it got merged into version 0.21:

bug #78433

I just whipped up a little multitouch bug tester program for Android. As noted in my previous post, lots of Android phones running 2.3.7 and earlier have buggy multitouch. In this example, I show the pointers (up to 5) with pointer numbers. You should be able to see at least two, and if the bug is not present, they should work properly. If you have the bug, you’ll notice 1 and 2 swapping back and forth as you touch 1, touch 2, lift 1, then tap 1.

Enjoy. multitouchbugtest.apk

This blog is really starting to seem like a rant about bugs. Today’s is dealing with multitouch on Android. My conclusions:

• Android 3.0+ handles multitouch almost perfectly, and supports multiple pointers. All devices I’ve tested have handled 4 pointers.
• Android 2.x (I’m testing with 2.3.5 and 2.3.7) sometimes works and sometimes doesn’t, it seems to depend on hardware.

I have a Motorola Droid2, some friends have T-Mobile G2’s, and another friend has a HTC Evo something-or-rather. The G2 works fine, but the Droid2 and Evo don’t.

I wrote a test program that tracks two simultaneous touches, and the location of them. In these logs, the pointer number should be the index number of the touch event, where “touch event” is defined as from the time you touch until you release all touches. In Android 3+, it correctly keeps track of up to 4 pointers (on my hardware anyway) correctly, such that the ids of the touches don’t change. These logs are from my Droid2. “left” and “right” are as reported by the X coordinate of the touch event. The boolean is my attempt to detect when we’re in “stupid mode” as I’ve been calling it.

1. I touch left, then tap right on and off:

D/GameView(29118): pointer 0 down false left
D/GameView(29118): pointer 1 down false right
D/GameView(29118): pointer 1 up false right
D/GameView(29118): pointer 1 down false right
D/GameView(29118): pointer 1 up false right
D/GameView(29118): all up false

2. I touch left, touch right, then release and tap the left pointer:

D/GameView(29772): pointer 0 down false left
D/GameView(29772): pointer 1 down false right
D/GameView(29772): pointer 0 up false left
D/GameView(29772): stupid mode enabled
D/GameView(29772): pointer 0 down true right
D/GameView(29772): pointer 1 up true left
D/GameView(29772): pointer 1 down true right
D/GameView(29772): pointer 0 up true left
D/GameView(29772): pointer 0 down true right
D/GameView(29772): pointer 1 up true left
D/GameView(29772): pointer 1 down true right
D/GameView(29772): pointer 0 up true left
D/GameView(29772): all up false

You will notice in #2 there that it gets confused as to which number pointer I’ve been tapping, and it even reports the coordinates of the other pointer in the ‘down’ event. This is “stupid mode” :) Since there are still so many 2.x devices, I now have to work around this somehow. Fun!

Since I seem to be logging my Google bug reports here, I’ll add one to the list. Android bug 25936 - “draw9patch should start file->open in the current directory, or the last used directory.”

Oddly enough, this bug was actually looked at the day after I submitted it, unlike most of my other bugs which seem to be completely ignored for months.