1. I don't see much benefit to adding a max length for one form (AuthenticationForm) to give some sense of security as opposed to properly addressing the issue at the webserver level. As Paul said, "As documented in the deployment docs, it is your responsibility as the deployer to limit post bodies to a size which is reasonable for your server. Otherwise, a user can make very large post requests to any view at all, which may overwhelm other parts of your web stack as well. 4k is a commonly accepted good starting point for forms which do not expect file upload; you will have to tune file upload forms to match your needs depending on how they're processed."
2. AuthenticationForm is intentionally generic to allow it to be used with custom user models which may have different restrictions on the user name. 3. What's the use case? I'm not sure the signal without any credentials would be of much value. Anyway, it shouldn't be difficult to write your own login() view with the behavior you desire if we don't make a change in Django. On Tuesday, May 12, 2015 at 3:14:56 AM UTC-4, Jens Diemer wrote: > > > The default auth.form.AuthenticationForm() did not set a max_length for > the > password field: > > > https://github.com/django/django/blob/72f6513ebaa7a3fd43c26300e9a8c430dc07cdb5/django/contrib/auth/forms.py#L120-L126 > > > Ok there is not really a max_length constraint. Because in the end the > auth.models.User must only store the hash value. > > The available hashers will consume more RAM if the password is very long. > (The > CPU usage is very similar to a short password) > Only if the server has a POST data limit, the password size is limited. > But it > seems that POST limits are not set or very large on default > installations... > > > On the other side: I didn't see any side effects with a limitation e.g.: > max_length=1024 > > > > > Another thing: The auth.models.AbstractUser has the 'username' field with > max_length=30 and validators.RegexValidator(r'^[\w.@+-]+$',...) > > The AuthenticationForm has max_length=254 and no validator... > > > > IMHO one principle is: Validate incoming data as soon as possible, isn't > it? > > > > Next thing is "auth.signals.user_login_failed" > > This signal will only fired if the auth backends was called. > IMHO it should be called on every failed login. Also if the form is not > valid. > > > > > > > -- > > > Mfg. > > Jens Diemer > > > ---- > http://www.jensdiemer.de > > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0f7eacf2-c7b8-4599-a708-546daa249413%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
