Preventing the leaking of sensitive information in error logs

[Julien Phalip]

Hi,

Recently I've been a bit embarrassed to receive a 500-error email
report containing a client of mine's password displayed in clear
because the admin login view had encountered an unhandled exception.
This is probably OK in a debug environment but in production this can
potentially have damaging consequences when handling passwords, credit
card numbers, etc. It may also go against certain policies and
standards such as the PCI-DSS (http://en.wikipedia.org/wiki/
Payment_Card_Industry_Data_Security_Standard).

There is already an open ticket to address this issue:
https://code.djangoproject.com/ticket/14614

I first wrote a patch allowing a lot of granularity to control which
POST/GET parameters should get obfuscated when producing the error
logs: 
https://code.djangoproject.com/attachment/ticket/14614/14614.obfuscate-request-parameters.diff

Russell pointed out that this implementation approach was overly
complicated. It also doesn't address the stack frame variables being
logged in some situations. So I've posted another patch with a more
radical approach, where all stack frame variables and the request's
information are systematically and entirely omitted from the logs for
exceptions occurring in views marked with the @sensitive decorator:
https://code.djangoproject.com/attachment/ticket/14614/14614.sensitive-request.diff

Perhaps the ideal solution lies somewhere between the two approaches.
The default loggers should also probably provide this protection by
default but still allow easy customisation/overriding of this
behaviour, for example for debugging purposes in safe environments.

I'm bringing this up to the dev-list as I'm keen to hear if someone is
interested in this problem and has suggestions towards a robust
solution. It is a pretty serious issue that I hope can be resolved by
the 1.4 release.

Many thanks,

Julien

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: admin.site.register decorator

[Russell Keith-Magee]

On Saturday, May 28, 2011, Mateusz Harasymczuk  wrote:
> Recently, I had to make more than one admin class in admin.py file.
> I have never had a situation like this before.
> I keept my admin classes in separate files in admin module.
>
> It came to me that after each class definition you have to make
> admin.site.register(Class, AdminClass)
>
> Hence:
>
> - Where is the best place to put this call?
> after a AdminClass definition?
>
> Try it, it looks ugly

Says you. Given that admin registration has always been like this,
that means I've been "trying it" for about 4 years, and I don't find
it ugly at all.

> - At the end of file with other registers?
>
> it is similar to signals connect and template_tag registering.
>
> Therefore it should be similarly decorated by decorator.
>
> @register_admin(class=ModelName)
> class ModelAdmin:
>     pass
>
>
> what do you think?

I think this misses several important points.

Firstly, class decorators are a relatively recent addition on Python.
They were only added in Python 2.6. Django needs to support Python
2.5.

Secondly, a class decorator must be used at the same time as the class
is declared. The statement-based registration based approach means you
can define a class in one module, and then register it in a different
module.

Thirdly, statement-based registration you can also include business
logic as part of the registration process; e.g., make a programmatic
decision as to which admin registration to use at runtime. This sort
of conditional behavior isn't an option with class decorators.

> BTW:
> This one is even more ugly than previous one!
>
> How about changing:
>
>   model_method.allow_tags = True
>   model_method.short_description = _( 'Model Method' )
>
> into:
>
>   @options(allow_tags=True, short_description=_('Model Method'))
>
> or:
>
>   @allow_tags
>   @short_desctiption(_('Model Method'))
>
> ?

I'm more sympathetic to this idea. This seems like a case where
decorators would be a good match - in fact, it could be a slight
improvement, because misspelling a function annotation won't raise an
error, but a misspelled decorator will. i.e.,

def myfunc():
   ...
myfunc.short_description = "xxx"

isn't an error, but

@short_descriptionnn("xxx")
def myfunc():
   ...

Is, because the decorator named short_descriptionnn doesn't exist.

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-developers@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: jQuery.tmpl() and Django

[Tiago Boldt Sousa]

Hi,

I've using this in Django. I've just substituted {{ }} for [[ ]] in my
jquery templates and created a list of all the template ids I have.
Then, on document ready, I do:

for (var i in templates){
  var newtext = $(templates[i]).text().replace(/\[\[/g,
"{{").replace(/\]\]/g, "}}");
  $(templates[i]).text(newtext);
}

That replaces the [[ ]] for {{ }} again on the client side, removing
any conflict. Works perfectly :)


On May 27, 4:14 am, Ori Livneh  wrote:
> Hello,
>
> jQuery.tmpl(), a beta feature slated for inclusion in the main jQuery
> brach, uses some of the same syntax as Django in its templating
> markup, which is a bit of a bummer. I'm writing to see whether you
> think we should get in touch with the jQuery team to see if they could
> plausibly change it.
>
> There are, obviously, quite a lot of templating languages out there,
> and some of them are bound to clash with Django, and that's not a
> problem. But Django and jQuery are often deployed together (jQuery is
> actually bundled with Django for use in the admin), making this clash
> especially annoying.
>
> You might think this isn't an issue since JavaScript code should be
> served from static files anyway, but there's an added complication.
> One of the patterns jQuery.tmpl() recommends is nesting templates
> within a 

PhD ideas

[Tiago Boldt Sousa]

Hi,

I'm now currently finishing my MsC [1] and am thinking about enrolling
into the PhD program. I was wondering if any of you would like to
suggest me some research topic that could benefit the scientific
community, that might also result as a potential improvement for
Django.

I love everything that's web related and software engineering but I
don't yet have any idea for a research topic that would be relevant
for a PhD.

Feel free to contact me directly :)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Looking for similar site for learning django

[Karen Tracey]

Please ask questions about learning or using Django on django-users. The
topic of this list is the development of Django itself.

Karen

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.

Looking for similar site for learning django

[kracekumar ramaraju]

I have been trying to learn django,I followed django documentation,books 
snippets.I was really impressed and clear explanation of the site regarding 
rails Check out this site about Rails 
tutorial,i 
am looking forward for something similar for Django.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Django and the new EU anti-cookie law

[andybak]

Here's a good summary of the issues: 
http://www.torchbox.com/blog/eu-law-cookies-and-ico

You can skip to the section titled: 'What enforcement have the ICO
announced?'

It looks like enforcement will lean towards the pragmatic.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.

admin.site.register decorator

[Mateusz Harasymczuk]

Recently, I had to make more than one admin class in admin.py file.
I have never had a situation like this before.
I keept my admin classes in separate files in admin module.

It came to me that after each class definition you have to make 
admin.site.register(Class, AdminClass)

Hence:

- Where is the best place to put this call?
after a AdminClass definition?

Try it, it looks ugly

- At the end of file with other registers?

it is similar to signals connect and template_tag registering.

Therefore it should be similarly decorated by decorator.

@register_admin(class=ModelName)
class ModelAdmin:
pass


what do you think?


BTW:
This one is even more ugly than previous one!

How about changing:

  model_method.allow_tags = True
  model_method.short_description = _( 'Model Method' )

into:

  @options(allow_tags=True, short_description=_('Model Method'))

or:

  @allow_tags
  @short_desctiption(_('Model Method'))

?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.