On Thu, Mar 15, 2012 at 4:49 PM, Carl Meyer <c...@oddbird.net> wrote: > Hi Daniel, > > On 03/15/2012 09:24 AM, Daniel Sokolowski wrote: >> Why can we not just increase the length limit on the username field?, >> Why can't we just throw a validation error if data entered is to long >> and the schema has not been updated? I think the answer yes we can and >> easily. > > I don't mean to pick on you specifically, but to me this is an excellent > example of a casual assertion of something we can "easily" do that > doesn't hold up under real examination (for instance, if you tried to > write the patch to actually do it). >
Why would anyone waste their time working on a patch that would be instantly rejected, as has been made patently clear throughout. The solution to these bugs is easy, it is just being ignored because it is 'too hard' to make these kinds of changes. Instead wishy-washy ways of completely rewriting authentication are dreamt up, planned, and then dropped. This is how I would fix it: 1) Fix the email length limit bug, and mark the field as a db index, but hide this by a settings hack, called CONTRIB_AUTH_EMAIL_FIX. If the settings hack is not set, raise a PendingDeprecationWarning 2) Add a management command 'auth_NN_inspectdb', NN being the version number, obviously. This command introspects the auth_user table, and determines if it needs changing, and prints out whether the table needs updating, which could include verbatim SQL statements for their engine. To cope with multiple databases, it takes a --database arg. 3) Add a management command 'auth_NN_updatedb'. This command introspects the auth_user table, and if it supports the engine, updates the DDL.To cope with mutliple databases, it takes a --database arg. 4) Add the following release notes: The contrib.auth.models.User model has increased the length of the email field to 254 characters, in order to allow all legal email addresses to be stored. In addition, the email field has been marked as a db index, in order to more easily allow email authentication. These changes are not made automatically by Django, sine they involve altering the structure of your database. Instead, you must enable this fix with by adding the settings.CONTRIB_AUTH_EMAIL_FIX. In addtion, there are two tools included to assist you inspect your database structure and migrate to the new structure. <description of auth_NN_inspectdb> <description of auth_NN_updatedb> If you do not want to make these changes, you can instead keep using 1.4 behaviour by not adding settings.CONTRIB_AUTH_EMAIL_FIX=True. You will receive a PendingDeprecationWarning when starting up, as this fix will soon become default. 5) Since this scares you all so much, bump version to 2.0 6) Once released, reverse the hack in trunk so that settings.CONTRIB_AUTH_NO_EMAIL_FIX gets you 1.4 behaviour, and warns a DeprecationWarning. 7) Add the following relnotes to 2.1 The contrib.auth.models.User schema changes originally introduced in 2.0 are now the default. If you still do not wish to migrate your database structure, you can keep using the 1.4 behaviour for now, by adding settings.CONTRIB_AUTH_NO_EMAIL_FIX=True to settings.py <info about migration commands from previous relnotes> If you do not either set settings.CONTRIB_AUTH_NO_EMAIL_FIX or update your database schema, then you will have problems when you encounter a user with an email address longer than 30 characters. The exact problem you will encounter depends upon your database: <description of what different databases do> I feel the amount of work involved here for your average django end user is minimal, certainly compared to things like adding csrf tokens throughout. It has been made abundantly clear that this approach would not be considered - in particular, using settings hacks to pragmatically achieve change - so why bother pushing it any further? I love a clean design as much as the next person, but not fixing bugs that exclude users on grounds of 'aesthetics' is pedantic and wrong. > How do you propose to "throw a validation error" if "the schema has not > been updated"? How do we know whether it's been updated? Are you > proposing that Django should introspect the users database table every > time it starts up in order to check the length of the username field? > Where would you put this introspection check? Have you considered the > effects this would have on every user of contrib.auth (both those who do > and don't run the schema migration)? And the effect on Django > development (needing to run the tests with both an "old" and "new" table > to ensure that the backwards-compatibility handling is tested?) This is a bug, and fixing it will affect lots of Django users. I'm fed up of this excuse being used to avoid fixing it. You seem to take the view that change is too hard, and therefore we should not do this until we have a magical solution that is all things for all men. Personally, I take the view that every single django site out there is broken for 'maria.hernandez.gonza...@lar.longcorpname.com', has been for a long time, and sweet FA has been done to fix it. That view says fix it, fix it now, because I want to be paid by the lovely Maria, not exclude her. I'm fed up of core devs saying that my paying users aren't important enough to fix such a minor bug, for fear of causing issues for little Johnny's blog. Cheers Tom PS: FYI, on my django based SAML identity provider, which provides SAML authentication for my companies network of 150+ sites has these stats for the length of users email addresses: mysql> select length(email) > 30 as long_email, count(*) from auth_user group by 1; +------------+----------+ | long_email | count(*) | +------------+----------+ | 0 | 150493 | | 1 | 33531 | +------------+----------+ I'm not talking about some silly edge case that catches 0.001% of users. 18% of my paying users have issues, if they visit a django site made by one of my colleagues that has not been fixed to accept longer email addresses. -- 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.
