Rolling my own basic authentication?

[magus]

I'd like to roll my own basic authentication for a web service, i.e. I
don't want to use the contrib.auth module. If possible I'd like to
avoid relying on the server for this. Anyone who can offer some
pointers on how to raise a 401 on a request that doesn't contain the
Authentication: header?

The 401 also needs to contain the realm, how would I do that?

/M

[Sean Perry]

Forgive the possibly stupid question, but why not just use htaccess /
apache auth? (or insert the method supported by your web server here).
It is simple, requires almost no code and you will get the user name as
an environment variable.

Beyond that, look into what Jacob said. The session layer is supposed to
be cheap if you never ask for anything from it.

[magus]

Sean Perry wrote:
> magus wrote:
> > I'd like to roll my own basic authentication for a web service, i.e. I
> > don't want to use the contrib.auth module. If possible I'd like to
> > avoid relying on the server for this. Anyone who can offer some
> > pointers on how to raise a 401 on a request that doesn't contain the
> > Authentication: header?
> >
> > The 401 also needs to contain the realm, how would I do that?
>
> Forgive the possibly stupid question, but why not just use htaccess /
> apache auth? (or insert the method supported by your web server here).
> It is simple, requires almost no code and you will get the user name as
> an environment variable.

It's the "insert the method supported by your web server here" part
that I am trying to avoid. I'd like to keep the username/password
available to the webservice, which means I'll have to either have the
server use the webservice's database (already solved for
Apache/contrib.auth, I know) or somehow keep two files in sync. I don't
like that idea. It would also tie my webservice to a server, I don't
like that either :-)

Since the username/password are in the HTTP header I believe they would
be available in the "environment" as long as the server doesn't filter
it out.

> Beyond that, look into what Jacob said. The session layer is supposed to
> be cheap if you never ask for anything from it.

Yes, but "cheapness" is only one of my concerns. I have two bigger
concerns:

1. By limiting the external dependencies (i.e. the number of django
modules I use) I will lower the risk of being hit by a bug that I don't
control.
2. AFAICS the session is represented by a cookie, for me this is
totally unnecessary since there will be no session. The webservice will
have no server-side state to keep track of. Also, there's a lot of
smart people out there and they keep on comming up with new and
interesting ways to use session cookies (session hijacking, session
fixation, etc.).

Another issue, albeit a lot smaller, is the fact that contrib.auth has
a model that's too big. My model looks like this:

class User(models.Model):
name = models.CharField(maxlength=50, primary_key=True)
passwd = models.CharField(maxlength=50)

I don't need anything more than that. If I don't need more, I don't
want more. The reason? With less code, less things will go wrong :-)

And, yes, I know I'm slightly paranoid and anal about all of this. :-)

/M

[magus]

Commenting on my own posts here :-)

magus wrote:
> Sean Perry wrote:
> > magus wrote:
> > > I'd like to roll my own basic authentication for a web service, i.e. I
> > > don't want to use the contrib.auth module. If possible I'd like to
> > > avoid relying on the server for this. Anyone who can offer some
> > > pointers on how to raise a 401 on a request that doesn't contain the
> > > Authentication: header?
> > >
> > > The 401 also needs to contain the realm, how would I do that?
> >
> > Forgive the possibly stupid question, but why not just use htaccess /
> > apache auth? (or insert the method supported by your web server here).
> > It is simple, requires almost no code and you will get the user name as
> > an environment variable.
>
> It's the "insert the method supported by your web server here" part
> that I am trying to avoid. I'd like to keep the username/password
> available to the webservice, which means I'll have to either have the
> server use the webservice's database (already solved for
> Apache/contrib.auth, I know) or somehow keep two files in sync. I don't
> like that idea. It would also tie my webservice to a server, I don't
> like that either :-)

Another reason I just thought of is flexibility. If I can decorate a
specific method in django as needing authentication then I can require
authentication for only some methods easily. This also means that I can
make changes to urls.py later on without having to revisit my web
server's configuration.

/M

[Sean Perry]

magus wrote:
> Yes, but "cheapness" is only one of my concerns. I have two bigger
> concerns:
>
> 1. By limiting the external dependencies (i.e. the number of django
> modules I use) I will lower the risk of being hit by a bug that I don't
> control.
> 2. AFAICS the session is represented by a cookie, for me this is
> totally unnecessary since there will be no session. The webservice will
> have no server-side state to keep track of. Also, there's a lot of
> smart people out there and they keep on comming up with new and
> interesting ways to use session cookies (session hijacking, session
> fixation, etc.).
>

if you never ask it to set a cookie, no cookie is ever created.

[mukappa]

Something like this?

response = HttpResponse()
response.status_code = 401
response['WWW-Authenticate'] = 'Basic realm="%s:%s' % (
request.META["SERVER_NAME"], request.META["SERVER_PORT"])
return response

[magus]

I believe you meant to say "if you never call login() no cookie is
created". That is good to know for the future if I ever actually NEED
the functionality that's available in contrib.auth :-)

/M