form validation in contrib.auth

[Jens Diemer]

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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/mis98k%24n71%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Re: SSL support for Django-admin runserver‏

[Florian Apolloner]

Hi,

On Tuesday, May 12, 2015 at 4:43:41 AM UTC+2, Steven Berry wrote:
>
> On Monday, May 11, 2015 at 6:30:39 PM UTC-4, Florian Apolloner wrote:
>
>>
>> On Monday, May 11, 2015 at 10:13:03 PM UTC+2, Steven Berry wrote:
>>>
>>> With all that said I'm in favor of what you suggest -- rely on gunicorn 
>>> where possible. However I don't think what I'm suggesting (and have already 
>>> implemented) fundamentally interferes with #21978. As far as I can tell the 
>>> django.core.servers.basehttp module exists solely for the runserver 
>>> command. 
>>> And the contents therein aren't so much of a homegrown webserver as they 
>>> are convenient subclasses to Python's inherent wsgiref.simple_server. 
>>> The onus of maintenance lies largely in the Python codebase.
>>>
>>
>> It might not interfere,  but there are already perfectly fine 
>> alternatives like stunnel which provide you with TLS support. So unless 
>> there is a really compelling argument to TLS support to runserver itself 
>> (which I yet fail to see in this thread), I am -0 to -1. Keeping the code 
>> as simple as possible also makes migrations to a 3rd party server easier 
>> later on.
>>
>
>
> Florian, by that logic what's the point of having runserver in the first 
> place? There are already perfectly fine alternatives that serve web 
> content. What I was suggesting was moving something that is half-baked to 
> something that's at least 60% baked while still taking advantage of what 
> runserver does well. The trick, which I touched on in my second post, and 
> which I think Tim addressed, is identifying what your intended scope is 
> here. If the goal is to deprecate runserver entirely then I agree with 
> you. But that intention hasn't been made clear, and what we're left with is 
> a crippled webserver with a bit of an identity crisis.
>

At the time Django started there where not many perfectly fine alternatives 
(if at all) to easily run a python webapp during development. And just 
because something is already there, does not mean it should be used as an 
argument for adding more stuff to it. And I am not really sure about the 
identity crisis, it does what it is supposed to easy and well during dev.

Cheers,
Florian

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/91426269-26fe-4490-8236-9852c5254247%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: SSL support for Django-admin runserver‏

[Steven Berry]

Florian,

I was merely presenting a rhetorical question to illustrate a point. 
Perhaps there weren't other available web servers then, but there are now, 
as has been pointed out. Prevalence and expectation of TLS/SSL is another 
thing that's changed since 2005. We can choose to maintain runserver and 
keep it up to date with modern standards, abandon it, or leave it alone to 
effectively abandon it.

So far we've demonstrated that we have an interest in maintaining runserver 
supported 
by:

   - The existence of https://code.djangoproject.com/ticket/21978
   - The fact that runserver has not been deprecated (nor are there any 
   warnings of future deprecation)
   
We also have demonstrated that we have no interest in maintaining runserver 
supported 
by the apparent direction of this discussion.

I'm fine with either case, but therein lies the so-called identity crises 
and the origination of my confusion.

As a developer using Django, I've long been directed toward runserver for 
development in the documentation yet it falls short of modern expectations. 
Which 
brings me back to my current, fundamental point.

*We should update runserver or update the documentation to more clearly 
address modern, third-party alternatives and how to resolve them with 
desirable development features (e.g. serving static files from app 
directories).*

I am willing to put in the work in any case, but I cannot do so without a 
decision and a ticket.

At any rate, Gert, thank you for the gunicorn suggestion from Saturday. 
This meets my needs after some adjustment to my wsgi module (I needed to 
include my requisite sys.path modifications so I moved them from my 
passenger_wsgi 
module).

Regards,
Steven

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/349614b8-14c2-42a6-8d46-af0bb7dd3b66%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrations in Django 1.7 make unit testing models harder

[Pradeek J]

