Re: auth.User refactor: reboot
A bit of an odd question-- What practices have other packages adopted? For example, I was playing with ASP.NET last weekend to help out a friend and found their decoupling of authentication from the database to be rather pleasant. Is it possible to add a layer of indirection. In some sense, I want to know: 1) What is the identify of this "putative" user 2) If their Identity is verified, what resources are they Authorized access to. To determine identity, in the current era, there are many ways--for example: single factor: 1) username/password 2) email address/password multifactor: 1) username/password + PIV card 2) username/password + RSA token Depending on the credential, it can be checked in multiple ways: active directory database etc. To facilitate these different cases, can we have a pluggable "Authentication Service" where the user provides a "credential" which then returns a result of whether the credential is valid or not?We could then implement a few "standard" authentication plugins, such as username/password, email address/password. Third party apps would run against the authentication service, so they shouldn't depend on a particular implementation of user in the database.For legacy users, the current username/password could be implemented and run as the default , so they only have to migrate if they want to...The settings file could be used to register authentication "providers" (for example EmailAuth or UsernameAuth) with the authentication service. If there are multiple authentication methods (users can sign in via openauth or email address for example), then they would fallover in the order they are registered with the authentication service (using settings.py might require some effort to preserve order and avoid multiple registrations...). Is this workable, or would it have too much complexity and too much of a performance hit? Sorry to be so vague...One issue that would come to mind with such an approach is how to deal with things like password recovery in such a scheme using DRY principles... Best, William On Tue, Mar 20, 2012 at 2:02 PM, Donald Stufft wrote: > On Tuesday, March 20, 2012 at 2:00 PM, Tom Evans wrote: > > On Tue, Mar 20, 2012 at 5:41 PM, Donald Stufft > wrote: > > What Alex said. If it was _just_ the username then you'd have a good > argument for > a setting like that. However there's username, email, some people want to > add > fields, some want to get rid of, or combine fields. Ideally any change > would > work > for as many of those use cases without turning into a giant set of boolean > flags > that drastically alter the DB schema. > > > No-one is talking about a 'giant set of boolean flags', or drastically > altering the DB schema. > > The email field needs to accept email addresses of up to 254 octets. > The username field should be able to hold common fields used as a > username, eg emails, and hence needs to be longer. > > That is one boolean flag. No more. If you want more flexibility on the > model, you would use the proposed pluggable auth models. > > What the much maligned setting gives us is a way to provision new > sites and migrate existing sites that care about that situation in to > a position where users with long email addresses can sign up to a > django site. Score. > > Cheers > > Tom > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > So you fix the problem for the people who agree that username should be > longer, and that email > should be longer, but not the people who feel that email should be longer > but username is fine? > > Those settings do not feel any cleaner to me personally than monkey > patching the models. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: #16779 - a tutorial for first time Django contributors
I develop on windows, linux, and macos--for windows, I have to say that I tend to use tortoise-git (somehow, I still prefer it to github for windows), whereas for linux, the command line is greatFrom my experience leaping between platforms, it's rather painful to try to shoehorn the way of doing things on one platform into another...It's more work, but perhaps a linux/windows section would work best for those areas that are more platform specific (for example, environment variables in windows, vs linux)? Anywho, just my 2 cents... On Sun, Nov 11, 2012 at 4:17 AM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > Le 11 nov. 2012 à 06:53, Shai Berger a écrit : > > > On Sunday 11 November 2012, Tim Graham wrote: > >> > >> I think the part that has the most potential to confuse new > contributors is > >> the introduction of PYTHONPATH. Claude suggested we could simply > instruct > >> users to run the tests like so: > >> > >> PYTHONPATH=/path/to/django ./run_tests.py --settings=test_sqlite > >> > >> I'm not particularly in love with that, but it would eliminate the need > to > >> try to explain things > > I've always been running the tests with: > > $ cd tests > $ PYTHONPATH=.. pythonX.Y runtests.py --settings=test_ > > It's straightforward and easy to understand: "Python will look for django > in the parent directory". > > If you're just running Django's test suite on a reasonably configured > system, you're starting with an empty PYTHONPATH; you don't really need > PYTHONPATH=..:$PYTHONPATH. > > The alternatives are: > - either prone to mistakes and side effects (setting a systemwide > PYTHONPATH — what if I move my checkout?); > - or even more complicated to explain (mkvirtualenv djang && pip install > -e .) > > > > It would leave a lot to explain to Windows users (which I note you are > still > > trying to cater for). > > > If you're using the default options of the git installer on Windows, > you're getting a fairly decent environment (MINGW32). It creates a "Git > Bash" icon on the desktop, which starts a Bash shell where `git` works. > After adding `export PATH=/c/Python27:$PATH` to `~/.bashrc`, `python` also > works in that shell. > > If we tell Windows users to use "Git Bash", we can skip most of the > Windows-specific instructions. It's likely to make the tutorial a better > experience for them. > > Otherwise, `set PYTHONPATH=..` works in `cmd.exe`, but I can't recommend > `cmd.exe` with a straight face :/ > > -- > Aymeric. > > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: #16779 - a tutorial for first time Django contributors
And I should say, thanks for the effort on this! On Sun, Nov 11, 2012 at 10:18 AM, william ratcliff < william.ratcl...@gmail.com> wrote: > I develop on windows, linux, and macos--for windows, I have to say that I > tend to use tortoise-git (somehow, I still prefer it to github for > windows), whereas for linux, the command line is greatFrom my > experience leaping between platforms, it's rather painful to try to > shoehorn the way of doing things on one platform into another...It's more > work, but perhaps a linux/windows section would work best for those areas > that are more platform specific (for example, environment variables in > windows, vs linux)? > > Anywho, just my 2 cents... > > > On Sun, Nov 11, 2012 at 4:17 AM, Aymeric Augustin < > aymeric.augus...@polytechnique.org> wrote: > >> Le 11 nov. 2012 à 06:53, Shai Berger a écrit : >> >> > On Sunday 11 November 2012, Tim Graham wrote: >> >> >> >> I think the part that has the most potential to confuse new >> contributors is >> >> the introduction of PYTHONPATH. Claude suggested we could simply >> instruct >> >> users to run the tests like so: >> >> >> >> PYTHONPATH=/path/to/django ./run_tests.py --settings=test_sqlite >> >> >> >> I'm not particularly in love with that, but it would eliminate the >> need to >> >> try to explain things >> >> I've always been running the tests with: >> >> $ cd tests >> $ PYTHONPATH=.. pythonX.Y runtests.py --settings=test_ >> >> It's straightforward and easy to understand: "Python will look for django >> in the parent directory". >> >> If you're just running Django's test suite on a reasonably configured >> system, you're starting with an empty PYTHONPATH; you don't really need >> PYTHONPATH=..:$PYTHONPATH. >> >> The alternatives are: >> - either prone to mistakes and side effects (setting a systemwide >> PYTHONPATH — what if I move my checkout?); >> - or even more complicated to explain (mkvirtualenv djang && pip install >> -e .) >> >> >> > It would leave a lot to explain to Windows users (which I note you are >> still >> > trying to cater for). >> >> >> If you're using the default options of the git installer on Windows, >> you're getting a fairly decent environment (MINGW32). It creates a "Git >> Bash" icon on the desktop, which starts a Bash shell where `git` works. >> After adding `export PATH=/c/Python27:$PATH` to `~/.bashrc`, `python` also >> works in that shell. >> >> If we tell Windows users to use "Git Bash", we can skip most of the >> Windows-specific instructions. It's likely to make the tutorial a better >> experience for them. >> >> Otherwise, `set PYTHONPATH=..` works in `cmd.exe`, but I can't recommend >> `cmd.exe` with a straight face :/ >> >> -- >> Aymeric. >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To post to this group, send email to django-developers@googlegroups.com. >> To unsubscribe from this group, send email to >> django-developers+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/django-developers?hl=en. >> >> > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Pluggable encryption for django auth (design proposal)
Hi! I'm new to the list and have started to look into authentication. I find that I will need to patch it for my own needs, but would like to ask the opinions of others who are more familiar with the code-base than I am. I apologize if I make any mistakes in the protocol of the list in matters such as including too much code. SHA1 is not secure. This is not a nationalism issue. For example: http://www.darknet.org.uk/2010/11/sha-1-password-hashes-cracked-using-amazon-ec2-gpu-cloud/ Or, from NIST: http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html where the relevant excerpt is: *March 15, 2006*: The SHA-2 family of hash functions (i.e., SHA-224, SHA-256, SHA-384 and SHA-512) may be used by Federal agencies for all applications using secure hash algorithms. Federal agencies should stop using SHA-1 for digital signatures, digital time stamping and other applications that require collision resistance as soon as practical, and must use the SHA-2 family of hash functions for these applications after 2010. After 2010, Federal agencies may use SHA-1 only for the following applications: hash-based message authentication codes (HMACs); key derivation functions (KDFs); and random number generators (RNGs). Regardless of use, NIST encourages application and protocol designers to use the SHA-2 family of hash functions for all new applications and protocols. I have also seen discussions in other venues from people who are worried about the security of SHA1 in the event that their system is compromised, can an attacker gain the passwords in the database? The appearance of modules such as django-bcrypt: https://github.com/dwaiter/django-bcrypt/ show that this issue is becoming of more general concern. Current solutions: 1) Monkey patch: put a top level installed_app that has a listener to the class_prepared signal that performs monkey patching throughout user. This is rather ugly and it feels very fragile to me if the auth module changes internally. 2) Rewrite the Backend as Tom suggests by subclassing ModelBackend: Again, it's not sufficient. Why? If we look at the Model Backend, we see that yes, the authenticate method currently authenticates against User--but the problem is NOT the authentication per se, but rather that the User class has several methods such as: check_password, set_password, etc. that have encryption hard coded. There are admin commands associated with the User class which refer to methods with a particular encryption method chosen. 3) For users of Django who cannot (say US government agencies, people who have tight security concerns, etc.) use the current module, ignore the auth module and roll their own: This has been attempted before. However, the problem is that it is easy to make mistakes doing this and most of the functionality in the auth module is very good and simply copying most of it to make a few changes to User--and to maintain those against modules which use the user module seems rather excessive. While my first suggestion was: Move the encryption related portions of the code that are hard coded to the authentication backend. Make a default which follows best practices (I would suggest moving to SHA2 in a backwards compatible fashion) that most people will use. However, for those that want to use bcrypt for example, it would be easy for them to simply write their own backend. However, there are also merits to Paul's approach of having a mapping in the settings file. What I like about the backend approach is that it allows for graceful fallbacks as function of python version, but gives the user the ability to change the algorithm in a simple way. Also, it saves one from distinguishing between sha1 and sha1 with stretchingPerhaps a compromise would be to have a backend which looks to the settings file for the location of a method? But, if I write a patch that works and maintains backwards compatibility would it be accepted? Is it better to email it here, or to submit a ticket, claim the ticket, and then add the patch? Also, would it be better for me to work from the trunk, or from 1.2.5? This is important because of: http://code.djangoproject.com/ticket/13969 Thanks, William -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Pluggable encryption for django auth (design proposal)
Hi! The scenario that I am considering is when the attacker has your database--can they compromise the passwords in it? While I believe that a salt will protect you against a "Rainbow Table" attack, I'm not convinced that it will protect you against the brute-force attacks which are now possible. I will try to consult some experts today and see if they are willing to go on record. William On Fri, Feb 11, 2011 at 8:10 AM, Eduardo Cereto Carvalho < eduardocer...@gmail.com> wrote: > I'm not an expert on the subject. > > But I think that the hashes security issues are olved by the use of a > "salt", salted hashes are known to be a very secure way to store data. > > > > On Fri, Feb 11, 2011 at 3:59 AM, William Ratcliff < > william.ratcl...@gmail.com> wrote: > >> Hi! I'm new to the list and have started to look into authentication. I >> find that I will need to patch it for my own needs, but would like to ask >> the opinions of others who are more familiar with the code-base than I am. >> I apologize if I make any mistakes in the protocol of the list in matters >> such as including too much code. >> >> SHA1 is not secure. This is not a nationalism issue. For example: >> >> http://www.darknet.org.uk/2010/11/sha-1-password-hashes-cracked-using-amazon-ec2-gpu-cloud/ >> >> Or, from NIST: >> http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html >> >> where the relevant excerpt is: >> *March 15, 2006*: The SHA-2 family of hash functions (i.e., SHA-224, >> SHA-256, SHA-384 and SHA-512) may be used by Federal agencies for all >> applications using secure hash algorithms. Federal agencies should stop >> using SHA-1 for digital signatures, digital time stamping and other >> applications that require collision resistance as soon as practical, and >> must use the SHA-2 family of hash functions for these applications after >> 2010. After 2010, Federal agencies may use SHA-1 only for the following >> applications: hash-based message authentication codes (HMACs); key >> derivation functions (KDFs); and random number generators (RNGs). Regardless >> of use, NIST encourages application and protocol designers to use the SHA-2 >> family of hash functions for all new applications and protocols. >> >> I have also seen discussions in other venues from people who are worried >> about the security of SHA1 in the event that their system is compromised, >> can an attacker gain the passwords in the database? The appearance of >> modules such as django-bcrypt: >> https://github.com/dwaiter/django-bcrypt/ >> show that this issue is becoming of more general concern. >> >> Current solutions: >> 1) Monkey patch: >> put a top level installed_app that has a listener to the class_prepared >> signal that performs monkey patching throughout user. >> This is rather ugly and it feels very fragile to me if the auth module >> changes internally. >> 2) Rewrite the Backend as Tom suggests by subclassing ModelBackend: >> Again, it's not sufficient. Why? >> >> If we look at the Model Backend, we see that yes, the authenticate method >> currently authenticates against User--but the problem is NOT the >> authentication per se, but rather that the User class has several methods >> such as: >> check_password, set_password, etc. that have encryption hard coded. >> There are admin commands associated with the User class which refer to >> methods with a particular encryption method chosen. >> >> 3) For users of Django who cannot (say US government agencies, people who >> have tight security concerns, etc.) use the current module, ignore the auth >> module and roll their own: >> This has been attempted before. However, the problem is that it is easy >> to make mistakes doing this and most of the functionality in the auth module >> is very good and simply copying most of it to make a few changes to >> User--and to maintain those against modules which use the user module seems >> rather excessive. >> >> While my first suggestion was: >> Move the encryption related portions of the code that are hard coded to >> the authentication backend. Make a default which follows best practices (I >> would suggest moving to SHA2 in a backwards compatible fashion) that most >> people will use. However, for those that want to use bcrypt for example, it >> would be easy for them to simply write their own backend. >> >> However, there are also merits to Paul's approach of having a mapping in >> the settings file. What I like about the backend approach is that it &g
Re: Pluggable encryption for django auth (design proposal)
Wow--you're ahead of me! Is your custom auth public source? If so, may I see the repo? Also, for increasing the length of the salt, are you referring to: http://code.djangoproject.com/attachment/ticket/13969/better_salting.diff <http://code.djangoproject.com/attachment/ticket/13969/better_salting.diff>I thought it was marked as accepted. But I just checked out SVN and you are correct that it is not using gen_salt. Does anyone know when it will be included? Thanks, William On Fri, Feb 11, 2011 at 9:50 AM, Clemens-O. Hoppe < clemens.o.ho...@googlemail.com> wrote: > That's a subject which comes up every few months, sadly. > > In a nutshell, if something requires python >= 2.5 or a lib for older > versions of Python, forget about adding it. > > See f. e. http://code.djangoproject.com/ticket/5600 which was closed as a > no-fix 3 years ago (full disclosure: I'm coh in that bug report). There was > also a discussion on this mailing list a few weeks ago about increasing the > salt length, but afaik it had no code-change as a result. > > I apologize if I sound a bit grumpy, but I've spend the last 5 days with > monkey-patching a local branch of the auth lib up to the latest in security > (SHA512, 128-bit salt, pre-stretching, pbkdf2, stronger random token > generation (salt, csrf, default-password)), now it spreads into other areas > of the django-lib as well (currently SECRET_KEY in the starproject script). > > Of course I would very much welcome such a proposal, yet I just believe the > odds for it to happen are (very) low. > > Cheers, > > coh > > > On 02/11/2011 06:59 AM, William Ratcliff wrote: > > Hi! I'm new to the list and have started to look into authentication. I >> find that I will need to patch it for my own needs, but would like to ask >> the opinions of others who are more familiar with the code-base than I am. >> I apologize if I make any mistakes in the protocol of the list in matters >> such as including too much code. >> >> SHA1 is not secure. This is not a nationalism issue. For example: >> >> http://www.darknet.org.uk/2010/11/sha-1-password-hashes-cracked-using-amazon-ec2-gpu-cloud/ >> > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Pluggable encryption for django auth (design proposal)
Excellent summary! If the core developers agree to this, I'm happy to contribute. William On Mon, Feb 14, 2011 at 1:37 AM, poswald wrote: > Here is an overview of issues on this subject opened over the years. > Some have existing code: > > http://code.djangoproject.com/ticket/3316 (Adding `crypt' to list of > password hashes for legacy apps. - closed: fixed) > http://code.djangoproject.com/ticket/5600 (Patch to enhance > cryptography on django.contrib.auth - closed: wontfix) > http://code.djangoproject.com/ticket/5787 (BCrypt password hashing > support in Django - closed: duplicate) > http://code.djangoproject.com/ticket/6028 (add compatibility with > glibc2 MD5-based crypt passwords - new ) > http://code.djangoproject.com/ticket/9101 (Improved salt generation > for django.contrib.auth - closed: wontfix) > http://code.djangoproject.com/ticket/9194 (Allow additional hashing > algorithms for passwords - closed: duplicate) > http://code.djangoproject.com/ticket/13969 (auth module should use > longer salt for hashing - new) > > Some of the arguments being made for this feature have been a bit > misleading and most of them pre-date the NIST requirements changeover. > I think the summary I made before gives the most clear overview of the > current situation: as it currently stands, if you get access to the > contents of a Django user table, you can decrypt the passwords very > cheaply/rapidly. > > Looking at the code of existing solutions to this it seems like the > following would be a reasonable approach: > > * Django ships with SHA2-256, SHA2-512 or PBKDF2 by default. SHA2 is > python 2.5 compatible (due to hashlib being added in python 2.5) and > PBKDF2 is short enough that it could be included into the project. > This satisfies NIST/US Gov requirements. > * SHA1 is maintained for backwards compatibility > * More secure hashing algorithms can be specified by defining the > functions to be used for 'User.set_password' and 'User.check_password' > as suggested above. > > To use SHA2-512 by default requires a larger password db column. That > might be reasonable and would be a better choice. Additionally we > could look into using Drepper's key strengthening algorithm of SHA2 by > default to make django brute-force resilient out of the box. It should > also be noted that an algorithm like bcrypt stores the salt in with > the hash and therefore the salt column is not used. > > It seems like we have people motivated to do the work. We need a > design decision made by a core dev that this is an acceptable > approach. > > -Paul > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Pluggable encryption for django auth (design proposal)
Carl and Russ, Thanks for the response! Would you prefer that those of us interested in working on this (pluggable user cryto-system) proceed from the trunk, or from 1.2? Thanks, William On Tue, Feb 15, 2011 at 2:03 AM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > On Tue, Feb 15, 2011 at 2:24 PM, Carl Meyer > wrote: > > Hi Paul, > > > > On Feb 14, 1:37 am, poswald wrote: > >> * Django ships with SHA2-256, SHA2-512 or PBKDF2 by default. SHA2 is > >> python 2.5 compatible (due to hashlib being added in python 2.5) and > >> PBKDF2 is short enough that it could be included into the project. > >> This satisfies NIST/US Gov requirements. > >> * SHA1 is maintained for backwards compatibility > >> * More secure hashing algorithms can be specified by defining the > >> functions to be used for 'User.set_password' and 'User.check_password' > >> as suggested above. > > > > I'm only one core dev, and not a crypto expert, but I've read the > > linked material and followed previous conversations, and here's my > > take: > > > > I don't think it's OK for Django to continue shipping with a default > > password hashing scheme which no crypto expert, as far as I've seen, > > considers adequate. People I trust to know their crypto, e.g. Thomas > > Ptacek of Matasano, consider PBKDF2 to be significantly better than > > salted SHA1 for password storage, if not quite as good as bcrypt. [1] > > PBKDF2 is simple enough (just SHA1 iterated many times) that including > > an existing pure-Python implementation in Django seems reasonable, > > removing the concerns about cross-platform and Python version > > compatibility. (It would still be best if we could get the PBKDF2 > > implementation reviewed by a cryptographer.) So I'm +1 on switching > > Django's default password hashing to PBKDF2. > > As with Carl -- I'm only one core dev, and I'm not a crypto expert, > here's my take: > > I agree that it's less than ideal for us to continue to use SHA1 given > it's known inadequacies. > > My concern with this approach is that it requires us to either > maintain or adopt an encryption algorithm. We're not just using > something from the standard library, we're taking responsibility for > the holes in a specific implementation. Even if we just adopt code > from an existing implementation, we are accepting responsbility for > finding and fixing any holes in that implementation. This is a > responsibility that can't be taken lightly, and I'm not completely > convinced that we should pick up that particular gauntlet. > > For this reason alone, I could be convinced that a configuration item > may be called for here -- e.g., registering a user-crypto library that > the default User object will use, in the same way that you can > currently register serialization libraries. > > However, that said: > > > As for the broader configurability question, I'm just fine with > > requiring a custom auth backend, which really isn't that hard, as a > > condition for customizing password hashing. So I'm not particularly > > tempted by proposals to add a new setting for this. The hardcoded > > stuff in the User model does bug me, though; I'm interested in the > > proposal to make the User model delegate that to new methods on an > > authentication backend (with backwards-compatibility fallback for old > > auth backends that don't have the new methods). > > One of the things that I want to tackle in the 1.4 timeframe is the > general problem of a 'pluggable' User model. Allowing for customizable > authentication schemes is one (of many) parts of this problem. Right > now, my focus is on getting the 1.3 release out the door; once the 1.4 > feature phase starts, I'll have a lot more time to discuss this sort > of thing. > > Yours, > Russ Magee %-) > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
