views:

857

answers:

1

Here's how my university handles authentication: we redirect the user to a website, they enter in their username and password, then they get redirected back to us with the username and a login key passed in the query string. When we get the user back, we call a stored procedure in the university's database that takes the username, login key, and ip address and tells us if this is valid.

I've got a Django custom authentication backend set up to handle our end of all of this. Does it make any difference one way or another whether I make it able to accept a password argument (since we're not actually taking their password)? Right now, I have it set up so that it takes the login key as the password argument. Would it be good, bad, or neither for me to change this to take this as say, login_key instead of as password?

+5  A: 

The Django docs say this:

Either way, authenticate should check the credentials it gets, and it should return a User object that matches those credentials, if the credentials are valid. If they're not valid, it should return None.

The 'Either way' refers to whether the authenticate() method takes a username/password combination, or just a token. Your scenario falls between those two, so I'd think that the 'best' answer would be to write your authenticate() to take a username and a login key, and return the right User or None as appropriate.

Harper Shelby
Be sure to see how the default authenticate works(by looking at code), as the docs says that it does other stuff too. See the remark "Calling authenticate() first"
Tiago
+1: ditto the call authenticate() first. We resorted to a Profile extension to store MD5 digests separate from the SHA1 digests that Django uses so we could authenticate sensibly.
S.Lott