Re: Configuration of "level" in LOGGING

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

Re: Configuration of "level" in LOGGING

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

Re: Configuration of "level" in LOGGING

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

Re: Configuration of "level" in LOGGING

How would this work with secret stores like hashicorp vault, aws secrets manager? Or even via environment variables? This approach would work if you define the logging level in your configuration, but not so friendly for other approaches. On Monday, April 4, 2022 at 9:26:02 PM UTC-4 Dan

Configuration of "level" in LOGGING

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 { 'level': logging.DEBUG } rather than being requi

Re: To keep or not to keep: logging of undefined template variables

ct.com/ticket/28526) - which links this thread. > > Having read the various replies, it seems like there is no shortage of > differing views how missing/invalid variables should be treated: > - There should be no logging > - There should be logging, but full tracebacks are too no

Re: To keep or not to keep: logging of undefined template variables

I was going to have a go at this ticket (https://code.djangoproject.com/ticket/28526) - which links this thread. Having read the various replies, it seems like there is no shortage of differing views how missing/invalid variables should be treated: - There should be no logging - There should

Re: Logging in from one browser logs me out from other browsers (after any change in PBKDF2PasswordHasher.iterations)

On Thursday, September 3, 2020 at 11:10:39 AM UTC+2 Adam Johnson wrote: > You could also move to use the Argon2 hasher, which does not have any > chagnes between versions to log out users: > https://docs.djangoproject.com/en/3.0/topics/auth/passwords/#using-argon2-with-django > Or a custom

Re: Logging in from one browser logs me out from other browsers (after any change in PBKDF2PasswordHasher.iterations)

You could also move to use the Argon2 hasher, which does not have any chagnes between versions to log out users: https://docs.djangoproject.com/en/3.0/topics/auth/passwords/#using-argon2-with-django It's also considered more secure. As the docs say: Argon2 is not the default for Django because

Re: Logging in from one browser logs me out from other browsers (after any change in PBKDF2PasswordHasher.iterations)

> On 3 Sep 2020, at 10:57, Tom Forbes wrote: > > You might have a point regarding the frequency of bumping the PBKDF iteration > setting. Is bumping it 5 times in 13 months really required? It was more like 40 months. For 1.11: May 20, 2016

Re: Logging in from one browser logs me out from other browsers (after any change in PBKDF2PasswordHasher.iterations)

On Thu, Sep 3, 2020 at 11:57 AM Tom Forbes wrote: > You might have a point regarding the frequency of bumping the PBKDF > iteration setting. Is bumping it 5 times in 13 months really required? On > the other hand you might want to consider staying on the LTS releases and > avoid issues such as

Re: Logging in from one browser logs me out from other browsers (after any change in PBKDF2PasswordHasher.iterations)

Hi, To conclude, I think it would be better to change the number of iterations not every 8 months, but every 2 years (with a new LTS release). אורי u...@speedy.net On Thu, Sep 3, 2020 at 10:29 AM Florian Apolloner wrote: > I do not think there is anything to reopen because it works as

Re: Logging in from one browser logs me out from other browsers (after any change in PBKDF2PasswordHasher.iterations)

You might have a point regarding the frequency of bumping the PBKDF iteration setting. Is bumping it 5 times in 13 months really required? On the other hand you might want to consider staying on the LTS releases and avoid issues such as this, and the issue you’re describing is quite niche.

Re: Logging in from one browser logs me out from other browsers (after any change in PBKDF2PasswordHasher.iterations)

Hi, On Thu, Sep 3, 2020 at 11:23 AM Shai Berger wrote: > > Please be aware that this is a security issue. The passwords are > encrypted as protection for the case that they fall into the hands of > an attacker, but for this protection to be effective, it must stay hard > and costly to

Re: Logging in from one browser logs me out from other browsers (after any change in PBKDF2PasswordHasher.iterations)

Hi Uri and all, On Thu, 3 Sep 2020 08:37:42 +0100 Adam Johnson wrote: > I agree with Florian. > Me too. > The occasional forced logout is probably fine. If you care about this > enough Uri, you could write a blog post documenting your patch and > how to use it when upgrading Django. > But:

Re: Logging in from one browser logs me out from other browsers (after any change in PBKDF2PasswordHasher.iterations)

I agree with Florian. The occasional forced logout is probably fine. If you care about this enough Uri, you could write a blog post documenting your patch and how to use it when upgrading Django. On Thu, 3 Sep 2020 at 08:29, Florian Apolloner wrote: > I do not think there is anything to reopen

Re: Logging in from one browser logs me out from other browsers (after any change in PBKDF2PasswordHasher.iterations)

I do not think there is anything to reopen because it works as designed. Password changes cause other browser sessions to be terminated because the session auth hash no longer matches. You can use a custom user model and override `get_session_auth_hash` but the defaults won't change, sorry.

Logging in from one browser logs me out from other browsers (after any change in PBKDF2PasswordHasher.iterations)

Django developers, I would like to reopen #31970 . In short, the problem is - if a user is logged in with more than one browser, and when we upgrade Django to any version which *PBKDF2PasswordHasher.iterations* changes (which is *any* new version), and

Re: Deadlock bug in logging? Reproducible case

Nah, I'm good — but thank you! On Friday, April 24, 2020 at 8:57:09 AM UTC-4, René Fleschenberg wrote: > > Hi, > > On 4/23/20 12:20 PM, Adam Johnson wrote: > > What version of Python René? > > I tested with 3.6.7. I can test with other versions, if that helps. > > Regards, > René > > > >

Re: Deadlock bug in logging? Reproducible case

Hi, On 4/23/20 12:20 PM, Adam Johnson wrote: > What version of Python René? I tested with 3.6.7. I can test with other versions, if that helps. Regards, René -- René Fleschenberg -- You received this message because you are subscribed to the Google Groups "Django developers

Re: Deadlock bug in logging? Reproducible case

True, I did notice it needed some more tweaking. I've got a long evening of rewriting years' worth of wsgi.py's and Apache configs ahead of me. I'll probably just jump straight to the envparse approach because (as you noted) my celery env var handling was making the WSGI approach moot anyway.

Re: Deadlock bug in logging? Reproducible case

Actually that might not work entirely, since your settings file will be imported before the environment variables are copied over. Instead you can lazily construct the django application on the first request: django_application = None def application(environ, start_response): global

Re: Deadlock bug in logging? Reproducible case

Beautiful. That does the trick. Thank you! And I certainly can see there's plenty of other approaches such as envparse or django-environ that I could be using, that keeps the vars out of my Apache config. Quick fix and a slighly longer better fix. This'll change how I do all my new projects

Re: Deadlock bug in logging? Reproducible case

ots of threads all trying to acquire a >> lock. Some are trying to log at the end of the request: >> >> Thread 0x00007cecf000 (most recent call first): >> File >> "/Users/chainz/.pyenv/versions/3.8.2/lib/python3.8/logging/__init__.py", >> line 221 in

Re: Deadlock bug in logging? Reproducible case

FYI, here's where that approach came from -- http://ericplumb.com/blog/passing-apache-environment-variables-to-django-via-mod_wsgi.html > > It's the top hit for "django apache environment variable" Which is literally an old friend of mine from grade school. Maybe that's a red flag ... -- You

Re: Deadlock bug in logging? Reproducible case

cent call first): > File > "/Users/chainz/.pyenv/versions/3.8.2/lib/python3.8/logging/__init__.py", > line 221 in _acquireLock > File > "/Users/chainz/.pyenv/versions/3.8.2/lib/python3.8/logging/__init__.py", > line 1687 in isEnabledFor > File &

