Re: Attach a technincal html response to email on server error
yeah i know it can be done... i can try to write it in future... it can be a subclass of something, i have to open the code. could be an interesting contribute? -- 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: Attach a technincal html response to email on server error
On Fri, Nov 11, 2011 at 9:35 PM, Ric wrote: > yeah i know it can be done... > > i can try to write it in future... it can be a subclass of something, > i have to open the code. > > You don't have to write anything, you just have to set include_html=True in the config for the Django-provided admin email handler. See: https://docs.djangoproject.com/en/1.3/topics/logging/#django.utils.log.AdminEmailHandler 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.
Re: TemplateResponse and loader should handle request
Just wanted to point those in this thread to this ticket: https://code.djangoproject.com/ticket/17093 Such a refactor of the template system as outlined could eventually incorporate some of these ideas. -Preston -- 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: Localization on User model
On 10 November 2011 18:53, hcarvalhoalves wrote: > I believe the solution is to actually figure a migration path to move > everything that is non-essential to outside the User model. To > identify a User, it should be enough to have username, password and > permissions, and have the rest of the fields live in a > django.contrib.auth.models.DefaultUserProfile. Why do you want the password in the User-model? There are more ways of authenticating than user/password. There's openid, oauth, facebook, saml, cas, pam... One to one relationships *is* a well-known and respectable technique you know? I might have mentioned before that the only field that we can't do without in a User-model is the primary key. Everything else, even username, is up for grabs. HM -- 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: Python 3 and you
Jannis, that's great news indeed, I'll help with testing. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/jzva36TUYGcJ. 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 sprint in North Carolina, Nov. 12-13, 2011
Hi All - Just a quick reminder that the Django sprint in NC is being held tomorrow and Sunday here in Carrboro. For more information: https://code.djangoproject.com/wiki/Sprint20TriangleNC Join us on IRC in the #django-sprint channel if you can't make it in person. We'll be on from about 9am to 3:30pm EST (UTC-5) each day and Karen Tracey will be here for most of that time to help review and commit our patches (thanks Karen!). :-) Cheers, Tobias -- Tobias McNulty, Managing Member Caktus Consulting Group, LLC http://www.caktusgroup.com -- 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: Request for review / Multiple time zone support for datetime representation
Just in case you were waiting for a reply, I've read your response and everything seems good to me. Luke On 10/11/11 07:46, Aymeric Augustin wrote: > Hi Luke, > > Thanks for the review! I've updated the branch with your suggestions. > > Here are a few comments -- when I have something to say other than > "fixed, thanks". -- "In your presence there is fullness of joy; at your right hand are pleasures forevermore" Psalm 16:11 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-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: Removing pickle from cookie-based session storage
On 10 nov, 18:05, Paul McMillan wrote: > > There's no reason to not use JSON by default since it's adequate for > > most cases where you need to store lightweight data client-side, since > > it's most useful to use with FormWizard and such, where the fields are > > easily serialized as strings. If it can't be a drop-in replacement to > > the other session storage, just document it and offer a > > PickleSignedSessionStorage, but don't push a possibly insecure > > default. > > The default is secure. If you don't disclose your secret key, you > don't have a problem. The problem is, if you *do* leak the secret key - or new bugs in the session handling component are found - what should be a session hi- jack issue escalates to a remote code execution exploit. I shouldn't have to insist on how bad that is. > JSON is considerably more verbose. Cookie space is limited. JSON > doesn't support many of the data structures people store in sessions. > There are many reasons to store data in sessions beyond FormWizard. It > already isn't a drop-in replacement, since it has limitations the > other ones don't have. There's nothing wrong with providing a pickle serializer. I'm just opposed to making it default. At the very least, add to the official documentation a mention to the possible security issues, so the concerned developer can make a choice. -- 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: Removing pickle from cookie-based session storage
On 10 nov, 21:21, Anssi Kääriäinen wrote: > On Nov 10, 10:05 pm, Paul McMillan wrote: > > > > > > > > > > > > There's no reason to not use JSON by default since it's adequate for > > > most cases where you need to store lightweight data client-side, since > > > it's most useful to use with FormWizard and such, where the fields are > > > easily serialized as strings. If it can't be a drop-in replacement to > > > the other session storage, just document it and offer a > > > PickleSignedSessionStorage, but don't push a possibly insecure > > > default. > > > The default is secure. If you don't disclose your secret key, you > > don't have a problem. > > > JSON is considerably more verbose. Cookie space is limited. JSON > > doesn't support many of the data structures people store in sessions. > > There are many reasons to store data in sessions beyond FormWizard. It > > already isn't a drop-in replacement, since it has limitations the > > other ones don't have. > > Would it make sense to allow easier subclassing of > signed_cookies.SessionStore? The standard SessionStore could use > self.serializer instead of the hardcoded PickleSerializer (patch size > 3 lines). Then document how to subclass SessionStore: > > from django.contrib.sessions.backends.signed_cookies import > SessionStore > from django.core.signing import JSONSerializer > > class JSONSessionStore(SessionStore): > self.serializer = JSONSerializer > > This would allow the developer to pick the tradeoff between JSON and > Pickle instead of Django enforcing the choice. Not that it is that > hard to subclass the SessionStore currently, but this would make it > even easier, and documentation would make it part of the public API. > > - Anssi That's how Werkzeug's SecureCookie is implemented also. Besides, that's just good practice. +1 -- 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: Removing pickle from cookie-based session storage
Can we provide a setting that lets you switch between the two? Then you can let developers choose their poison? On Friday, November 11, 2011 at 6:25 PM, hcarvalhoalves wrote: > On 10 nov, 18:05, Paul McMillan wrote: > > > There's no reason to not use JSON by default since it's adequate for > > > most cases where you need to store lightweight data client-side, since > > > it's most useful to use with FormWizard and such, where the fields are > > > easily serialized as strings. If it can't be a drop-in replacement to > > > the other session storage, just document it and offer a > > > PickleSignedSessionStorage, but don't push a possibly insecure > > > default. > > > > > > > > > The default is secure. If you don't disclose your secret key, you > > don't have a problem. > > > > > The problem is, if you *do* leak the secret key - or new bugs in the > session handling component are found - what should be a session hi- > jack issue escalates to a remote code execution exploit. I shouldn't > have to insist on how bad that is. > > > JSON is considerably more verbose. Cookie space is limited. JSON > > doesn't support many of the data structures people store in sessions. > > There are many reasons to store data in sessions beyond FormWizard. It > > already isn't a drop-in replacement, since it has limitations the > > other ones don't have. > > > > > There's nothing wrong with providing a pickle serializer. I'm just > opposed to making it default. > > At the very least, add to the official documentation a mention to the > possible security issues, so the concerned developer can make a choice. > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto:django-developers+unsubscr...@googlegroups.com). > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > > -- 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.
