Re: DRAFT 1.1 roadmap posted
> > - the SafeForm feature (eight +0). Personally, I suspect we > should stop trying to second-guess form features for a bit, but > if somebody came up with the perfect code, there's no real > reason to defer that one (it got 8 +0 votes and nothing else, so > we're only lanking a champion). I can imagine a period where I'd > just go through a bunch of things like that and gave thumbs up > or thumbs down to code and committed it if it was of high enough > quality. > I would volunteer to work on this (I voted +1), though I guess you need a committer to back it up. Some of you may recall[1] that I have at least one issue[2] with the way the current CSRFMiddleware works, which still hasn't gotten any attention. If I help with this, maybe I can at least get my fix in :) Since there are some disagreements about the exact implementation, maybe it would get more support by just calling this "some kind of fix for using CSRF protection on some forms but not others" then arguing about the implementation on the ticket or mailing list. [1]http://groups.google.com/group/django-developers/browse_thread/ thread/3fc2d329a2fafe3f/d47ca3f0e40eb8f0 [2]http://code.djangoproject.com/ticket/9356 -bob --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Localization in the admin site and date/time filters.
See tickets #2203 and #9366. They're two opposite sides of an issue
that needs to be reconciled somehow, and I figured this list was the
best way to fight it out.
#2203 summary - Date/time formats in the admin interface use the
{DATE,TIME,DATETIME}_FORMAT string from translation files, and fall
back to settings.DATE_FORMAT if there is nothing found. It is not
possible to override this with settings.DATE_FORMAT
#9366 summary - Date/time formats used by the date and time filters
use settings.{DATE,TIME}_FORMAT. It is not possible to use the
DATE_FORMAT string from a translation file without creating a custom
filter. (I also mention that there is no way to use DATETIME_FORMAT
either from settings or translation files, but that should probably be
a separate issue)
There doesn't seem to be any simple fix for both of these that will
make everyone happy. I've come up with a few ideas, but they probably
break backwards compatibility, or will make a 3rd group of people
unhappy.
1. Make the DATE_FORMAT setting default to empty string. If it's empty
in get_date_formats(), use the format from translation files,
otherwise use the format in the setting. This will break any
installation that has i18n disabled and no DATE_FORMAT in their
settings.py, unless get_date_formats() also hardcodes a fallback
format (the current default setting). This also makes an all-or-
nothing solution where overriding the format in your settings file
prevents you from using any localization of that particular format.
2. A slight improvement on #1 would be making the DATE_FORMAT setting
default to the string 'DATE_FORMAT', and get_date_formats() would then
attempt to translate that string. This would allow for a user to set
it to either an actual date format to override it everywhere, or a
string like 'CUSTOM_DATE_FORMAT' which can then be added to a
project's translation files for all locales. This still needs the
hardcoded fallback as #1 in the case where i18n is disabled and
DATE_FORMAT is not present in the project's settings.py.
I'm not sure if it's possible to make everyone happy, but there needs
to be a clear way to choose either a localized format or a custom
format, and Django needs to be consistent (by default) in every case
where it is formatting a date/time.
Anyone have any better ideas (I haven't done much work with i18n/
l18n)? Did I miss a situation where someone could still get stuck not
being able to easily use the desired format?
-bob
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: CSRF / SafeForm
On Dec 3, 9:14 am, Luke Plant wrote: > > At the moment, once you've factored everything in, I think 'view > middleware' + template tag is the way to go, with some more custom > solution for loginCSRF. The SafeForm ends up having an unwieldly > API, which means it won't be used or could be used incorrectly, it > will often require changing a template anyway, and it's specific to > Django forms. The template tag solution would basically require a > single line being added to the template for each form (plus some > settings, once). I probably should have said something earlier, since I semi- volunteered to work on this before. I like the csrf_except decorator you added. Making it a view middleware also seems like it would be possible to make a decorator with decorator_from_middleware, so users can have both an opt-in and opt-out way of using the middleware, without requiring an awkward SafeForm class. I definitely think that it should be included in the default middleware, but without even requiring the template tag to use it. Maybe add a setting for CsrfMiddleware to inject the hidden field which is on by default but can be disabled if someone wants to use the template tag. This is an area where Django can easily be secure by default, as long as we add the flexibility for the users who need more control. -bob PS - Don't really want to hijack this, but you seem to be the only one currently working on CsrfMiddleware. Would you mind looking at http://code.djangoproject.com/ticket/9356 ? --~--~-~--~~~---~--~~ 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: CSRF / SafeForm
I added a ticket (with patch) for implementing the template tag: http://code.djangoproject.com/ticket/9977 It also adds a CSRF context processor, which is used by the tag. The diff doesn't look quite right. There obviously needs to be an empty __init__.py file added to the templatetags folder for it to work. -bob On Jan 5, 12:17 pm, Luke Plant wrote: > I wrote: > > If you want to implement any of this, I'm not planning on working > > on it for this next week, I'll get in touch when I start in case > > you've made some progress. > > I'm now not going to be able to implement this for the 1.1 deadline. > I could review and commit if someone else implemented it, but > remember that Jacob also wanted to see the patch complete with docs > etc. before then, so I'm guessing this will not make 1.1 now. > > We would need to also ensure that all apps in contrib use the template > tag, otherwise we wouldn't be able to make the new method a > recommendation. This in turn will require > TEMPLATE_CONTEXT_PROCESSORS to > contain 'django.core.context_processors.request' (or some other > method for the template tag to get hold of session id/cookies). > > Finally, most importantly: > > I think we really need CSRF protection for the admin by default for > 1.1. The CSRF middleware in its current state, while not perfect, is > mature enough to be on by default IMO (as you can now manually add > exceptions where needed, and AJAX is automatically excluded). So I'd > recommend adding it to the default MIDDLEWARE_CLASSES in > global_settings, or at least the skeleton settings file created > by 'manage.py startproject'. > > Luke > > -- > Noise proves nothing. Often a hen who has merely laid an egg cackles > as if she laid an asteroid. > -- Mark Twain > > 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 -~--~~~~--~~--~--~---
Backwards-incompatible patches for FormPreview
There are 3 outstanding tickets for FormPreview that add functionality that exists in FormWizard. Unfortunately, patches for two of them are backwards-incompatible changes. Both of the backwards-incompatible tickers are marked "design decision needed", so . . . here I am, looking for a decision! http://code.djangoproject.com/ticket/7222 http://code.djangoproject.com/ticket/8690 (thanks JKM for looking at this one) http://code.djangoproject.com/ticket/9147 I'm currently using workarounds for all 3 of these on my site, which involves copying-and-pasting significant chunks of the FormPreview class. That's not a very elegant way to use it, and it makes inheriting from FormPreview almost pointless. Maybe I shouldn't even be trying to use FormPreview, but it seems like fixing those 3 tickets would make it more consistent with the API that FormWizard offers, in addition to making it easier to use (for me, anyway). Somehow, I can't seem to find the backwards compatibility page right now, but I think I remember that contrib apps didn't have the same guarantee that Django core does. I know that's not an excuse to break compatibility all over the place, but a 1.1 (or 1.2 . . .) release seems as good a time as any. Did I miss the boat on this release? Of course, I'm also open to suggestions on how to fix any of these without breaking backwards compatibility. --~--~-~--~~~---~--~~ 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: 'week_day' starting with sunday as first day of a week need to be fixed
Would it be possible to use cron's weekday numbering? Would that make anyone happy? 0-7, with both 0 and 7 representing Sunday. That would at least avoid the %7 part of the workaround (from the user's perspective, anyway). The "Monday as first day" camp could use 1-7 for their week numbering, and the "Sunday as first day" could use a 0-indexed week (0-6). Sheesh, this is starting to sound like a religious war. I think Karen made the right call here, but if there's a solution that could make more people happy, it's worth being considered. After all, once 1.1 goes out, we're stuck with it. -bob --~--~-~--~~~---~--~~ 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: Proposal: enable CSRF middleware by default
On Mar 18, 1:25 pm, Luke Plant wrote: > > Yep, agreed. I plan to replace the content re-writing stuff with a > template tag which hopefully won't be too nasty. It's just I haven't > had time yet, and I'd rather fix the security hole now, and improve > the implementation later. The exception mechanisms we've got in place > mean that it's not too painful to migrate: > There is a patch to add the template tag on http://code.djangoproject.com/ticket/9977 There are still docs and tests to be added (though I wasn't able to find the existing tests for CSRF), but I think your initial concerns about the patch have been addressed. -bob --~--~-~--~~~---~--~~ 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: QuerySet.values() Shallow Copy
On Mar 19, 8:17 am, Vitaly wrote: > I wanted json serialize a tree of django model objects: Schedule -> > Player -> django.models.User. > django.core.serializers.serialize does shallow serialization of > QuerySet but I want a deep one. Next, I looked at QuerySet.values() > plus simplejson but alas the shallow copy again. > You may want to look at http://code.djangoproject.com/ticket/4656 instead, since I think that patch does what you're looking for. -bob --~--~-~--~~~---~--~~ 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: Proposal: enable CSRF middleware by default
On Mar 19, 2:49 pm, Luke Plant wrote: > The hard work isn't the template tag, it's: > > - tests (the existing ones are in django/contrib/csrf/tests.py) > - documentation > - converting the admin (I really think this needs to be done > before we can check this in, because we want to deprecate > CsrfResponseMiddleware and make it clear in the docs what the > One True Way is. > So, if the template tag wasn't hard enough to write, it's not helpful? I'm not sure how I missed the tests, though. I think I was just looking at the regression tests for the built-in tags/filters. I'll add tests to my patch, but only if it would be helpful. It's not really clear if you even want help, or you would rather I just stop wasting your time so you can write it yourself. I don't think it should be active by default until it's done "properly". Why should it be the default now, if you have plans to significantly change how it works in the near future? If I had a commit-bit vote, I would be -1 on doing this now, and +1 on adding it once the rest of the planned improvements go in. -bob --~--~-~--~~~---~--~~ 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: Proposal: enable CSRF middleware by default
On Mar 19, 3:42 pm, Jacob Kaplan-Moss wrote: > On Thu, Mar 19, 2009 at 2:18 PM, Bob Thomas wrote: > > So, if the template tag wasn't hard enough to write, it's not helpful? > > Um. That's not what I read from what Luke's saying. > That's what I read, though. > Again, that's not at all what I get from Luke's message. I don't quite > understand your hostile tone here; Luke's telling you what needs to > happen with your patch before it can be checked in. This is how code > review works: other people look at your code and give you feedback. > That's what Luke's doing here. > I probably should have waited another few minutes before posting. I was partially commenting on his latest reply on ticket #9977, which left me a bit frustrated. (and, including that in this discussion wasn't really appropriate) > In this case, tests are not just "useful", they're *required* -- our > policy (detailed at length > athttp://docs.djangoproject.com/en/dev/internals/contributing/#patch-style) > is that tests and documentation are required: > I didn't meant to imply that adding tests was even optional. I said before that I knew it needed tests, I just wasn't looking in the correct place to add them. I was talking about the entire CSRF feature. I was getting the impression that what I was doing was counterproductive to getting this added to Django instead of helping it along. If it's taking more time to review my patches than it would take to write it from scratch, I'm not really helping. > I'm sorry if you perceived Luke's feedback as a personal slight, but > that's not what's happening here. > I'm trying not to take it personal, I was just getting the impression that I was wasting my time on this particular feature. Apologies to Luke and Jacob if I've offended either of you. -bob --~--~-~--~~~---~--~~ 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: Reminder: Django 1.1 beta this week means feature freeze
Digging through the (huge) 1.1 milestone list a bit, the following seem to be closer to improvements than bugs (IMO). If you have any favorites in here, they should probably be looked at for last-minute additions to 1.1 beta, or they may be in danger of missing 1.1 entirely: http://code.djangoproject.com/ticket/6064 Allow database connection initialization commands http://code.djangoproject.com/ticket/8447 with change in behavior to MultiValueDict.iteritems, there should be a MultiValueDict.iterlists http://code.djangoproject.com/ticket/8968 No way to utilize `next` parameter to redirect after comment deletion http://code.djangoproject.com/ticket/8972 Add ability to delete selected vector features within the Geodjango/ OpenLayers Admin map interface http://code.djangoproject.com/ticket/9101 Improved salt generation for django.contrib.auth http://code.djangoproject.com/ticket/9124 SelectDateWidget not usable with required=False http://code.djangoproject.com/ticket/9147 FormPreview needs easier extensibility http://code.djangoproject.com/ticket/9167 shutdown_message option missing in runserver.py http://code.djangoproject.com/ticket/9310 404 debug pages should show the name of the tried urlpattern if one exists. http://code.djangoproject.com/ticket/9344 TemporaryFile is missing the 'tell' method on Windows platforms http://code.djangoproject.com/ticket/9404 Proxy file-like methods and attributes in UploadedFile objects http://code.djangoproject.com/ticket/9460 Template blocks for submit buttons in admin's change view http://code.djangoproject.com/ticket/9666 ssi tag don't works with context variables http://code.djangoproject.com/ticket/9686 GeoDjango should support the sqlite3 back end via SpatiaLite http://code.djangoproject.com/ticket/9745 Add support of PostGIS's SnapToGrid function http://code.djangoproject.com/ticket/9779 Adding Foreign Key detection to SQLite inspectdb http://code.djangoproject.com/ticket/9877 More Pythonic mutations of geometry objects http://code.djangoproject.com/ticket/9881 Auth login should pass current_site to template, not current_site.name http://code.djangoproject.com/ticket/9966 Generic view "redirect_to" to carry existing query string http://code.djangoproject.com/ticket/10043 widthratio tag does not accept a variable as the max_width argument http://code.djangoproject.com/ticket/10047 TemporaryFile.seek has bad interface under Windows NT http://code.djangoproject.com/ticket/10106 default admin config for User should include is_active filter http://code.djangoproject.com/ticket/10130 Support setting deletion http://code.djangoproject.com/ticket/10134 unique_for_* broken? http://code.djangoproject.com/ticket/10146 Support for contrib/markdown extension_configs in settings.py http://code.djangoproject.com/ticket/10166 Cookie test fails in login() view http://code.djangoproject.com/ticket/10190 Charset should be customizable with HttpResponse http://code.djangoproject.com/ticket/10222 Add line_merge to GEOS geometries under django.contrib.gis http://code.djangoproject.com/ticket/10326 Allow handler500, handler404 to be callables http://code.djangoproject.com/ticket/10327 Pass document.domain to popup windows in admin http://code.djangoproject.com/ticket/10360 allow customized forbidden message when using exceptions http://code.djangoproject.com/ticket/10370 re-implement MultiValueDict.itervalues() to match values() http://code.djangoproject.com/ticket/10460 Better redirect for logout view of Authentication (list is non-inclusive and unofficial; I'm not a committer) -bob --~--~-~--~~~---~--~~ 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: Support for extending the django.contrib.auth User model
This has been discussed extensively, both on this list and the ticket at http://code.djangoproject.com/ticket/3011 It's been rejected for 1.1 (now is not really a good time to be proposing features), but you can try mentioning this again when 1.2 planning starts. -bob --~--~-~--~~~---~--~~ 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: Reminder: Django 1.1 beta this week means feature freeze
On Mar 19, 4:59 pm, Jacob Kaplan-Moss wrote: > On Thu, Mar 19, 2009 at 3:54 PM, Bob Thomas wrote: > > Digging through the (huge) 1.1 milestone list a bit, the following > > seem to be closer to improvements than bugs (IMO). If you have any > > favorites in here, they should probably be looked at for last-minute > > additions to 1.1 beta, or they may be in danger of missing 1.1 > > entirely: > > Wow, Bob, thanks for doing this -- this is a good list of stuff to > glance at over the next couple days. You're welcome :-) I have *even more* of an appreciation for you reviewing all of those tickets to put them in the 1.1 milestone in the first place. > > As you note, there's a grey area between "feature" and "bug" > One trend I noticed was that there were quite a few GIS tickets that aren't really in that grey area at all. Without a champion, they seem most likely to miss 1.1 (assuming contrib apps are subject to the same strict definition of "bug" after the beta is released). -bob --~--~-~--~~~---~--~~ 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: Proposal: enable CSRF middleware by default
> > also, please note that even if GET requests are mostly readonly, > if they return JSON, they can be still read by a CSRF attack, > so those have to be secured ( usually be verifying > the special header set by ajax requests ). > > gabor That's more of a "JSON hijacking" attack than CSRF. It would be nice if there was a way for Django to automatically avoid this as well (maybe another middleware that does not allow returning a content type of 'application/json' if request.is_ajax() is false?), but that's a different issue entirely. -bob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