Re: Deadlock bug in logging? Reproducible case

" process. This ended with a traceback with lots of threads all trying to acquire a lock. Some are trying to log at the end of the request: Thread 0x7cecf000 (most recent call first): File "/Users/chainz/.pyenv/versions/3.8.2/lib/python3.8/logging/__init__.py", line 22

Re: Deadlock bug in logging? Reproducible case

Tom > > On 23 Apr 2020, at 12:40, Brian Tiemann > > wrote: > > It also happens in 3.6.9, which is my prod environment. > > FWIW, by way of background context, this is not a heavily used app, not > enough so to warrant logging to a custom buffered consumer or re

Re: Deadlock bug in logging? Reproducible case

t; FWIW, by way of background context, this is not a heavily used app, not > enough so to warrant logging to a custom buffered consumer or remote agent. > It's just a small office using it. But the main home view's UI has 5 AJAX > calls that cause the site to lock up on a regular basis, suc

Re: Deadlock bug in logging? Reproducible case

It also happens in 3.6.9, which is my prod environment. FWIW, by way of background context, this is not a heavily used app, not enough so to warrant logging to a custom buffered consumer or remote agent. It's just a small office using it. But the main home view's UI has 5 AJAX calls that cause

Re: Deadlock bug in logging? Reproducible case

