On Tuesday, 5 April 2022 at 19:34:54 UTC+5:30 jacob...@gmail.com wrote:
>
>- Django doesn't have to store any state of users and/or IP addresses
>attempting to log in
>
> We would still have to keep track of the rate of requests made by each
user and/or IP if we want to respond with a >
Hello Jason,
Thanks for your answer.
First I apologize because my webmail removed all indentation from
class EnhancedQuerySet:
Thus it may not be easily understood without taking the time to reindent it.
I created it here : https://djangosnippets.org/snippets/10867/
so that everyone can easily
Sandeep - it's best to report bugs as tickets.
Anyway, I checked this out for you and I don't see the problem. I started a
project, and added the code you suggested as models, ran makemigrations,
and saw this error:
$ ./manage.py makemigrations core
SystemCheckError: System check identified some
How about this proposal?
Someone opens the login page. In addition to the visible
fields username and password and the hidden field csrftoken we add another
hidden field. This field contains the earliest (server-)timestamp a user
might login, and lies in the near future, for instance now() +
what if we just logg the key to python django level to retrieve logging
info...?
On Tue, Apr 5, 2022 at 6:55 AM Dan Swain wrote:
> The current Django LOGGING setup requires a string for the "level". This
> is not intuitive since the Python logging module defines logging.DEBUG,
> logging.INFO,
On Tue, 5 Apr 2022, at 09:26, Dan Swain wrote:
> The current Django LOGGING setup requires a string for the "level". This is
> not intuitive since the Python logging module defines logging.DEBUG,
> logging.INFO, etc. I think one should be able to configure the logging level
> using {
Django doesn't require a string for log level. The contents of the LOGGING
setting are passed directly to the callable in LOGGING_CONFIG, which
defaults to logging.config.dictConfig, which takes numbers.
Demo:
In [1]: import logging
In [2]: from django.conf import settings
In [3]: import