I'm facing the same speed issue here. Like Andrew mentioned above, if 
initial data is going to be removed and data migrations are the way 
forward, even having an option to skip migrations is a problem because we'd 
need that data to be populated. Is there something planned for this for 
Django 1.9? 

On Saturday, December 27, 2014 at 8:10:10 PM UTC+5:30, Tim Graham wrote:
>
> In pull request 3791 , I 
> started working on the code removals for Django 1.9 to better understand 
> how the database/migrations code will look and what APIs we still need to 
> deprecate. The good news is that we can keep support for apps without 
> migrations (at least for Django's test suite) without adding any additional 
> code or using any deprecated database creation APIs (as Claude suggested 
> earlier). If you look at the commit "Removed supported for syncing apps 
> without migrations" in that PR, you'll see "Run the syncdb phase" remains 
> in the migrate management command, but now it'll only be executed when 
> testing (and it's also quite a bit simplified due to other removals like 
> support for initial data). It seems like it should be pretty simple to 
> implement something similar to the old *SOUTH_TESTS_MIGRATE* setting in 
> order to allow disabling migrations for all apps when testing if we wanted 
> to go that route. I think the remaining deprecations to move forward with 
> ticket 
> #22340  (Legacy Table 
> Creation Methods Not Properly Deprecated) are straightforward and will 
> leave a comment there about it.
>
> On Saturday, December 20, 2014 2:18:17 PM UTC-5, Aymeric Augustin wrote:
>>
>> There's django-admin test --keepdb for this purpose (in Django 1.8).
>>
>> -- 
>> Aymeric.
>>
>> Le 20 déc. 2014 à 18:41, Bernard Sumption  a 
>> écrit :
>>
>> A proposition: the problem isn't that migrations take 80 seconds, it's 
>> that this 80 seconds is repeated every time a developer runs tests. How 
>> about serialising the structure and content of the database to disk after 
>> applying migrations, then whenever you need a migrated test database, load 
>> it from disk unless the migration files have been altered since the 
>> serialised version was created?
>>
>> Bernie :o)
>>
>> On 20 December 2014 at 10:52, Andrew Godwin  wrote:
>>>
>>> Clause, I believe that line is to allow people to run makemigrations 
>>> when AUTH_USER_MODEL points to an app that doesn't yet have migrations; 
>>> before, it would fail hard, as the AUTH_USER_MODEL was not in the migrate 
>>> state and so nothing could use it, and you couldn't run makemigrations to 
>>> create it as it would error out.
>>>
>>> I'd test variations of that to see if your patch still works; if not, 
>>> we'll need a workaround again.
>>>
>>> Andrew
>>>
>>> On Sat, Dec 20, 2014 at 10:47 AM, Claude Paroz  
>>> wrote:

 On Friday, December 19, 2014 6:30:32 PM UTC+1, Tim Graham wrote:
>
> Yes. Claude has worked on the deprecation in 
> https://github.com/django/django/pull/3220 but it requires adding 
> more migrations to our test suite and he noted that each migration we add 
> to Django's test suite adds up to ~3.5 seconds to the run time of the 
> test 
> suite. He also worked on some speed ups to mitigate this in 
> https://github.com/django/django/pull/3484 but there are some 
> unsolved issues.
>

 I think that the first mentioned patch I worked on (PR 3220) shows that 
 it should be possible to use the new schema infrastructure without 
 requiring migrations, at least for apps that don't depend on other 
 migrated 
 apps. Tell me if I miss anything.

 But surely, I'd really like to solve first the speed issue of 
 migrations (#23745, PR 3484). Chris, if you have the opportunity to test 
 that patch with your database, it would be great. The way forward for this 
 patch is to first test the "if app_label == settings.AUTH_USER_MODEL 
 and ignore_swappable:" line which is currently not tested and is 
 probably not addressed by my patch. Andrew, do you remember why you 
 introduced that part of the code?

 Claude

 -- 
 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 django-develop...@googlegroups.com.
 To post to this group, send email to django-d...@googlegroups.com.
 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/1f5f37b2-5309-4af6-8b3c-aa76eee3bde1%40googlegroups.com
  
 
 .