Hi — Thanks for looking into this. Adam, I skipped over details like the Python version because I noted them in the readme on my gitlab demo. But I was using Python 3.7.2 for the record. I used "deadlock" because my digging into this had previously turned up https://bugs.python.org/issue6721 ,

Re: Deadlock bug in logging? Reproducible case

ll, further requests > are not getting processed. I can reproduce it when logging to the > console, so I don't think disk I/O is the problem. It might still be a > problem in the Python stdlib, of course. > > -- > René > > -- > You received this message because you are s

Re: Deadlock bug in logging? Reproducible case

minated. But I presume you're experiencing more of a "standstill" and > future requests no longer work? I was able to reproduce this. It leads to a standstill, further requests are not getting processed. I can reproduce it when logging to the console, so I don't think disk I/O is the p

Re: Deadlock bug in logging? Reproducible case

ill" and future requests no longer work? Additionally you don't describe your Python version. Since logging is part of the Python standard library (and you're not using any extensions) any logging issues you're seeing are part of Python, and may be fixed on later versions. Minor versions contai

Re: Deadlock bug in logging? Reproducible case

This is more an issue at the file system level and the hardware not being able to keep up rather than anything Django is doing. It's the same fundamental principal for why you may turn off webserver logging to increase performance, writing to disk is expensive and so when dealing with high

Re: Deadlock bug in logging? Reproducible case

Sorry - that message was sent as a 'reply' in error - my colleague uses ajax with Django a lot and I was trying to forward this to him. Kind Regards, Dave On Wed, 22 Apr 2020 at 18:23, Brian Tiemann wrote: > Hi all, > > I was directed here after getting corroboration on #django and

Re: Deadlock bug in logging? Reproducible case

FYI Sent from my iPhone > On 22 Apr 2020, at 18:23, Brian Tiemann wrote: > >  > Hi all, > > I was directed here after getting corroboration on #django and elsewhere. > > I have what appears to be a bug in which a Django app can deadlock if you hit > it with a lot (>3) of AJAX requests

Deadlock bug in logging? Reproducible case

Hi all, I was directed here after getting corroboration on #django and elsewhere. I have what appears to be a bug in which a Django app can deadlock if you hit it with a lot (>3) of AJAX requests within a short time (i.e. all triggered in parallel from a single HTML page). I have a

Re: handle_uncaught_exception error logging

Hrm. Thanks for the link... probably not going to end up being a Django issue. I will report back if it is. On Sunday, April 12, 2020 at 10:25:07 AM UTC-4, Tim Graham wrote: > > The relevant commit might be > https://github.com/django/django/commit/10b44e45256ddda4258ae032b8d4725a3e3284e6.

Re: handle_uncaught_exception error logging

The relevant commit might be https://github.com/django/django/commit/10b44e45256ddda4258ae032b8d4725a3e3284e6. That change was made in Django 2.1. You didn't say what version of Django you're using. You'll have to give more details about your case and what's behaving differently. On Sunday,

handle_uncaught_exception error logging

Why was the error log removed from handle_uncaught_exception? I didn't find mention about it but I've recently encountered a middleware causing a 500 error and not getting a traceback log was unexpected. https://github.com/django/django/blob/stable/2.0.x/django/core/handlers/exception.py#L115

Re: Logging in management commands

Hello Christian, I don't have an exact answer for you but there's open tickets about making management commands use logging instead of custom output wrappers that might interest you. Simon [0] https://code.djangoproject.com/ticket/21429 [1] https://code.djangoproject.com/ticket/27877 Le

Logging in management commands

