http.server.BaseHTTPRequestHandler basic auth logout? Django authentication system for REST interface?

[Roy Smith]

In article <mailman.10835.1402098782.18130.python-list at python.org>,
 Dan Stromberg <drsalists at gmail.com> wrote:

> I have some code for a web server.  Right now, it uses
> BaseHTTPRequestHandler with Basic Auth, but we want to be able to log
> out, and there doesn't appear to be a general way to log out of
> something using Basic Auth, short of turning to unportable JavaScript.
>  And this needs first and foremost to be machine-callable, so
> JavaScript probably isn't a great solution for us.
> 
> Does BaseHTTPRequestHandler add a way of dealing with Basic Auth
> logout by any chance?  I googled about it, and didn't find anything.
> 
> I could rewrite to work with Django's authentication system I suppose.
>  Does this work reasonably well for REST API's?  How do you pass the
> credentials?  Is it a cookie?
> 
> Thanks!

There's a lot of questions wrapped up in one there.

Personally, I would stay away from the BaseHHTPRequestHandler stuff.  
That's really low level.  If you're building a REST API, probably lower 
than you need to be working.

We got a REST-ish API running in django.  We let django do the session 
management for us.  That means django drops a session_id cookie on the 
client.  We don't use the django authentication system, but have our own 
/api/login and /api/logout routes which let us manage the state (i.e. 
logged in or out) of each session on the backend.

This works fine for our web browser clients.  For our mobile clients, it 
still works, but having mobile clients manage the cookie store on their 
end is annoying (to the mobile app developer).  Cookies are great for 
keeping state on the client side when you're talking to a plain old 
browser.  Once you're talking to a client application (be it a native 
app on a mobile device, or a javascript app running in a browser), 
cookies are more trouble than they're worth.

If we were to do it all again (and, someday, we will), we would probably 
skip the cookies all together.  We would still have a /api/login route, 
but instead of tracking sessions by cookies, we would hand the client 
back (as part of the HTTP data payload) a token.  It would be up to the 
client to present that token back to us with every subsequent request.  
We would have to keep state on the server side about every extant valid 
token (but then again, we need to do that now, for each session).  
Logging out would just be involve invalidating the token.