Re: #12012 Logging: request for comments
On Wed, Sep 29, 2010 at 9:40 AM, Nick Phillips wrote: > On Wed, 2010-09-29 at 09:00 +0800, Russell Keith-Magee wrote: > >> These all strike me as messages appropriate for a warning -- they're >> all slightly concerning indications that you're either under some sort >> of attack, or at the very least that your users are having a bad >> experience on your site. >> >> This includes 404 -- manually entered URLs and annoying PHP hackbots >> notwithstanding, your site shouldn't be generating 404s. If it is, you >> should be investigating. The only argument I can see for 404 as an >> INFO message is the prevalence; given that a 404 is often generated >> without being a concern, it makes sense to make them easy to filter >> out. However, IMHO, unilaterally ignoring 404s would be just as bad as >> having too many. On top of that, any halfway decent log analysis tool >> can filter these messages on a per-status code or per-URL basis. > > FWIW I agree with everything you say up to this point - it's just the > conclusion that I differ on; I'd prefer to have the ability to use the > logging config to send the 404s somewhere else. Not to ignore them, just > to be able to deal with them separately as simply as possible. Since > their issue is buried within the framework and can't easily be > overridden, I think their ubiquity does justify the the lower priority. I think I may be able to keep everyone happy here. With a couple of modifications, this is something that can be handled as a logging filter. All we need to do is pass in the status code as part of the extra data that is part of the log message; then you could write a filter to transform the log however you wanted -- for example: class Info404Filter(logging.Filter): def filter(self, record): if record.status_code == 404: record.levelno = logging.INFO record.levelname = logging.getLevelName(logging.INFO) return True would, if installed, convert all 404 messages into INFO level. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
Re: #12012 Logging: request for comments
On Wed, 2010-09-29 at 09:00 +0800, Russell Keith-Magee wrote: > These all strike me as messages appropriate for a warning -- they're > all slightly concerning indications that you're either under some sort > of attack, or at the very least that your users are having a bad > experience on your site. > > This includes 404 -- manually entered URLs and annoying PHP hackbots > notwithstanding, your site shouldn't be generating 404s. If it is, you > should be investigating. The only argument I can see for 404 as an > INFO message is the prevalence; given that a 404 is often generated > without being a concern, it makes sense to make them easy to filter > out. However, IMHO, unilaterally ignoring 404s would be just as bad as > having too many. On top of that, any halfway decent log analysis tool > can filter these messages on a per-status code or per-URL basis. FWIW I agree with everything you say up to this point - it's just the conclusion that I differ on; I'd prefer to have the ability to use the logging config to send the 404s somewhere else. Not to ignore them, just to be able to deal with them separately as simply as possible. Since their issue is buried within the framework and can't easily be overridden, I think their ubiquity does justify the the lower priority. However, as Alex pointed out, this is essentially bikeshedding. So, since you're the one doing the work, at this point I'll shut up and wish you well with it :-) Cheers, Nick -- Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz # these statements are my own, not those of the University of Otago -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
Re: #12012 Logging: request for comments
On Tue, Sep 28, 2010 at 11:45 PM, Ian Lewis wrote: > Hi, > > On Tue, Sep 28, 2010 at 9:19 AM, Nick Phillips > wrote: >> I'm worried by the use of "warning" for all 4xx statuses. I think it >> still makes sense to use the "original" syslog level definitions[*] as a >> guide, and on there I'd suggest that some 4xx statuses would merit >> "Info", some "Notice", and maybe one or two "Warning". "Notice" not >> being included in Python's default logging, I guess that means I'd split >> them between "Info" and "Warning". >> >> My view is that the main use of these logs to me is to help me see when >> someone is doing Bad Things (or trying to) to my system. I would be >> wanting anything that indicated a targeted exploration of my server to >> show up as "Warning", and anything that's most likely a random script >> kiddie to be "Info". That certainly puts 404 in as "Info"; I see so many >> hits looking for e.g. poorly-configured phpmyadmin installations, that >> 404s would swamp anything that I really needed to be looking at. > > I'm split on this myself but I think making all 400 level responses warnings > would keep things consistent and help find potential security issues easier. > > Something like > > 5xx = error > 4xx = warning > 3xx = info > 2xx (>300) = debug > > would be very easy to understand and the desired request logging is easy > to set up using logging levels. It's important to note that I've deliberately *not* included logging calls for 3XX and 2XX responses. Django's logging isn't intended as a replacement for Apache/webserver logging; it's there as a supplement. The warning/error condidtions are the occasions when you're likely to want/need the extra request data to work out what went wrong, hence the logging calls. 3XX and 2XX calls are normal operation, so they shouldn't require any special handling above and beyond what the webserver does. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
Re: #12012 Logging: request for comments
2010/9/29 Łukasz Rekucki : > On 28 September 2010 17:45, Ian Lewis wrote: >> Hi, >> >> On Tue, Sep 28, 2010 at 9:19 AM, Nick Phillips >> wrote: >>> I'm worried by the use of "warning" for all 4xx statuses. I think it >>> still makes sense to use the "original" syslog level definitions[*] as a >>> guide, and on there I'd suggest that some 4xx statuses would merit >>> "Info", some "Notice", and maybe one or two "Warning". "Notice" not >>> being included in Python's default logging, I guess that means I'd split >>> them between "Info" and "Warning". >>> >>> My view is that the main use of these logs to me is to help me see when >>> someone is doing Bad Things (or trying to) to my system. I would be >>> wanting anything that indicated a targeted exploration of my server to >>> show up as "Warning", and anything that's most likely a random script >>> kiddie to be "Info". That certainly puts 404 in as "Info"; I see so many >>> hits looking for e.g. poorly-configured phpmyadmin installations, that >>> 404s would swamp anything that I really needed to be looking at. >> >> I'm split on this myself but I think making all 400 level responses warnings >> would keep things consistent and help find potential security issues easier. > > Making all 4xx a Warning is a bad idea. When you're writing a RESTful > API, it's common to use these status codes the way they were intended > to be used. For example, if the user makes a POST add a comment, but > the form data is invalid a RESTful API won't return a 2xx, because the > request failed. The only reasonable codes are in in 4xx range. It's > not uncommon for users to badly fill out forms, so getting warnings > about it would just flood the log. > > The logging level should be based on the cause (like CSRF validation > failure) not solely on the response's status code. Here's the list of 4XX responses that we currently raise: 400 Bad Request 403 Forbidden (due to permissions and CSRF) 404 Not Found 405 Method Not Allowed 410 Gone 412 Precondition Failed These all strike me as messages appropriate for a warning -- they're all slightly concerning indications that you're either under some sort of attack, or at the very least that your users are having a bad experience on your site. This includes 404 -- manually entered URLs and annoying PHP hackbots notwithstanding, your site shouldn't be generating 404s. If it is, you should be investigating. The only argument I can see for 404 as an INFO message is the prevalence; given that a 404 is often generated without being a concern, it makes sense to make them easy to filter out. However, IMHO, unilaterally ignoring 404s would be just as bad as having too many. On top of that, any halfway decent log analysis tool can filter these messages on a per-status code or per-URL basis. In short, I'm not convinced it's worth making a special case of 404. Yours Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
Re: #12012 Logging: request for comments
On Tue, Sep 28, 2010 at 7:43 PM, Luke Plant wrote:
> On Sat, 2010-09-25 at 14:16 +0800, Russell Keith-Magee wrote:
>
>> * The default logging configuration. Have I got the
>> propagate/override options right for sensible defaults (both in global
>> and new-project settings)?
>
> I just noticed that the project template settings and the global
> settings are different. The global settings use a null handler for debug
> logs, while the project template config would send them to stderr. I
> can see the value of having debug calls appear on the console while
> running the development server, but most people will take the template
> settings.py as a good starting point for deployment. Since we have
> already defined DEBUG in the template settings.py, how about changing
> the project template to have this:
>
> LOGGING = {
> 'version': 1,
> 'disable_existing_loggers': False,
> 'handlers': {
> 'null': {
> 'level':'DEBUG',
> 'class':'django.utils.log.NullHandler',
> },
> 'console':{
> 'level':'DEBUG',
> 'class':'logging.StreamHandler',
> },
> 'mail_admins': {
> 'level': 'ERROR',
> 'class': 'django.utils.log.AdminEmailHandler'
> }
> },
> 'loggers': {
> 'django': {
> 'handlers':[DEBUG and 'console' or 'null'],
> 'propagate': True,
> 'level':'INFO',
> },
> 'django.request':{
> 'handlers': ['mail_admins'],
> 'level': 'ERROR',
> 'propagate': True,
> },
> }
> }
>
> That will give a settings.py that is sensible for both development and
> deployment.
Hrm. I'm not sure I agree.
The reason for having different settings between global_settings and
template settings is support for old projects. If you've got a legacy
project, you won't have a LOGGING setting, so the logging needs to be
identical to what is produced right now -- which is to say, emails for
server errors, but everything else to the bitbucket.
I can see the value in adding the null handler as part of the project
template, but I'm not sure about the "DEBUG and 'console' or 'null'"
logic. To my mind, 'just write to the console' is a reasonable
default, regardless of whether you're in testing or production; in
practice, if you're in production, you're going to need to tweak
propagation, level, and probably push the handlers to something
better, too. Making the default as simple as possible (i.e., just say
console) makes more sense to me than trying to presuppose how a log
will be used in production.
That said, it's a bit of a moot point: there isn't anything written to
the 'django' logger at this point in time. In practice, the value of
the setting is pretty much irrelevant for the moment. 'null' is as
good as any, as long as it's clear that this is what is happening.
For completeness, we should probably add a logger entry for
'django.db.backends' that pushes everything to null.
So - here's a revised proposal, which can be shared between both
global and project template settings:
LOGGING = {
'version': 1,
'disable_existing_loggers': False,
'handlers': {
'null': {
'level':'DEBUG',
'class':'django.utils.log.NullHandler',
},
'console':{
'level':'DEBUG',
'class':'logging.StreamHandler',
},
'mail_admins': {
'level': 'ERROR',
'class': 'django.utils.log.AdminEmailHandler'
}
},
'loggers': {
'django': {
'handlers':['null'],
'propagate': True,
'level':'INFO',
},
'django.db.backends':{
'handlers': [],
'level': 'INFO',
'propagate': True,
},
'django.request':{
'handlers': ['mail_admins'],
'level': 'ERROR',
'propagate': True,
},
}
}
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@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.
Re: #12012 Logging: request for comments
On 28 September 2010 17:45, Ian Lewis wrote: > Hi, > > On Tue, Sep 28, 2010 at 9:19 AM, Nick Phillips > wrote: >> I'm worried by the use of "warning" for all 4xx statuses. I think it >> still makes sense to use the "original" syslog level definitions[*] as a >> guide, and on there I'd suggest that some 4xx statuses would merit >> "Info", some "Notice", and maybe one or two "Warning". "Notice" not >> being included in Python's default logging, I guess that means I'd split >> them between "Info" and "Warning". >> >> My view is that the main use of these logs to me is to help me see when >> someone is doing Bad Things (or trying to) to my system. I would be >> wanting anything that indicated a targeted exploration of my server to >> show up as "Warning", and anything that's most likely a random script >> kiddie to be "Info". That certainly puts 404 in as "Info"; I see so many >> hits looking for e.g. poorly-configured phpmyadmin installations, that >> 404s would swamp anything that I really needed to be looking at. > > I'm split on this myself but I think making all 400 level responses warnings > would keep things consistent and help find potential security issues easier. Making all 4xx a Warning is a bad idea. When you're writing a RESTful API, it's common to use these status codes the way they were intended to be used. For example, if the user makes a POST add a comment, but the form data is invalid a RESTful API won't return a 2xx, because the request failed. The only reasonable codes are in in 4xx range. It's not uncommon for users to badly fill out forms, so getting warnings about it would just flood the log. The logging level should be based on the cause (like CSRF validation failure) not solely on the response's status code. Regards, Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
Re: #12012 Logging: request for comments
I don't see how a 302 because someone posted something is any less debug thann the 200 to serve thhhe get. Bikesheddinngly yours, Alex On Sep 28, 2010 11:45 AM, "Ian Lewis" wrote: Hi, On Tue, Sep 28, 2010 at 9:19 AM, Nick Phillips wrote: > I'm worried by ... I'm split on this myself but I think making all 400 level responses warnings would keep things consistent and help find potential security issues easier. Something like 5xx = error 4xx = warning 3xx = info 2xx (>300) = debug would be very easy to understand and the desired request logging is easy to set up using logging levels. -- Ian http://www.ianlewis.org/ -- You received this message because you are subscribed to the Google Groups "Django developers" g... -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
Re: #12012 Logging: request for comments
Hi, On Tue, Sep 28, 2010 at 9:19 AM, Nick Phillips wrote: > I'm worried by the use of "warning" for all 4xx statuses. I think it > still makes sense to use the "original" syslog level definitions[*] as a > guide, and on there I'd suggest that some 4xx statuses would merit > "Info", some "Notice", and maybe one or two "Warning". "Notice" not > being included in Python's default logging, I guess that means I'd split > them between "Info" and "Warning". > > My view is that the main use of these logs to me is to help me see when > someone is doing Bad Things (or trying to) to my system. I would be > wanting anything that indicated a targeted exploration of my server to > show up as "Warning", and anything that's most likely a random script > kiddie to be "Info". That certainly puts 404 in as "Info"; I see so many > hits looking for e.g. poorly-configured phpmyadmin installations, that > 404s would swamp anything that I really needed to be looking at. I'm split on this myself but I think making all 400 level responses warnings would keep things consistent and help find potential security issues easier. Something like 5xx = error 4xx = warning 3xx = info 2xx (>300) = debug would be very easy to understand and the desired request logging is easy to set up using logging levels. -- Ian http://www.ianlewis.org/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
Re: Changes to LazySettings
On Sep 28, 3:42 am, Luke Plant wrote: > But can anyone else think of any gotchas with this change before I > commit it? It produces a 30% improvement for the benchmark that relates > to the ticket [3]. Not directly related to this change, but there are at least one part in Django that will cache a setting when first used [1]. The code in django/utils/translations/__init__,py will cache the real translation provider for performance reasons. If the USE_I18N setting is changed when testing, it will not have any effect in which translations provider is used. There might be other parts also which do the same thing. I wonder if __setattr__ of the LazySettings should automatically flush this cache when USE_I18N is changed? [1] http://code.djangoproject.com/changeset/13899 - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
testsuite [was: four NoSQL backends you want? :)]
On Mon, Sep 27, 2010 at 08:37:08PM -0400, Alex Gaynor wrote: > > While developing my backend I basically ignored the existing tests > because it was impossible to learn anything from 700 test failures, > of which some are "expected and never will pass" (e.g. ones testing > that we generate only one JOIN), other are "this is something I just > haven't implemented yet, and really don't need to be told". > Once it passed your test suite, did you then make it pass the Django test suite? Tons of questions come to mind: If not, why not? Did you try to improve it, but it was too hard? Were there lots of old tests that are no longer relevant? Sounds like you have had recent and relevent experience; I'm basically looking for a brain dump of the highlights, and trying to decide if it's worth the effort. (I expect it will take lots of time ...) So far, both you and the No-SQL hackers have not used the test suite, which makes me wonder about the suite's utility for exercising new persistence layers. The alternative is "works for me, try it at your own risk ..." which requires no extra effort on my part. If no one else uses it, then no skin off my nose. m -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
Re: #12012 Logging: request for comments
On Sat, 2010-09-25 at 14:16 +0800, Russell Keith-Magee wrote:
> * The default logging configuration. Have I got the
> propagate/override options right for sensible defaults (both in global
> and new-project settings)?
I just noticed that the project template settings and the global
settings are different. The global settings use a null handler for debug
logs, while the project template config would send them to stderr. I
can see the value of having debug calls appear on the console while
running the development server, but most people will take the template
settings.py as a good starting point for deployment. Since we have
already defined DEBUG in the template settings.py, how about changing
the project template to have this:
LOGGING = {
'version': 1,
'disable_existing_loggers': False,
'handlers': {
'null': {
'level':'DEBUG',
'class':'django.utils.log.NullHandler',
},
'console':{
'level':'DEBUG',
'class':'logging.StreamHandler',
},
'mail_admins': {
'level': 'ERROR',
'class': 'django.utils.log.AdminEmailHandler'
}
},
'loggers': {
'django': {
'handlers':[DEBUG and 'console' or 'null'],
'propagate': True,
'level':'INFO',
},
'django.request':{
'handlers': ['mail_admins'],
'level': 'ERROR',
'propagate': True,
},
}
}
That will give a settings.py that is sensible for both development and
deployment.
Luke
--
"Cross country skiing is great if you live in a small country."
(Steven Wright)
Luke Plant || http://lukeplant.me.uk/
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@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.
Re: four NoSQL backends you want? :)
On 28 Sep., 02:45, Russell Keith-Magee wrote: > So - the real goal is to ensure that you can use forms and generic > views with NoSQL stores, not to ensure that you take an app built > using a relational store, and deploy it on a NoSQL store. If that's the real goal then we've reached it already more than half a year ago with the backend for App Engine and a couple of months ago with a backend for MongoDB. To end this endless discussions and to proof what we claim, i call for help. Please test generic views, forms, the admin, in order to build trust. Let us know how to improve the documentation and what's missing. The current documentation for the App Engine can be found here: http://www.allbuttonspressed.com/projects/djangoappengine The documentation for the MongoDB backend can be found here: http://github.com/aparo/django-mongodb-engine We've started a supported/unsupported feature list on djangopackages: http://www.djangopackages.com/grids/g/cloud/ So please help in order to get closer at least one step towards NoSQL in Django. Bye, Thomas Wanschik -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