Hi, i just stumbled upon logging in management commands I saw that there is an own system of logging. When creating custom mgmt cmds, you have to write logging output to     if options["verbosity"] >= 2:         sys.stdout.write(message) this is a little inconvenient, and much le

Re: Add logging to related descriptors

But I think > a useful way Django could easily doing more to help debug applications is > to simply add some DEBUG-level logging whenever a related instance gets > fetched. > > The idea would be add logging calls in the `__get__` methods of related > descrip

Re: Add logging to related descriptors

t through another mechanism? :) >> > > I don't expect them to. The logging is for me, the consultant hired to > find why their code is slow :P > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)&

Re: Add logging to related descriptors

On Tuesday, May 28, 2019 at 11:48:11 AM UTC-5, James Bennett wrote: > > > I guess my question is: if your devs won't check this in tests, why do you > expect they'll check it through another mechanism? :) > I don't expect them to. The logging is for me, the consultant hir

Re: Add logging to related descriptors

On Tue, May 28, 2019 at 9:30 AM Flavio Curella wrote: > But there are many situations where a N+1 can get created and people > usually have don't write tests for (even if they should have). For example, > assume this model: > I guess my question is: if your devs won't check this in tests, why

Re: Add logging to related descriptors

# admin.py admin.site.register(Book) ``` You shouldn't write a `__str__` that way in the first place, but in my experience I've seen way more `__str__` methods accessing related fields than tests checking `assertNumQueries` against admin views. Some additional logging would help me spot this issues before writing

Re: Add logging to related descriptors

Have you looked at the assertNumQueries assertion? https://docs.djangoproject.com/en/2.2/topics/testing/tools/#django.test.TransactionTestCase.assertNumQueries This can let you assert the expected queries and break your tests if someone accidentally introduces an N+1. -- You received this

Add logging to related descriptors

m the user side. But I think a useful way Django could easily doing more to help debug applications is to simply add some DEBUG-level logging whenever a related instance gets fetched. The idea would be add logging calls in the `__get__` methods of related descriptors: * https://github.com/dja

Re: django logging - `ServerFormatter.uses_server_time()` forces users to use `{` logging style

t; >> I encountered some troubles with django logging configuration during the >> update from Django 1.11 to 2.1. This issue was related to this commit >> <https://github.com/django/django/commit/3af305e8b8a89f4b0e5874cd601568ab8dcd7334> >> and >> generally `Ser

Re: django logging - `ServerFormatter.uses_server_time()` forces users to use `{` logging style

I'm not opposed to a patch to address your use case. On Thursday, February 7, 2019 at 6:34:23 AM UTC-5, Łukasz Skarżyński wrote: > > Hello, > > I encountered some troubles with django logging configuration during the > update from Django 1.11 to 2.1. This issue was related

django logging - `ServerFormatter.uses_server_time()` forces users to use `{` logging style

Hello, I encountered some troubles with django logging configuration during the update from Django 1.11 to 2.1. This issue was related to this commit <https://github.com/django/django/commit/3af305e8b8a89f4b0e5874cd601568ab8dcd7334> and generally `ServerFormatter.uses_server_time()`

Re: To keep or not to keep: logging of undefined template variables

>> >> I'm still not sure what the solution should be, but I created #28526 [1] >> to track this problem: finding a remedy to the problem of verbose, often >> unhelpful logging of undefined variables. >> >> I don't think "the end goal of err

Re: To keep or not to keep: logging of undefined template variables

problem of verbose, often > unhelpful logging of undefined variables. > > I don't think "the end goal of errors raising when using undefined > variables" is feasible. My sense is that relying on the behavior of > undefined variables is too entrenched in the Django temp

Re: To keep or not to keep: logging of undefined template variables

ndering an admin changelist page [0]. >> >> I'm still not sure what the solution should be, but I created #28526 [1] >> to track this problem: finding a remedy to the problem of verbose, often >> unhelpful logging of undefined variables. >> >> I don't think &

Re: To keep or not to keep: logging of undefined template variables

dy to the problem of verbose, often > unhelpful logging of undefined variables. > > I don't think "the end goal of errors raising when using undefined > variables" is feasible. My sense is that relying on the behavior of > undefined variables is too entrenched in the D

