Archive for the ‘OWA’ Category
When I first bought my Droid Eris, around a year ago, it came loaded with HTC replacements for most of the stock Google apps, including the mail app, the dialer, mms, etc… The HTC mail app just worked – it supported Exchange, handled multiple in-boxes, and the notifications worked like a charm. Sadly, when I switched to a Froyo ROM, the HTC applications where no longer available and I was stuck with the stock Google apps. Well, as far as the mail application was concerned, this was a very bad thing. The Google mail app came with some significant bugs, and a notification system that was pretty much useless. So I set out to find an acceptable replacement for the HTC app.
This is when I found K-9. It was reviewed well, and boasted Exchange support, which is apparently hard to find on Android. I was saddened when I discovered the state of the Exchange support, which wasn’t great. Firstly, there was a bug in it that prevented it from working with the domain\username format. But alas, the project was open source and, being a developer, this was good news. So I took it upon myself to dive in and fix whatever bug(s) was preventing it from working correctly. I had no idea what I was in for at that point.
What was going to hopefully be a few line patch turned into 2,000 lines or so – and I was only half done at that point. By now I have completely rewritten the process of making the initial connection to Exchange and authenticating. After my initial patch was (reluctantly) reviewed and merged, the project head offered me the position of taking over as maintainer for Exchange support. I accepted, but warned him that I don’t have much free time these days. Either way, I have gained a lot of knowledge about how Exchange with OWA and WebDAV work, and am able to share that knowledge with you.
First, let me describe a little bit about how WebDAV access works. Each user has a mailbox, which by default can be accessed by a URL in the form: https://mail.company.com/Exchange/username. Tack ‘/Inbox’ on to that path, and you have the user’s inbox. You can type that into your browser and you will be kindly redirected to an OWA login page. If you were to send an HTTP GET request to that URL, you would find that the Exchange server responds with a 302 status code, which is a redirect. This is exactly what K-9 does when making its initial connection to your exchange server.
Assuming this request is “successful” (I won’t go into what qualifies as success), K-9 then attempts to authenticate you. Based on the initial response, this will either be through basic authentication or form-based authentication. The greater majority of Exchange servers are setup for form-based authentication, and this is the only configuration I have actually tested. Unless the user has overridden the default authentication path in their configuration (which is completely unnecessary), the path used is: https://mail.company.com/exchweb/bin/auth/owaauth.dll. If Exchange gives K-9 back authentication cookies on the response, the user is authenticated and K-9 retrieves the user’s list of folders. Otherwise, it tries a more brute-force approach. It will check the response for an HTML form target. If it does not find one, it will send a request to the redirect URL from our initial connection and check this response for an HTML form target. Assuming one of these searches yields a valid form target, it will then try to authenticate again using a URL constructed with this form target. For this reason, the user can enter complete junk into the ‘Authentication path’ field, and K-9 will still be able to authenticate the user (albeit less efficiently). I could have removed this field entirely, but chose not to just in case a user has a completely custom/bizarre Exchange configuration.
The only reason I have encountered for why a user would need to enter a value for one of the “advanced” configuration options is if their mailbox alias does not match their user name. Unfortunately, this was not the case for versions of K-9 prior to 3.400. For this reason, upgrading K-9 to the most recent version will break Exchange support for some users until their configuration is corrected. I didn’t really want to do this, but it was a necessary improvement so that these advanced options have a specific and deterministic affect on how K-9 connects to your Exchange server. I don’t want users spending hours “tinkering” with their options trying to get K-9 to work anymore.
To cap off this blog post, I’d like to show some screen shots of the updated screen for configuring an Exchange account. As of the writing of this post, these changes have not even been merged into trunk yet.
Let me know what you think.