Playing With Wire » Django The Internet Startup Blog Wed, 20 Jul 2011 18:45:29 +0000 en-US hourly 1 Zendesk Remote Authentication with Django and Unicode Names Sat, 06 Jun 2009 17:16:22 +0000 Recently we hooked up with Zendesk for our support system. We hooked up its Remote Authentication API so that our customers could use their YippieMove logins in our support system as well. Jon Gales provided a great recipe for doing this in Django which we kicked off with, making some minor updates too. Only one problem remained: if an account had international characters in the first or the last name, Chinese, Japanese, and so on, the code would error out.

Here’s what the error looks like in practice:

Traceback (most recent call last):

File "/usr/local/lib/python2.5/site-packages/django/core/handlers/", line 86, in get_response
response = callback(request, *callback_args, **callback_kwargs)
hash = md5('%s %+s%s%s%s' % (first, last,, settings.ZENDESK_TOKEN, timestamp)).hexdigest()

UnicodeEncodeError: 'ascii' codec can't encode character u'\xef' in position 2: ordinal not in range(128)

The problem is that md5().hexdigest() only works on byte strings. If you give it a unicode string it will try to .encode('ascii') it, which works fine as long as there are no international characters in the string.

The solution is simple: just explicitly UTF encode the source string. The Zendesk documentation did not mention what encoding they use themselves but my first guess would have been UTF-8, which turned out to be right. So with that in mind here is our current version of Jon Gales’ Zendesk Remote Authentication snippet for Django:

def authorize(request):
    timestamp = request.GET['timestamp']
  except KeyError:
    raise Http404

  u = request.user

  from hashlib import md5

  first = u.first_name
  last = u.last_name
  if not first and not last:
    first = "Yippie"
    last = "Mover"

  data = u'%s %+s%s%s%s' % (first, last,, settings.ZENDESK_TOKEN, 
  hash = md5(data.encode('utf-8')).hexdigest()

  url = u"%s/access/remote/?name=%s %s&email=%s&timestamp=%s&hash=%s" % (
    settings.ZENDESK_URL, first, last,, timestamp, hash)

  return HttpResponseRedirect(url)

Notice that we feed a unicode URL to HttpResponseRedirect – Django is smart enough to do the right thing when encoding the URL.

]]> 0
YippieMove promoted and polished Fri, 01 Aug 2008 02:04:06 +0000 YippieMove has now been up and live for a few weeks. Here at WireLoad we’ve kept busy even after the launch, focusing on promotion and polish.

The promotion part is similar to how it was like when we started up Playing With Wire. Apart from the obvious – buying ad based exposure – we’ve been working on the most important part for a modern website. The website has to appear in search engines. So we configured a Sitemap and added the site to Google Webmaster Tools.

The Sitemap is a simple enough idea: you list what public pages you have on your site and provide auxiliary information about how often you think each page will change and how important it is to the site. Since YippieMove is written with Django we could use Django’s Sitemap framework. We couldn’t use any of the fancy shortcut classes but since YippieMove only has a few public pages a simple list did the trick. We could have written the whole Sitemap by hand by this logic, but in the future there may be lists of pages we can add more dynamically. Besides our list in Python is much less verbose than the XML of an actual Sitemap. Writing XML by hand is painful.

We use Google’s Webmaster Tools for all our sites. I don’t know if it actually encourages Google to keep the sites well indexed, but it does make it easier to troubleshoot. The information I keep checking is when Google last crawled the site. YippieMove isn’t very well indexed right now but since I know that Google hasn’t crawled our site for more than 2 weeks, I know all I can do is to wait. It’s too early to start examining if there’s anything we’re doing wrong with the content or inter-page linking and so on.

We’ve also been polishing the site. The demo video has been up for some time now.

We fixed a couple of bugs. On the second week we noticed iPhone based access was not working. This appeared to be due to the version of Prototype we were using: 1.5. Upgrading to 1.6 took care of that easily enough. The experience in Internet Explorer 7 wasn’t perfect. Various bugs had snuck into the Ajax form submission towards the end of development. Our policy with Internet Explorer is simple: the site needs to work, no more. So we fixed the bugs and left an odd graphical glitch (the fieldsets we use have a border in IE 7 even that the CSS specifies no border).

Another matter of polish, or at least gradual expansion, was that we added more preconfigured providers. We now support more than twice as many preconfigured email providers as when we started. As the list began to grow a little long we also added category headers to structure it up visually.

Speaking of providers, we hooked up a learn more page that lists what we’ve got. Hope you like the design – those 3D screenshots take forever to make with my current method. :)

So all in all, it’s been productive since the launch. I hope you’ll all enjoy the new stuff!

]]> 0