Re: To keep or not to keep: logging of undefined template variables

We received a report that shows the large number of undefined variable warnings when rendering an admin changelist page [0]. I'm still not sure what the solution should be, but I created #28526 [1] to track this problem: finding a remedy to the problem of verbose, often unhelpful logging

Re: To keep or not to keep: logging of undefined template variables

much effort this would take, but it would definitely make the logging a lot more user + developer friendly. On 20 June 2017 at 08:48, Vlastimil Zíma <vlasti...@ziima.cz> wrote: > -1 to the removal. I was annoyed by the logging at first, but then I > started to clean individual logs. Half

Re: To keep or not to keep: logging of undefined template variables

-1 to the removal. I was annoyed by the logging at first, but then I started to clean individual logs. Half way through, I found several usages of long removed variables, one unused template (as a side effect) and I updated several views to always provide defined context variables. All in all

Re: To keep or not to keep: logging of undefined template variables

On Thursday 16 March 2017 12:03:07 Tim Graham wrote: > Ticket #18773 [0] added logging of undefined template variables in > Django 1.9 [1], however, I've seen several reports of users finding > this logging more confusing than helpful. With channels hitting 2.0 and the already la

Re: To keep or not to keep: logging of undefined template variables

to be missing e.g.: {% if foo? %} {{ foo? }} This would clearly be a big change though. Luke On 16/03/17 22:03, Tim Graham wrote: Ticket #18773 [0] added logging of undefined template variables in Django 1.9 [1], however, I've seen several reports of users finding this logging more confusing

Re: To keep or not to keep: logging of undefined template variables

Doesn't sound like there's much impetus either way, and it's confusing people, so I'd say remove it. Or maybe make it optional, default off? On 19 March 2017 at 07:52, Tim Martin wrote: > I don't have any objection to removing this. However, the thought occurs > that my

Re: To keep or not to keep: logging of undefined template variables

I don't have any objection to removing this. However, the thought occurs that my patch to the handling of undefined variables could enhance this to make it more useful. I think we could log in the case where a conditional expression actually depends on an undefined variable. I haven't thought

To keep or not to keep: logging of undefined template variables

Ticket #18773 [0] added logging of undefined template variables in Django 1.9 [1], however, I've seen several reports of users finding this logging more confusing than helpful. For example, admin templates log errors about missing is_popup variables [2] which is how the template are designed

Re: Logging config tries too hard

I had troubles understanding the logging setup the first time, but after that, its quite simple on every project. I usually end up copy/pasting some console and db logger class and just add it to the config, I don't really think it is that difficult El martes, 6 de septiembre de 2016, 9:57:16

Re: Logging config tries too hard

om/en/dev/internals/release-process/#deprecation-policy As it applies to this case, basically we need to ensure that people's existing logging config continues to function as it does now in the next release of Django. If they need to make updates to their settings in order to preserve the same logging

Re: Logging config tries too hard

Le vendredi 9 septembre 2016 07:31:42 UTC+2, Ivan Sagalaev a écrit : > I think the best end result would be one where LOGGING simply defines the >> full config and it is always applied (by Django) exactly once, and the >> defaults we want are set as the global default for LO

Re: Logging config tries too hard

Carl, I think this is the thread with your past comments: https://groups.google.com/d/topic/django-developers/no2IhnRty68/discussion To avoid a new setting, we could add some custom key/value to LOGGING for the new behavior and pop it before the dict is passed to dictConfig. On Tuesday

Re: Logging config tries too hard

On 09/06/2016 04:57 PM, Ivan Sagalaev wrote: > I'm > talking about this function: > https://github.com/django/django/blob/master/django/utils/log.py#L66 > > When `LOGGING_CONFIG` isn't explicitly disabled it first unconditionally > initializes logging with the hard-c

Re: Logging config tries too hard

> > Just to be sure, which version of Django are you using? There were some > simplifications in Django 1.9 that attempted to make writing custom logging > configurations easier and further changes in Django 1.10. > I'm using 1.9, but I'm referring to the code in master

Re: Logging config tries too hard

