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

[Dan Stromberg]

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!

 

[Roy Smith]

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.