» Preemptive HTTP Authentication with Android 2.2

Preemptive HTTP Authentication with Android 2.2

I just spend a good few hours trying to figure out why my Android application fails to communicate with a web service which requires preemptive Basic HTTP Authentication. Here’s an example code for anyone else on the same quest:

String auth = android.util.Base64.encodeToString(
	(username + ":" + password).getBytes("UTF-8"), 
	android.util.Base64.NO_WRAP
);
HttpGet request = new HttpGet(url);
request.addHeader("Authorization", "Basic "+ auth);

Thanks Mark Murphy.

David Linsin shows in his blog how to use HttpRequestInterceptor to fiddle with the request before it is sent. For some reason I wasn’t able to make it work and I don’t see any reason why adding the Authorization header manually wouldn’t be enough. Feel free to correct me if I’m missing something here.

Android 2.2 ships with Base64 utility class. With older versions you can use http://iharder.net/base64. This is what Mark Murphy uses in his examples. The interface is almost identical.

android.util.Log Trims, Base64 Doesn’t!

This is actually the reason why all this took so long to figure out. The web server returned “400 Bad Request” and I couldn’t figure out what was wrong. I knew the problem was in the Authorization header but when I logged the authorization token everything looked OK… until I did this:

Log.i("AUTH", "\""+auth+"\"");

I turned out that the base64 encoded authorization token had an extra newline at the end. Hence, android.util.Base64.NO_WRAP.

» My name is Mäkinen, Veikko Mäkinen

Sometimes it’s not easy to be a Finn with weird characters in my surname…

On 18.12.2010 20:22, devenroll@apple.com wrote:
> Please include the line below in follow-up emails for this request.
>
> Follow-up:  XXXXXXXXXXX
>
> Re: iOS Developer Program
>
> Dear Mr Makinen,
>
> We are currently in the process of reviewing your iOS Developer
> Program enrolment information.
>
> In reviewing your company enrolment application, we have found the
> following information:
>
> Enrollment ID: XXXXXXXXXX 
> Company Name: XXXXXXXXXX  
> Applicant Name: Veikko Mäkinen 
> Email: veikko.makinen@xxxxx
>
>
> Please note that the applicant name is in double-byte characters. We
> are unable to properly view this on our system since we require
> registered information to be in standard English characters. We have
> therefore withdrawn your enrolment XXXXXXXXXXX and you can submit a
> new enrolment request with the correct applicant name.
>
> We ask that you please submit a new enrolment using a different Apple
> ID and email address from the ones used for your original enrolment.


Dear Apple Developer Support,


I have read this message over and over again and several times checked 
my calendar to make sure I'm still in year 2010 and not leaped back to 
the 90'ies. Don't get me wrong, though. Many quality software systems 
were built in the 90'ies and if your enrollment system still runs just 
fine there's no need to update it to support other character sets besides 
the legendary American Standard Code for Information Interchange, or 
ASCII. After all, if we get by with ten digits, 128 characters should 
be plenty.

This can, however, become problematic now that developing countries like 
Finland or Germany are joining the party. Some of these newcomers, me 
being one of them, might expect to be able to use their actual names 
or at least GET A NOTICE AND A CHANCE TO CORRECT IF THE NAME PROVIDED 
IS NOT ACCEPTABLE!

And then about creating a totally new Apple ID just to be able to enroll 
with a fake name: You have got to be kidding...? No? Absolutely sure? 
I have changed the name in my Apple ID account but the enrollment system 
still insists that my name is Veikko Mäkinen. Can't I reset the information 
from the Apple ID account? I was under the impression that Apple systems 
Just Work.


Sincerely,
Veikko Mäkinen

» Facelift

Long overdue facelift of my ever-so active blog happened finally. Briefly tested with Firefox 3, IE8, and Safari [something]. Can’t be bothered with anything more.

» A Great Article Series on Agavi

Vikram Vaswani has written a great article series on Agavi. The five-part series starts off with the basic but in the end goes quite deep into building a multi presentational layer web application. Go read it on the IBM developerWorks! Now!

• Part 1: Open a whole new world with Agavi
• Part 2: Add forms and database support with Agavi and Doctrine
• Part 3: Add authentication and administrative functions with Agavi
• Part 4: Create an Agavi search engine with multiple output types including XML, RSS, or SOAP
• Part 5: Add paging, file uploads, and custom input validators to your Agavi application