> > It’s unclear to me as well how the current system is intended to be used. > I can speculate, that the idea was that you *can* disable the existing loggers and define your own, but the effect of it actually disabling all logging from Django instead of it falling through to the cu

Re: Logging config tries too hard

Just to be sure, which version of Django are you using? There were some simplifications in Django 1.9 that attempted to make writing custom logging configurations easier and further changes in Django 1.10. https://github.com/django/django/commit/8efea1b8d5b5fb0cfef1a3244c339cebf8af36c5 https

Re: Logging config tries too hard

It’s unclear to me as well how the current system is intended to be used. All my projects do this: > # Configure logging manually to avoid merging with Django's defaults. > > LOGGING = { > # custom logging configuration goes here > } > > logging.conf

Logging config tries too hard

Hello everyone, It's been a while since I last posted here, please forgive if I break any new rules inadvertently. I'd like to revisit a decision made in [18993][]. My use case is very simple and obvious: I want all logging going into stdout. As currently implemented, I can't do it easily

Re: Middleware error framework, high level logging for database queries

this can readily grow outside django, until it's matured. (2) High level logging for database queries. We've currently monkey-patched a system to add the following information to our log lines: ... 52ms (db: 4ms/8q) /url ... Some years back I wrote some middleware to do just

Middleware error framework, high level logging for database queries

ome logging and error checking): class JsonErrorHandler(object): def process_exception(self, request, exception): if hasattr(exception, 'to_json_error_msg') and callable(exception.to_json_error_msg): # json_error just dumps the arguments as JSON and puts it into an HttpRespo

Re: Tracking/logging bruteforcing, especially on admin accounts?

Le vendredi 20 mai 2016 02:44:41 UTC+2, Josh Smeaton a écrit : > > I understand the reasoning for "use the cache", but not every site has > caching enabled, especially lots of smaller sites. > That's not true. When not specified, the cache backend default to the local memory cache:

Re: Tracking/logging bruteforcing, especially on admin accounts?

I understand the reasoning for "use the cache", but not every site has caching enabled, especially lots of smaller sites. A separate table could be used for tracking attempts, and cleared out per user on successful login attempt/ip address. This table would not need to be huge if designed with

Re: Tracking/logging bruteforcing, especially on admin accounts?

On Thursday, May 19, 2016 at 1:57:50 PM UTC+2, Aymeric Augustin wrote: > > Django’s “last_login” field in the user model is a common cause of > performance issues in large sites. (I believe it’s required to secure > password resets so we can’t remove it.) Let’s avoid adding more fields with >

Re: Tracking/logging bruteforcing, especially on admin accounts?

y more useful — assuming the generalization doesn’t make the problem intractable. You should look at prior art such as django-ratelimit-backend. > I am proposing a solution broken into two parts - tracking and enforcing. > > Tracking - End goal would be logging SuspiciousOperation

Re: Tracking/logging bruteforcing, especially on admin accounts?

I am proposing a solution broken into two parts - tracking and enforcing. > > Tracking - End goal would be logging SuspiciousOperation if appropriate > thresholds were crossed. We’d need to store server-side state. I don’t > believe we don’t have a clean heap data structure across all

Re: feature request - use logging in WSGIRequestHandler

FWI a new ticket[1] with what looks like a sane implementation to add this level of logging to the runserver command has been created. I'll make sure to copy all the concerns raised by Russ over there and you might want to chime in the review process. Simon [1] https://code.djangoproject.com

Re: naming of a new test client method for logging in

Okay, it seems I'm in the minority with my preference for login_user(). I've committed the patch with force_login(). Thanks for the feedback. On Tuesday, June 30, 2015 at 4:34:11 PM UTC-4, Berker Peksag wrote: > > On Tue, Jun 30, 2015 at 4:38 PM, Tim Graham > wrote: > >

Re: naming of a new test client method for logging in

On Tue, Jun 30, 2015 at 4:38 PM, Tim Graham wrote: > There's a proposal [1] to add a new method to the test client that works > like login(), but skips the authentication (no credentials need to be > provided) and verification (is_active=False can login) steps. The signature

Re: naming of a new test client method for logging in

