Authentication redirects with iOS and Django

I am writing a client/server application. The client is an iPhone; client requests are handled by a Django application. Below, I will demonstrate how an iOS device can respond to redirects for login credentials from a Django service when a session has expired. I have not found much written about this subject so I am publishing what I have learned. This assumes that you know how to store and retrieve the username and password on an iOS device via Keychain Services, make HTTP requests from an iOS client, and create basic Django applications.

There are several questions that arise when acquiring a new session id with the client:

1. How do we send username and password credentials to the Django service from the iOS client, such that we a) login to the server b) get forwarded to the original page we requested?
2. What happens when the client requests a Django view with an @login_required decorator if the client's session id is expired?
3. What happens to POST data in an original client request after the server sends login URL redirects while sending authentication challenges?

I hope the following post answers all of these. First, some definitions:

• 'session id' - this refers to the hexadecimal string sent from the server as a cookie value, after the a user has signed-in/logged-in. (eg. "2b1189a188b44ad18c35e113ac6ceead"). More info on Django sessions
• 'server' - in this case a Django app, hosted by Apache using mod_wsgi.
• 'client' - in this case an iPhone (3GS), running the application and sending requests over a LAN. But theoretically, it could be any iOS networked device.

I will demonstrate with a URL that requires the user to be 'logged in' on the Django app. If the client does not have a valid session id, Django will respond by forwarding to a login view. In our case we will challenge the iOS client with a WWW-Authenticate; the client will respond to the challenge in a delegate method and be redirected to the original URL requested by the client. Inside a delegate method on the iOS client, I will show how to preserve the original request's HTTP method and (NSData *)HTTPBody .

Let's make this a simple HTTP GET request. In this case the requested URL will be:

http://10.0.0.2/user/home/


When the client sends the above request, the Django view will detect that the client is not logged in because either the session id was not sent with the GET request or the session id was expired. The server will respond with a status code of 302. In this case the server will respond with the redirect URL of the login page. Here is the @login_required decorator in the requested view:

	# if the client request does not contain a valid session id, the
	# client will receive a redirect to http://10.0.0.2/signin/
	@login_required(login_url='/signin/')
	def user_home_view(request):
	# . . . returns the user's home view

view raw gistfile1.py hosted with ❤ by GitHub

Before we look at the Django sign in view, let's have a look at the NSURLConnection Delegate in the class that sends the request:

	// MyHTTPRequest.h
	@interface MyHttpRequest : NSObject {
	// The following 3 class attributes are saved as the initial request is created.
	// If a redirect occurs, these attributes will be used to copy to the last redirected request,
	// only if the URL is the same as the initial request's URL
	NSData *requestBodyData;
	NSString *requestMethod; // POST or GET
	NSURL *requestURL; // initial request's URL
	// other attributes omitted
	}
	// notice we 'copy' the NSData. This will be the original request's HTTPBody
	@property (nonatomic, copy) NSData *requestBodyData;
	@property (nonatomic, retain) NSString *requestMethod;
	@property (nonatomic, retain) NSURL *requestURL;
	// other attributes omitted

view raw gistfile1.m hosted with ❤ by GitHub

	// inside MyHTTPRequest.m
	- (NSURLRequest *)connection:(NSURLConnection *)connection willSendRequest:(NSURLRequest *)request redirectResponse:(NSURLResponse *)response {
	/* This delegate method is called before the connection sends a NSURLRequest.
	(NSURLResponse *)response will be nil when this method is not called by the delegate recieving a redirect
	(NSURLRequest *)request will contain the NSURLRequest object that (NSURLConnection *)connection is about
	to send to the server.
	For example, during an initial request to a server, this delegate method is called
	and (NSURLResponse *)response will be nil, since the delegate has not received a HTTP
	redirect ( the delegate has not received any response from the server yet because no request
	has been sent yet )
	*/
	if (response != nil) { // response contains a HTTP redirect ( ie. status code 302)
	// request will now contain the redirected URL. Our original request data has been lost!
	// if the request is the same as the URL for the initial request, recreate
	// the original request, including the HTTP method, HTTPBody, and HTTPHeaderFields
	if ([[requestURL absoluteString] isEqualToString:[[request URL] absoluteString]]) {
	NSMutableURLRequest *newRequest = [[NSMutableURLRequest alloc] initWithURL:requestURL];
	[newRequest setHTTPMethod:requestMethod];
	if (requestBodyData != nil) {
	[newRequest setHTTPBody:requestBodyData];
	}
	[newRequest setAllHTTPHeaderFields:[request allHTTPHeaderFields]];
	return [newRequest autorelease];
	} else {
	// request is not the same as our original request, so return the redirected request URL
	return request;
	}
	} else {
	// response == nil so send the original request
	return request;
	}
	}

view raw gistfile1.m hosted with ❤ by GitHub

The delegate method is sending a new request containing the redirected URL if the server sends a redirect. And it is sending the original request if no redirect has been sent by the server. It is also sending a version of the original( very first ) request ( HTTPBody, HTTP method, and the latest header fields), only if the redirected URL is the same as the original request; This is how we keep any POST data in the HTTPBody when login redirects have succeeded. More on that below. Let's first take a look at the Django login view:

	def auth_landing_page(request):
	try:
	if request.META['HTTP_AUTHORIZATION']:
	# in httpd.conf set 'WSGIPassAuthorization On'
	# WSGIPassAuthorization will pass the login information sent by the client to the Django view,
	# as shown below.
	http_authorization = request.META['HTTP_AUTHORIZATION']
	import base64
	_user, _password = base64.b64decode(http_authorization[6:]).split(':')
	user = authenticate(username=_user, password=_password)
	if user != None:
	login(request, user)
	if user.is_authenticated():
	# return request.GET['next'] contains the initially requested URL
	# a typical redirected URL will look like this: /login/?next=/user/home/
	return HttpResponseRedirect(request.GET['next'])
	else:
	pass
	else:
	return HttpResponse("Username or password was incorrect")
	except KeyError:
	# if we did not acquire user and password from the client,
	# present the client with a WWW-Authenticate challenge.
	client_auth_challenge = HttpResponse("")
	client_auth_challenge.status_code = 401
	client_auth_challenge['WWW-Authenticate'] = r'Basic realm="Secure Area"'
	return client_auth_challenge

view raw gistfile1.py hosted with ❤ by GitHub

Notice how we send an authentication challenge from the view if no credentials have been sent by the client? Also, note that within httpd.conf, WSGIPassAuthorization must be set to 'on' for mod_wsgi to forward the credentials to the Django view.

Upon redirecting to the login URL, the client is presented with an authentication challenge. The client should respond appropriately within the NSURLConnection delegate method:
 - (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge


The client requests the redirected URL and sends the login credentials when receiving a WWW-Authentication challenge. Upon successful login, they are redirected to the original URL- which is stored by Django in the requests as 


request.GET['next'] = "/user/home/"


In the redirect for the original URL, after successful login, the Django view sends the cookie containing the session id. In the NSURLConnection delegate 


-(NSURLRequest *)connection:(NSURLConnection *)connection willSendRequest:(NSURLRequest *)request redirectResponse:(NSURLResponse *)response;

all of the headers from the last request are copied to the newRequest; this includes the session id. If there was any POST data in the original request, it will also be copied to the newRequest, so that the original transaction data will be sent to the server after authenticating and acquiring a new session id.


I hope that this shed some light on how to keep your iOS app able to handle authentication redirects when the server session id expires. 


NOTE: I did not cover displaying a login view that allows the user to enter in username and password in the iOS client if the server login fails. Also, I did not show how to use the