Look ma, no passwords!
Tags: 10.7, mercurial, python
Here’s a quick and easy way to handle authenticated Mercurial repositories on 10.6 and later. First, install the mercurial_keyring python package using pip as in `sudo pip install mercurial_keyring`. Then you can update ~/.hgrc as follows:
[ui] username = Foo Barred <[email protected]> [extensions] mercurial_keyring = [auth] foo.prefix = https://hg.bar.com foo.username = someusername
You’ll then have to enter the password one more time, but hg will then stop bothering you. However, if the authenticated Mercurial repository is also using an unverified certificate, then it’s a good idea to also execute the following commands so that you won’t have to stare at certificate warning messages from hg:
openssl req -new -x509 -extensions v3_ca -keyout /dev/null -out dummycert.pem -days 3650 sudo cp dummycert.pem /etc/hg-dummy-cert.pem
Once executed, add the following to the ~/.hgrc file:
[web] cacerts = /etc/hg-dummy-cert.pem
Environment
Tags: erlang, macosx, ssh
Really just a note to myself, but I bet someone else might run into this issue I had.
I’m revisiting the disco project, a nifty Python/erlang based map-reduce framework that I toyed with a few years back. It’s a few versions ahead now with many improvements and sporting a distributed key-value storage system. Alas, it wouldn’t run straight out of the box for me, failing to connect to an erlang instance. As it happened, erlang was installed using homebrew, which means the binary was not in a default path. Running a command using “ssh localhost“, as disco does, will bypass the user’s bash profile. Either you need to symlink the erl executable to /usr/bin/erl or you create an .ssh/environment file with a proper PATH definition (chmod 644). To get the latter to work, /etc/sshd_config must be edited so that the line containing “PermitUserEnvironment” is uncommented and set to ‘yes’.
Twitter, OAuth and iOS
Tags: cocoa, ios, oauth, twitter
Twitter used to make it easy for third-party developers to have users authorize apps. All they had to do was type in their name and password, then the app could exchange it for an access token in one go. They called it xAuth and it was provided, because the whole OAuth authentication flow was a bit of a pain if you weren’t a browser client. Recently, however, Twitter started to require OAuth if you want your users to read direct messages.
Converting your app to use OAuth is not that hard, but most implementations I see use a PIN method. In a PIN method, the user has to copy a number provided by Twitter after authenticating and copy that into the app’s interface. For the user this is a very cumbersome way to authorize an app to use their Twitter account. The remainder of this blog post will describe how to use the callback method. In a callback method, Twitter redirects the user back to a URL given by the client app. Twitter provides authorization values as parameters to the callback URL. These values are then used to obtain the final access token.
The first thing to do is to configure your Twitter API keys, accessible from Twitter’s apps page. In the Settings tab for an app, turn on “Read, Write and Access direct messages” and enter a callback URL. It doesn’t really matter what you use since we’re not actually going to load the URL. Use something with your own host, e.g. “infinite-sushi.com/callback”.
The trick is then to use UIWebView’s webView:shouldStartLoadWithRequest:navigationType: delegate call to intercept Twitter’s redirection to the callback url. Grab the parameters of that callback request, dismiss the UIWebView, finalize authorization, and let the user continue using the app.
A sample iOS app demonstrating the OAuth with callback method can be found on my GitHub. It uses a version of the OAuthConsumer library.