I second Andriy's comment. /Markus On Tue, Jun 30, 2015 at 04:41:06PM +0300, Andriy Sokolovskiy wrote: force_login() seems to be more clear what it going on inside On 6/30/15 16:38, Tim Graham wrote: There's a proposal [1] to add a new method to the test client that works like login(), but

Re: naming of a new test client method for logging in

force_login() seems to be more clear what it going on inside On 6/30/15 16:38, Tim Graham wrote: > There's a proposal [1] to add a new method to the test client that works > like login(), but skips the authentication (no credentials need to be > provided) and verification (is_active=False can

naming of a new test client method for logging in

There's a proposal [1] to add a new method to the test client that works like login(), but skips the authentication (no credentials need to be provided) and verification (is_active=False can login) steps. The signature is (user, backend=None). What would you name this method? Proposals so far:

Re: improving debug logging in development

hat within the got_request_exception signal; not sure if it would work in the logging framework. Collin On Thursday, March 26, 2015 at 5:58:43 AM UTC-4, HM wrote: > > What about the yellow 500 error-page when in debug-mode? I'd like to have > a copy of the complete thing *somewhere* now that what's sent by em

Re: improving debug logging in development

What about the yellow 500 error-page when in debug-mode? I'd like to have a copy of the complete thing *somewhere* now that what's sent by email is sanitized. Cloning a running system, turning DEBUG on and attempting to trigger the same error isn't always easy. Is the 500-data loggable at all? On

Re: improving debug logging in development

On Mon, 2015-03-23 at 19:16 -0600, Carl Meyer wrote: > And it still seems to me that it's bad for Django's default config to > set `level: ERROR` and `propagate: False` on the django.request and > django.security loggers, as that prevents those logs from propagating to > higher-level handlers

Re: improving debug logging in development

't provide a working "send all logs to stdout" without either that or another way to bypass Django's default logging config. And it still seems to me that it's bad for Django's default config to set `level: ERROR` and `propagate: False` on the django.request and django.security loggers, as

Re: improving debug logging in development

Hm, now I wonder if that blog post in my initial post is entirely correct. This config seems to send all Django logging to stdout (regardless of the value of disable_existing_loggers). The difference from the initially proposed doc patch is that this config redefines the 'django' logger

Re: improving debug logging in development

On Monday, March 23, 2015 at 9:45:12 PM UTC+1, Wim Feijen wrote: > > This may sound stupid, but I actually use Logbook for logging because I > find it easy to use. > Why would this sound stupid? Logbook is a nice library and actually worth thinking about if we start using dependenci

Re: improving debug logging in development

This may sound stupid, but I actually use Logbook for logging because I find it easy to use. On Monday, 23 March 2015 18:48:26 UTC+1, Tim Graham wrote: > > The alternative to a new setting would be to revert the "merging" behavior > of the django.utils.log.DEFAULT_LOGGING a

Re: improving debug logging in development

This is what we're using to send to loggly. I'm not honestly 100% sure it works as intended but it gets the job done. It would be great if we could conditionally log to console when running in a local dev environment. LOGGING = { 'version': 1, 'disable_existing_loggers': True

Re: improving debug logging in development

hich don't propagate their entries (I couldn't >> tell the reason for this from >> https://github.com/django/django/commit/f0f327bbfe1caae6d11fbe20a3b5b96eed1704cf#diff-246800ac266982b8ad12f505352a662eR63) [...] > ISTM that "layer atop the default config" is a better def

Re: improving debug logging in development

get any future updates to the default config automatically. ISTM that "layer atop the default config" is a better default behavior if you add a LOGGING setting than "replace the default config", to avoid people losing their mail-admins config accidentally. (But we definitely nee

Re: improving debug logging in development

704cf#diff-246800ac266982b8ad12f505352a662eR63) I would like to ask if anyone who is using settings.LOGGING could share their config so we can get a sense of different use cases? [1] An attempt to write a LOGGING config that outputs all entires to stdout, but doesn't entirely work as stated above. LOGGING = { 'v

Re: improving debug logging in development

On 03/22/2015 08:23 PM, Carl Meyer wrote: > The first, more complex and more important question is: how do we fix > Django's logging config process to be less broken, so that the best > advice for getting it to do what you what isn't "disable Django's > interference entirely a

  1   2   3   4   >