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.
February 27, 2014 @ 13:43
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.
- 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
- 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!
February 24, 2012 @ 16:12
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.