» Propel Developers’ Held a Meeting

Propel developers held an IRC meeting last night discussing the projects future. Amazingly many showed up and the discussion was active and fruitful.

Read the log at Propel Wiki.

» Say It!

Disqus Comments

Integrating Disqus commenting system to my Tumblr blog was ridiculously easy. Just have to figure out why the comment form completely breaks my design :)

» Be Careful with PHP’s version_compare

Be Careful with PHP’s version_compare

var_dump(version_compare("5.2.8-0.dotdeb.1", "5.2.8", "<="));

Expected result: bool(true)

Actual result: bool(false)

The moral of the story: use < or >.

» Installing a Project-local Propel

Installing a Project-local Propel

Installing Propel is often seen as a difficult task. Official installion instructions recommend installing via Pear and say more initial work is requireq to install it manually. I usually advice not to use global Pear installations but install everything per project because it gives you better control and you are able to use different versions of libraries for different project. This article shows you how easy it actually is to have a project-local installation of Propel 1.3.

Prerequisites

• Phing 2.2.x (and, thus, Pear)

Phing is the only exception to my “no pear installations” rule. It can be installed per project but I see Phing as a development tool you can have globally on your development machine.

Suggested Directory Layout

/            project root
  dev/       development-time files (docs, database schemas, code templates etc.)
    db/      database development files (schema.xml, diagrams, docs etc.)
    libs/    development-time libraries
  libs/      runtime libraries (3rd party)

Getting Propel from the SVN

I recommend fetching Propel directly from the SVN repository simply because I see that as the easiest choice and you have full control of which version to pick. Also, should you ever want to upgrade to a newer revision (maybe there is a bugfix that isn’t officially released yet), you can just retrieve it from the repository. Personally I have 3rd party libraries set up as svn:external where possible but we don’t go into that in this article.

Propel is split into two components - generator and runtime libraries and we’ll keep those two appart. So, in your project root execute following SVN commands:

svn export http://svn.phpdb.org/propel/branches/1.3/generator dev/libs/propel

svn export http://svn.phpdb.org/propel/branches/1.3/runtime/classes/propel libs/propel

And that is it. YES, I mean it!

Propel is now ready to be used. You don’t need to set PATH or include_path, you don’t need to copy executables anywhere and you don’t have to modify a single file.

Building a Propel Project

Create your schema.xml, runtime-conf.xml and build.properties files in dev/db. To build your project go to your project root and run

dev/libs/propel/bin/propel-gen dev/db

… and whatch Propel do its magic. Propel creates output files into ´dev/db/build/´

Fine-tuning The Building Process

You can control where Propel puts the output with a few build.properties directives. Here’s an example that probably needs no explanation.

#relative to propel-gen script
propel.output.dir = ../../..
propel.php.dir = ${propel.output.dir}/app/lib/propel
propel.phpconf.dir = ${propel.output.dir}/dev/db/config
propel.sql.dir = ${propel.output.dir}/dev/db/sql

What About Runtime?

Yeah, you got me there - there’s still one thing you need to take care of before everything “just works”.

//propel runtime + path to your om classes
$path = '/my/project/libs' . PATH_SEPARATOR . '/my/project/app/lib/propel';
set_include_path(get_include_path() . PATH_SEPARATOR . $path);

» Agavi 1.0.0 Beta 8 Includes a Critical Security Fix

Agavi 1.0.0 Beta 8 Includes a Critical Security Fix

A new Agavi 1.0.0 Beta 8 was released late yesterday (European time). As usual, the new version contains several improvements and bug fixes but also a fix to a critical cross-site scripting vulnerability described in http://trac.agavi.org/ticket/1019. The vulnerability actually affects, as far as we know, only Internet Explorer 6 and 7 which fail to encode URL according to standards.

Affected versions:

• Agavi 0.11 up to and including 0.11.6-RC2
• Agavi 1.0 up to and including 1.0.0-beta7

Solutions

• Upgrade to 0.11.6 or 1.0.0 Beta 8
• Patch your Agavi with a hot fix attached to the ticket
• Use one of the workarounds described in the ticket.