Re: Feature request for newforms: HTML 4
This seems a long way to go for the want of removing a few forward-slashes. XHTML has become the defacto standard for Django, which is great, but the vast majority of pages are still HTML 4. So if there's to be one standard it should be that. --~--~-~--~~~---~--~~ 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: Signed Cookies (ticket #3285)
Gulopine wrote: > I've taken the liberty of writing up a contrib middleware to > transparently implement signed cookies in a Django app. It autmatically > signs and validates all cookies on its own, without any other code > needing to know a thing about it. Can you explain the reasons why one would want to use signed cookies? What (presumably security) issues are they intended to overcome? Andrew --~--~-~--~~~---~--~~ 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: Signed Cookies (ticket #3285)
On 1/12/07, Andrew Durdin <[EMAIL PROTECTED]> wrote: > Can you explain the reasons why one would want to use signed cookies? > What (presumably security) issues are they intended to overcome? Stateless server. Rather than provide a randomized session token to the user and associate that token with a set of data on the server side, put the dataset in the cookie and sign it. Only accept it back if the signature checks out. For most people, the tradeoff isn't worth it, but past a certain (large) number of active users, it's better to sacrifice a little bandwidth and store client state on the client side. So yes, in a way, you are right. Storing state on the client side is only possible and sane if you can verify the authenticity of the state. - Dave --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
How to find more details about mod_python error?
>From time to time I receive the error like this: Mod_python error: "PythonHandler django.core.handlers.modpython" Traceback (most recent call last): File "C:\PYTHON23\Lib\site-packages\mod_python\apache.py", line 299, in HandlerDispatch result = object(req) File "/home/django_src/django/core/handlers/modpython.py", line 165, in handler File "/home/django_src/django/core/handlers/modpython.py", line 139, in __call__ File "C:\PYTHON23\lib\site-packages\django\core\handlers\base.py", line 109, in get_response return self.get_technical_error_response(request) File "C:\PYTHON23\lib\site-packages\django\core\handlers\base.py", line 139, in get_technical_error_response return debug.technical_500_response(request, *sys.exc_info()) File "C:\PYTHON23\lib\site-packages\django\views\debug.py", line 126, in technical_500_response return HttpResponseServerError(t.render(c), mimetype='text/html') File "C:\PYTHON23\lib\site-packages\django\core\template\__init__.py", line 146, in render return self.nodelist.render(context) File "C:\PYTHON23\lib\site-packages\django\core\template\__init__.py", line 707, in render bits.append(self.render_node(node, context)) File "C:\PYTHON23\lib\site-packages\django\core\template\__init__.py", line 735, in render_node raise wrapped TemplateSyntaxError: Caught an exception while rendering. ### As far I understood this error is on mod_python level. But how can I find the reason for this error or in other words .what caused this error? Can anyone help? Thanks La. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
alternative JSON encoder
I had the following problems with the default json encoder that is suggested to use: * cant handle Decimal * ignores properties that are not fields, it only encodes the fields (but i often add more properties to the object for passing to the template) * has problems with some m2m relations (at least in my models :-)) * looks quite complex for this simple usage, so wrote a short alternative http://dpaste.com/hold/4601/ if there is any interest, let me know where it fits best and i can make it a ticket+patch. -- cu Wolfram --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Ticket #3287 (enhancement) [patch] Model methods in the change list can have checkmark icons by decorating with boolean=True
http://code.djangoproject.com/ticket/3287 The ticket explains what's going on and shows use case/code examples. There is a patch for making the change and another that updates the relevant documentation. It's my first patch. So I'd like people to take a look to make sure my bits a kosher. It's also an enhancement, not a bug fix, so please let me know if the implementation is up to par. Thanks much! --~--~-~--~~~---~--~~ 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: Signed Cookies (ticket #3285)
> Can you explain the reasons why one would want to use signed cookies? > What (presumably security) issues are they intended to overcome? Yes, the main concept here is security. Since the signature is based on name and value of the cookie as well as the project's SECRET_KEY, a change to any one of the those three values would invalidate the cookie. The most likely use is for any time a site wants to store data for a user more persistently than a session, but without requiring the user to manually supply any additional information to retrieve that data. This sounds vague, but that's because I won't pretend to limit its potential uses to only those I know of. It could be some data for a mildly dynamic site without a database, or it could be a shopping cart ID for an online store that wants to retrieve the cart immediately when the user returns to the site. > Rather than provide a randomized session token to > the user and associate that token with a set of data on the server > side, put the dataset in the cookie and sign it. That's one possible use, yes, but potential uses go beyond simple session cookies. There's been some recent activity elsewhere, regarding the use of signed cookies for authentication purposes (django/contrib/auth/__init__.py:51 even mentions them). In theory, a username could be stored in a signed cookie and used to authenticate that user upon each request to the site. I don't know if the username alone would suffice, or if some password-based hash would accompany it, but if the username alone proves secure enough, users could be authenticated without touching the database. It would then be possible to add a second AuthenticationMiddleware (CookieAuthenticationMiddleware, perhaps) that checks for a cookie in the right format. Then it could be protected simply by placing that middleware after SignedCookiesMiddleware. I'm not a security expert, and I won't pretend to be. This patch is simply intended to provide a tool for something that's been getting some attention recently. I should note, however, that security extends only so far as preventing a user from tampering with the cookie. If the cookie itself is compromised and removed from the computer by an attacker, it would presumably still be considered valid if it accompanied a request from the attacker's computer. One potential tactic for this case would be to include an extra field in the user's db record that could be set to a random string, something of a per-user secret. If the cookie is stolen, that user's secret key could be reset by an admin (after noticing suspicious activity), or directly by the user (after validation of the user's account password). This would hardly be a real solution, though, since it relies on someone noticing the cookie has been stolen and taken action appropriately. It would also require a hit to the database each time as well, regardless of whether the password is stored in the cookie. At any rate, I know I'm not a security expert, and the use of signed cookies in authentication is outside the scope of this patch. --~--~-~--~~~---~--~~ 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: Signed Cookies (ticket #3285)
On 1/12/07, Gulopine <[EMAIL PROTECTED]> wrote: ... > I should note, however, that security extends only so far as preventing > a user from tampering with the cookie. If the cookie itself is > compromised and removed from the computer by an attacker, it would > presumably still be considered valid if it accompanied a request from > the attacker's computer. That's true with existing session-key cookies, of course. > ...If the cookie is stolen, that user's secret key > could be reset by an admin (after noticing suspicious activity), or > directly by the user (after validation of the user's account password). > > This would hardly be a real solution, though, since it relies on > someone noticing the cookie has been stolen and taken action > appropriately. It would also require a hit to the database each time as > well, regardless of whether the password is stored in the cookie. Well, right now, stolen session keys can be made invalid simply by removing them from the session table. Any signed-cookie auth should probably include something like this in order to have the same ability to revoke. --~--~-~--~~~---~--~~ 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: Ticket #3287 (enhancement) [patch] Model methods in the change list can have checkmark icons by decorating with boolean=True
On 1/12/07 1:28 AM, Xian wrote: > It's my first patch. So I'd like people to take a look to make sure my > bits a kosher. > It's also an enhancement, not a bug fix, so please let me know if the > implementation is up to par. It looks quite good, and it fixes something that's bugged me for a while. Thanks for the patch; I've checked it in as [4309]. Jacob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Moving towards Django 1.0
Howdy folks -- I think it's time to start a push towards releasing Django 1.0. What follows are my thoughts about how I'd like this process to work. == What does 1.0 mean for Django? == There's a lot of different things that "1.0" can mean. In many cases the label refers to some arbitrary measure of code maturity, but that's usually very indistinct. There's quite a bit of "1.0" software that's far less robust than Django was at day 1; we could have called it "1.0" then and gotten away with it, I think. In the context of Django, though, 1.0 has always meant something more concrete: forwards compatibility. Once we tag something as 1.0, we're committing to maintaining API stability as described in the contributing HOWTO (http://www.djangoproject.com/documentation/contributing/#official-releases). This means that any API in 1.0 *must* continue to work until *at least* 1.2, and we've been concerned about getting those APIs right before we carve them into cement. Now, though, we're getting pretty damn close. 0.95 stabilized the bulk of Django's APIs (see http://www.djangoproject.com/documentation/api_stability/), with a few exceptions. So, for the purposes of my proposal, I'm calling 1.0 the point at which all of Django's APIs stabilize. Note that this *doesn't* mean feature-completion -- there's some fascinating work (evolution, per-object-perms, etc.) that when finished will make amazingly valuable additions to Django. None of that influences the release of 1.0 in any way, so I'm going to ignore those kinds of features until the very end. So -- unstable APIs then. What do we have? == Unstable APIs == * Forms: the newforms library is coming along nicely. There's some work that remains, the bulk of which lies in converting the admin to use newforms instead of manipulators. At that point, the transition can really be called complete. * Serialization: a few tickets (#2930, #2843, #2650, #2553, and perhaps a few more) need to be reviewed and rolled in or rejected, but other than that I'm willing to call this API stable. * Authentication: Joseph Kocherhans proposed a couple of changes to the auth code to better allow custom backends. I'm +1 on those changes, and in the absence of any disagreement I'd say the community seems to agree as well. Once that stuff goes in, I think we can pretty easily call the auth framework solid -- any changes in the future could be made in a backwards-compatible way. * Generic relations: two things need to happen here (a) they need to be moved into the contrib app, and (b) They need to work in the admin. The second probably should wait on the admin rewrite; the first can be done any time. * Comments: I plan to rewrite this framework to use newforms, and in the process drastically simplify it. == Other must-haves == There's a few other things that aren't "unstable" per-se, but are must-haves for 1.0. I know everyone's gonna have their own list -- and one of the purposes of this thread is to find that list -- but I'd like to keep these minimal. Here's my list of must-haves for 1.0: * Oracle and SQLServer support. How do people -- especially core comitters -- feel about the Oracle sprint branch? I'd like to merge it; the general outline of the Oracle backend should let the SQLServer folks go to town. * Test fixtures. I think we're just waiting on Adrian's OK to check this in; I'm +1 on Russ's patch on #2333. == Handling breakage == A few of these things -- the last three, mostly -- will break (some to lots) of code. Just doing it in some arbitrary SVN revision would suck. So I think we should release a 0.96 in the next week or so, and make the all the backwards-incompatible changes after 0.96. We should announce in as many places as possible that trunk will be moving things around between 0.96 and the next release. Which brings me to... == 1.0 roadmap == So, here's my roadmap for 1.0: * Release 0.96 * Finalize all unstable APIs and must-haves referenced above. * Release 1.0rc1 * Resolve (i.e. fix, reject, or defer) all tickets in Trac. * Release rc2 * Call for and fix any large outstanding breakage still in rc2 * Release 1.0 I'm deliberately not mentioning any dates for any of the above, and I won't. I think Adrian might have a timeline in mind and I'm glad to hear it, but I'm not gonna jinx myself :) == How should this work? == So that brings us to a process. Here's how I'd like it to work: === Step 1: feature-completion === I'd like to appoint a "leader" for each "topic" (unstable API and must-have). This person will have checkin access to their area of interest so they'll need to be someone who's already got checkin or someone who's skilled enough to deserve it. This person can either tackle the issue alone or else form a team to get it done. Here's my list -- any nominations for the missing slots? * Forms: Adrian * Serialization: Jacob * Authentication: Joseph * Generic relations: ? * Comm
Re: Moving towards Django 1.0
On 12 Jan 2007, at 22:39, Jacob Kaplan-Moss wrote: > There's a few other things that aren't "unstable" per-se, but are > must-haves > for 1.0. I know everyone's gonna have their own list -- and one of > the > purposes of this thread is to find that list -- but I'd like to > keep these > minimal. What's the story with model inheritance? Cheers, John. -- http://sneeu.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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Moving towards Django 1.0
On Jan 12, 2007, at 5:39 PM, Jacob Kaplan-Moss wrote: > == Feedback == > > Well, have at it :) How about the docs on the Django site and the Django book site? Newforms, for example, is still fairly under documented, though quickly improving. 1.0 is a big psychological milestone, and will probably draw in a lot of people -- I think it'd be beneficial to make sure all the documentation is in place before the big rush :) --- David Zhou [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: Moving towards Django 1.0
> == Other must-haves == > > There's a few other things that aren't "unstable" per-se, but are must-haves > for 1.0. I know everyone's gonna have their own list As a noob I think you would be making a mistake without a simple Django installer for Windows, one that installs everything needed along with a non-trivial sample application that people can explore. Since the 1.0 release will cause a lot of people to consider looking seriously at Django and perhaps even Python for the first time, it make sense to lower the barrier to actually doing something useful and seeing how powerful Django really is. I wasn't sold until I had gone through the tutorial. Getting to the point of being able to start the tutorial is actually more complicated than doing the tutorial. Though I admit it is not too difficult, there are plenty of places where one can screw up with the semi-manual approach currently required. I'd be happy to take on the installer part if no one else better qualified steps up. I would also be happy to deal with a non-trivial example as soon as I have one. However, I am sure my use of Python/Django idiom will be suboptimal and there is probably something in existence that would be a better example. One possibility is taking the Tutorial a bit further and having some professional quality templates designed so that it looks impressive. This way prospective users can see what the end result looks like and then the tutorial can take them from scratch to building that example. I can help out here as well if need be. What sort of timeframe do you envision for 1.0 a few weeks, a few months? - Curtis --~--~-~--~~~---~--~~ 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: Moving towards Django 1.0
On Fri, 2007-01-12 at 16:39 -0600, Jacob Kaplan-Moss wrote: > Howdy folks -- > > I think it's time to start a push towards releasing Django 1.0. What follows > are my thoughts about how I'd like this process to work. So I've been absent for a couple of months now with work and life commitments, but things are getting back on track (woo-hoo -- once again I will soon have no life.. hmm...wait a minute...). From the beginning of February (around Feb 5), I will be back on deck to do a bunch more Django work, so I feel I should be able to help out a bit here. [...] > == Other must-haves == > > There's a few other things that aren't "unstable" per-se, but are must-haves > for 1.0. I know everyone's gonna have their own list -- and one of the > purposes of this thread is to find that list -- but I'd like to keep these > minimal. Here's my list of must-haves for 1.0: > > * Oracle and SQLServer support. How do people -- especially core comitters > -- > feel about the Oracle sprint branch? I'd like to merge it; the general > outline > of the Oracle backend should let the SQLServer folks go to town. > > * Test fixtures. I think we're just waiting on Adrian's OK to check this in; > I'm +1 on Russ's patch on #2333. * Model inheritance: This is top of my list to fix/finish. The backwards-incompatible bit here (in a sense) is getting MI working at all. The "under the covers" transparent portion that I was trying to do first was refactoring the way we construct queries in order to construct more efficient SQL (e.g. not using left outer joins when we don't need them) and to be a bit more easily extensible for things like Oracle, SQL Server and people who want to override query sets to add "group by" and "having clauses". I'm going to reverse the order here: get MI working (visible change), then go back to QuerySet stuff (which is functionally invisible if you don't want to use the extra stuff). Part two here is less important now, since the Oracle and SQL Server backends have made do in other creative ways, although extensions to allow aggregations for those who want them might make things helpful. * Autoescaping: I think this needs to stay on the radar at least. We came dangerously close to a consensus on this (both in discussions on this list, based on Simon's proposal) and the discussions you, I and Adrian had at OSCON. There is a patch in Trac that implements the whole thing ( + tests + documentation), although it won't apply at the moment because of the text fixture changes. I'll update the patch in early Feb, but I think it might be worth having this in 1.0 -- particularly if we want to have "on by default", since that is a real backwards-incompat change -- but just as a marketing item, since it really is a bit of a liability at the moment. [Since it will no doubt come up, I'll just mention that I'm not as enthused about SmileyChris's alternative AutoEscaping idea -- in the wiki -- because some of the points it addresses aren't really problems, I feel, and is very difficult to integrate with custom tags (or even things like linebreaksbr, etc). I may be biased, though, since I liked Simon's original proposal.] [...] > == 1.0 roadmap == > > So, here's my roadmap for 1.0: > > * Release 0.96 > * Finalize all unstable APIs and must-haves referenced above. > * Release 1.0rc1 > * Resolve (i.e. fix, reject, or defer) all tickets in Trac. > * Release rc2 > * Call for and fix any large outstanding breakage still in rc2 > * Release 1.0 > > I'm deliberately not mentioning any dates for any of the above, and I won't. > I think Adrian might have a timeline in mind and I'm glad to hear it, but I'm > not gonna jinx myself :) This plan is ambitious enough that dates will be fun to watch as they go whizzing by. But having some kind of step-by-step and some momentum to actually get to 1.0 is going to help us. > == How should this work? == > > So that brings us to a process. Here's how I'd like it to work: > > === Step 1: feature-completion === > > I'd like to appoint a "leader" for each "topic" (unstable API and must-have). > This person will have checkin access to their area of interest so they'll > need to be someone who's already got checkin or someone who's skilled enough > to deserve it. This person can either tackle the issue alone or else form a > team to get it done. Here's my list -- any nominations for the missing slots? > > * Forms: Adrian > * Serialization: Jacob > * Authentication: Joseph > * Generic relations: ? > * Comments: Jacob > * Oracle: ? > * SQLServer: ? > * Fixtures: Russ I'm happy to take on Generic relations (at least the moving portion and to work out the pieces needed for when we get the admin rewrite done). I'm also happy to do model inheritance. And seriously, if you have other items that need volunteers, just put my name in. I can make time in the next couple of months. I guess I'd also like to see "documentatio
Re: Moving towards Django 1.0
On Jan 12, 2007, at 3:28 PM, John Sutherland wrote: > > On 12 Jan 2007, at 22:39, Jacob Kaplan-Moss wrote: >> There's a few other things that aren't "unstable" per-se, but are >> must-haves >> for 1.0. I know everyone's gonna have their own list -- and one of >> the >> purposes of this thread is to find that list -- but I'd like to >> keep these >> minimal. > > What's the story with model inheritance? Wasn't this dependent on query refactoring that Malcolm was working on? Don --~--~-~--~~~---~--~~ 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: Moving towards Django 1.0
On Jan 12, 2007, at 4:06 PM, Don Arbow wrote: > Wasn't this dependent on query refactoring that Malcolm was working > on? > Doh, I send my post and Malcolm's response arrives at the same time... Don --~--~-~--~~~---~--~~ 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: Moving towards Django 1.0
On 1/12/07 5:35 PM, David Zhou wrote: > How about the docs on the Django site and the Django book site? First, please consider the book somewhat separate from Django itself. Though Adrian and I are the authors, and though we're involving the community as much as possible, the release schedule for the book is independent from any plans for Django. That is, we need to take the publisher's needs into account for the book, but those needs shouldn't -- and won't -- influence whatever we decide for Django itself. That said... > Newforms, for example, is still fairly under documented, though > quickly improving. 1/22 should see the publication of the book chapter on newforms :) > 1.0 is a big psychological milestone, and will > probably draw in a lot of people -- I think it'd be beneficial to > make sure all the documentation is in place before the big rush :) Yes, this is a very good point. I've been considering "documentation" as part of the "bug fixing" (i.e. stage 2); perhaps it's its own task and should be added as part of the "finalization" (step 1) stuff. Yeah, as I think about it, I think docs are important enough they need their own "leader" as well. That person could additionally take control of the documentation index -- which is getting a bit difficult to use -- and the FAQ. I've added that task to my list. Jacob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Windows installer (was: Moving towards Django 1.0)
On 1/12/07 5:59 PM, inflector wrote: > As a noob I think you would be making a mistake without a simple Django > installer for Windows, one that installs everything needed along with a > non-trivial sample application that people can explore. Good point. Eugene sent me a windows installer a while ago, but I didn't have a chance to test it out and then I lost track of it Let's table this until closer to the release, but if you want to talk to him and anyone else and start lining things up for a windows installer, we'd love to have one. Jacob --~--~-~--~~~---~--~~ 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: Moving towards Django 1.0
On 1/12/07 6:02 PM, Malcolm Tredinnick wrote: > So I've been absent for a couple of months now with work and life > commitments, but things are getting back on track (woo-hoo -- once again > I will soon have no life.. hmm...wait a minute...). From the beginning > of February (around Feb 5), I will be back on deck to do a bunch more > Django work, so I feel I should be able to help out a bit here. Yay! You of course shouldn't feel any obligations, but it'll be quite nice to have your help :) > * Model inheritance [snip] I actually had this on my original list, but then I took it off -- it seems to me that allowing MI wouldn't break any existing code (just allow new code to, you know, work correctly). If that's true, I'd be OK introducing it post-1.0 However, if I'm wrong then this does need to be on the roadmap for 1.0. > * Autoescaping: I think this needs to stay on the radar at least. We > came dangerously close to a consensus on this (both in discussions on > this list, based on Simon's proposal) and the discussions you, I and > Adrian had at OSCON. Ah, yes :) I think I'm really the only one who's still holding out for manual escaping, so in the interests of Getting Things Done I'm gonna shut up about it. Is there anyone besides me who *doesn't* want auto escaping (in some form) in Django? If so, let's hear it now. > There is a patch in Trac that implements the whole > thing ( + tests + documentation), although it won't apply at the moment > because of the text fixture changes. I'll update the patch in early Feb, Cool - I look forward to playing with you > This plan is ambitious enough that dates will be fun to watch as they go > whizzing by. But having some kind of step-by-step and some momentum to > actually get to 1.0 is going to help us. Let's keep things abstract for a couple of days at least, but once we've got the hit list for 1.0 ironed down, you're right that someone should set a timeline. It's just not gonna be me :) > I'm happy to take on Generic relations (at least the moving portion and > to work out the pieces needed for when we get the admin rewrite done). That's fantastic. I've got some code for the admin kicking around that should be OK to adapt and finish off for newforms. I'll put you on my list as the mover and I'll be the shaker (er, the admin guy). > I guess I'd also like to see "documentation coverage" as an item there: See my previous post about this -- I agree 100%. > If you can give as much notice as possible for these, I'd like to fly > over and be onsite. Virtual sprinting from another timezone is not > always easy, although I'll give it a go if that's all there is. Yeah, will do. > Agreed. You are probably talking about two jobs there, though: a final > call on things (you or Adrian, I suspect) and somebody (the Key > Master... er Bugmaster) to track to the "release critical" bugs and keep > things organised both for hammering the worker bees and feeding the > decisions up to the Final Decision Maker (tm). Ahhh - that's the part I hadn't quite figured out myself. Good call. Keep it coming, Jacob --~--~-~--~~~---~--~~ 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: Moving towards Django 1.0
Jacob Kaplan-Moss schrieb: > * Forms: the newforms library is coming along nicely. There's some work that > remains, the bulk of which lies in converting the admin to use newforms > instead of manipulators. At that point, the transition can really be called > complete. Adrian said that he wanted to make inline collections easier. I thought that this is a real big thing, and will completely redefine how the admin implements inline editing. And probably deeper. (Just had a look at AutomaticManipulator.save ... gosh) Not to forget: newforms will have a big influence on generic views, too. Michael -- noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg - Tel +49-911-9352-0 - Fax +49-911-9352-100 http://www.noris.de - The IT-Outsourcing Company --~--~-~--~~~---~--~~ 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: Moving towards Django 1.0
On 1/12/07 6:40 PM, Michael Radziej wrote: > Adrian said that he wanted to make inline collections easier. I > thought that this is a real big thing, and will completely redefine > how the admin implements inline editing. And probably deeper. (Just > had a look at AutomaticManipulator.save ... gosh) Heh. Yeah, this is part of reworking the admin to use newforms. I think Adrian's got a plan here, so I'll let him answer more completely if he wants :) > Not to forget: newforms will have a big influence on generic views, > too. Good point; someone's going to need to rework those, as well. Jacob --~--~-~--~~~---~--~~ 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: Moving towards Django 1.0
Jacob Kaplan-Moss schrieb: > On 1/12/07 6:40 PM, Michael Radziej wrote: >> Adrian said that he wanted to make inline collections easier. I >> thought that this is a real big thing, and will completely redefine >> how the admin implements inline editing. And probably deeper. (Just >> had a look at AutomaticManipulator.save ... gosh) > > Heh. > > Yeah, this is part of reworking the admin to use newforms. I think Adrian's > got a plan here, so I'll let him answer more completely if he wants :) If he did, this thread would be overtaken by discussions about newforms, widgets, and html vs. xhtml ;-) Michael -- noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg - Tel +49-911-9352-0 - Fax +49-911-9352-100 http://www.noris.de - The IT-Outsourcing Company --~--~-~--~~~---~--~~ 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: Moving towards Django 1.0
Jacob Kaplan-Moss wrote: > I'd like to appoint a "leader" for each "topic" (unstable API and must-have). > This person will have checkin access to their area of interest so they'll > need to be someone who's already got checkin or someone who's skilled enough > to deserve it. This person can either tackle the issue alone or else form a > team to get it done. Here's my list -- any nominations for the missing slots? What about things that don't match any of those things? Should misc. patches be discussed before or after .96? --~--~-~--~~~---~--~~ 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: Moving towards Django 1.0
On 1/12/07 6:55 PM, Jeremy Bowers wrote: > What about things that don't match any of those things? Should misc. > patches be discussed before or after .96? Well, you'll need to be a bit more specific about what "things" you're talking about. I think, though, that there are three possibilities for any "thing": * If Feature X absolutely can't be implamened post-1.0 without breaking 1.0 APIs, then it needs to be accepted or rejected now. This case covers BIG features like, well, rewriting Django's form handling. I don't think that there are many of these. * If Feature X could be done post-1.0, a decision about it would be made during the ticket triage process (step 2 in my outline). That decision will be either "reject", "accept", or "defer" (to 1.1 or whatever). * If X is a bug, it will be fixed before 1.0. Does that answer your question? Jacob --~--~-~--~~~---~--~~ 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: Moving towards Django 1.0
Jacob Kaplan-Moss wrote: > On 1/12/07 6:02 PM, Malcolm Tredinnick wrote: > >> * Autoescaping: I think this needs to stay on the radar at least. We >> came dangerously close to a consensus on this (both in discussions on >> this list, based on Simon's proposal) and the discussions you, I and >> Adrian had at OSCON. >> > > Ah, yes :) > > I think I'm really the only one who's still holding out for manual escaping, > so in the interests of Getting Things Done I'm gonna shut up about it. Is > there anyone besides me who *doesn't* want auto escaping (in some form) in > Django? If so, let's hear it now. > > I would prefer that auto-escaping didn't make it into Django. It may be an overly utopian ideal, but I think security issues, including escaping, should be a conscious effort involving research and understanding of the situation. Without that, it's like blindly adding bandaids to your application hoping they'll keep the holes closed. Besides, auto-escaping reminds me of PHP's "magic quotes" and we all know how well that turned out... :) Chris --~--~-~--~~~---~--~~ 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: Moving towards Django 1.0
On 1/12/07, Chris Nelson <[EMAIL PROTECTED]> wrote: > I would prefer that auto-escaping didn't make it into Django. It may be > an overly utopian ideal, but I think > security issues, including escaping, should be a conscious effort > involving research and understanding of the > situation. Without that, it's like blindly adding bandaids to your > application hoping they'll keep the holes closed. > > Besides, auto-escaping reminds me of PHP's "magic quotes" and we all > know how well that turned out... :) This comment set off all of my here-comes-a-200-message-mailing-list-saga alarms, so before anybody responds to this, *please* start the response in another mailing-list thread. Adrian -- Adrian Holovaty holovaty.com | djangoproject.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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Moving towards Django 1.0
On 1/12/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > Yeah, as I think about it, I think docs are important enough they need their > own "leader" as well. That person could additionally take control of the > documentation index -- which is getting a bit difficult to use -- and the FAQ. I've volunteered in the past and will happily volunteer again to take up maintenance and organization of the docs. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Autoescaping for 1.0
Rather than clog up the main "1.0" discussion, let's move this to a side discussion. We need to come to a consensus on Django autoescaping - I'll put in my 2c for my alternative (http://code.djangoproject.com/wiki/AutoEscape%20alternative) of course, but whichever direction we go, it'd be good to actually start going there. Questions off the top of my head: How "auto" is autoescaping going to be? If I recall, previous consensus seemed to be off by default, easy to switch on. Are we only worried about HTML autoescaping? (as opposed to JS or any other escaping people may want) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Configuration Refactoring
Okay, I've been working with django for a little while, and I thought
I'd share my experience and point out some things that bugged/confused
me at first. Looking at settings.py:
MEDIA_* is poorly named since they overload the meaning of 'media'
which otherwise relates back to the static css/img/js content.
MEDIA_UPLOAD, or something else would be clearer. If this is not
changed then the description needs to be made more obvious.
MEDIA_URL is basically invalid if left blank - it resolves to a file in
the root server directory. It seems like it should work with relative
urls (so not to specify the domain name - great for debugging from
local sources). It might be beneficial to remind the user that they
need to do two things to make the configuration work:
1) add the exception to their .htaccess file (if media_url is a child
of the django root) to let their httpd find their directory
2) add the 'if DEBUG..." conditional and urls.py mapping if they want
to use the local test server.
There should be some mention about that here.. I'm sure it would make
the configuration process more clear.
Perhaps:
"MEDIA_UPLOAD_ROOT: absolute location to store uploaded content on the
local file system. This directory needs to be writable by the server
process."
"MEDIA_UPLOAD_URL: Absolute URL (http://whatever.com/media/) or
relative to the host url (/media/) from which to serve uploaded media"
Supporting the Built-in and Production server in the General Case
-MEDIA_UPLOAD is a special case for django, since it is necessary for
the django process to receive files (can't be delegated to remote
server, without much more work [I suppose you could have a form submit
to another server, but then you'd lose any benefit])
For all other static content serving, django avoids making any
commitments as to location.
I think it is a smart idea to separate the concerns of the dynamic and
static content. Django shouldn't be responsible for locating or serving
these files. That being said, the current setup (especially when using
the built-in server) makes this task more difficult than it needs to
be.
At the moment, anything non-django being served by the same host must
be specified as an exception in both the .htaccess file (to prevent
urls.py lookup, please correct me if I'm wrong), and in urls.py (for
the local
test server, again as recommended in a "if debug" conditional [also
maybe it should be an if "debug_server"]).
This is duplication.
The separation of concerns becomes a hindrance to flexibility - I'm not
sure how Adrian implemented it, but when he moved his static hosting to
the Amazon service I'm sure he would have liked to have a STATIC_URL
setting which would have allowed him to simply insert a new base url,
and have requests automatically redirected to the remote server
transparently. No matter how easy it is to modify the template, or add
in dynamic references is (say by prepending {{media_host_root}}) this
is still bound to be more error prone and require thought on the part
of the media producer.
This is nothing that can't be handled with exclusively in mod_rewrite,
at least in production. And in the urls.py for testing. The problem,
and obvious downside to just doing it that way:
1) two different configs to keep in sync
2) all requests are still made to the django host, so there is still
the overhead of dealing with each redirect (but not serving content!)
The solution I'd recommend is to extend urls.py to emit the redirects.
If .htaccess has been fixed, they should never be reached anyway. That
way, both testing and production configuration can be unified in one
place.
This is a hard issue. I know this decision was not made lightly. I
agree that it is doesn't make sense to have django be responsible for
actually serving static media. But a middle ground solution would be
easier to maintain.
Gil Pinheiro
--~--~-~--~~~---~--~~
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: Autoescaping for 1.0
SmileyChris wrote:
> Rather than clog up the main "1.0" discussion, let's move this to a
> side discussion.
>
I can add some personal experience to this.
At work, we use Apache::ASP (perl-based), which uses <%= $value %> to
dump out a string directly into the HTML. After one too many XSS bugs
(particularly the one I wrote even though I absolutely know better), we
re-wrote our Apache::ASP to auto-HTML escape with <%= $value %>, and
added a <%! $value %> to do the original no-escaping. (We chose !
because we wanted the connotations of ""; it should be something you
stop and think about and make sure you have correct.)
Since then, to the best of my knowledge, we've never written an XSS,
whereas before it was a laborious process to explain to each employee
(sometimes more than once...) that you have to escape *everything*.
In practice it works out very well. I think that's because it's
***way*** easier to notice that you've got something excessively
escaped, and even if it happens it's usually not the end of the world,
whereas not having something escaped enough is a security hole. We've
had no trouble dumping out JS fragments by manually turning off the
escaping. (That's one case where excessive escaping becomes as obvious
as the nose on your face, when you see the script tag on the screen.)
I've also discovered that even relatively skilled developers can have a
lot of trouble catching every case that needs to be escaped, whereas
almost any developer can correctly determine when *not* to escape
something. The "it didn't work, I'll do X" algorithm that is so popular
is a lot safer when X is "turning off escaping" instead of "turning on
escaping".
Based on my experience, both of the suggestions on the Wiki are
heavier-weight than they need to be. I would suggest yet a third
alternative:
* Always escape the output of {{ and }}. (I would not make this
something that has to be turned on. If you insist, you could make it
something that could be turned *off*, but I'd rather wait for people to
ask for/demand that feature before adding it.)
* Add a filter to allow this to be bypassed: {{ obj.value | noHTMLescape
}}.
That's it. Works well in practice, I think. I think you'll find the
impact in practice on existing templates is less than you expect; the
usual case, dumping an attribute or plain-text, silently goes from
"potential security flaw" to "working correctly"; it's only in the
relatively rare cases where you're doing something else that you'd have
to actually change something. I'll trade "subtle and pervasive security
flaws" for "obvious overescaping bugs" any day.
If I had my way, I'd probably go with {{! obj.value !}} instead of {{
obj.value|noHTMLescape }}, but I suspect that would be too radical for
Django. It would admittedly tempt people to put other symbols there,
although so far we haven't been tempted. But if you do like it, hey, great.
--~--~-~--~~~---~--~~
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: Autoescaping for 1.0
Jeremy Bowers wrote: > I've also discovered that even relatively skilled developers can have a > lot of trouble catching every case that needs to be escaped, whereas > almost any developer can correctly determine when *not* to escape > something. The "it didn't work, I'll do X" algorithm that is so popular > is a lot safer when X is "turning off escaping" instead of "turning on > escaping". +1 on a noescape "filter" (I'm not too familiar with the template code but it seems like it would have to be a special case rather than a real filter). The reason given above sounds right to me: people know when they don't want something to be escaped. What about escaping more than just HTML? --~--~-~--~~~---~--~~ 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: Autoescaping for 1.0
Brian Beck wrote: > +1 on a noescape "filter" (I'm not too familiar with the template code > but it seems like it would have to be a special case rather than a real > filter). The reason given above sounds right to me: people know when > they don't want something to be escaped. Although, this does make generating non-SGML formats a bit more inconvenient. --~--~-~--~~~---~--~~ 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: Autoescaping for 1.0
On 13 Gen, 06:02, "SmileyChris" <[EMAIL PROTECTED]> wrote: > We need to come to a consensus on Django autoescaping There's an interesting discussion on GvR's blog, with several mentions of escaping: http://www.artima.com/forums/threaded.jsp?forum=106&thread=146606 Speaking of Django 1.0, it also contains this promise from Adrian: :-) "Note that at the moment Django needs an environment variable DJANGO_SETTINGS_MODULE, as Guido mentioned, but that dependency for the template system will soon go away -- as I mentioned in a previous comment in this forum." -- Nicola Larosa - http://www.tekNico.net/ Cannavaro Cannavaro Cannavaro, what else is there to say? [...] He stopped Klose and he stopped Ballack and he stopped Podolski and he stopped Odonkor and he stopped Schneider and he stopped Schweinsteiger, most of them more than once. [...] Cannavaro was the knife in Germany's heart. -- Tim Bray, July 2006 --~--~-~--~~~---~--~~ 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: Web services in Django
2006/12/22, juampa <[EMAIL PROTECTED]>: > > Hello all: > > I am trying to gather all the information I can about implementing web > services with Django (XML-RPC, SOAP, REST). Can you suggest good > sources of information/examples of implementations? What is the offical > status of WS support in Django? Thanks. Here is a really interesting ticket: http://code.djangoproject.com/ticket/115 Maybe it's time to collect all ressources in order to progress, feel free to add yours: On the web: * XMLRPC in Django http://www.allyourpixel.com/post/xmlrpc-djgo/ * Django Ajax Redux http://lazutkin.com/blog/2005/dec/10/django-ajax-redux/ On mailing-lists: * Extend URL resolver support for HTTP Methods / REST support: http://groups.google.com/group/django-developers/browse_thread/thread/15056b2979180228/e9c4c94408a54f44 * metaapi: Django Meta-API - Invitation to Criticize! http://groups.google.com/group/django-developers/browse_thread/thread/639016969c4cd323/745e4111d3835634 * Django, RDF & XUL http://groups.google.com/group/django-users/browse_thread/thread/da7638815273dbcd/c0a371f9f6ebd286 * REST-like web services in Django http://groups.google.com/group/django-users/browse_thread/thread/9f438744f6be28b4/bf7d2d3314d4df0f * A RESTful Django? http://groups.google.com/group/django-users/browse_thread/thread/540bce06cda01fc7/056d6c595547abc9 Ok, a lot of people waiting for this "feature" but it's not really easy to deal with all possibilities so let's get back to the discussion. Cheers, David --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Reminder: PyCon early-bird registration ends Monday
Howdy folks -- A quick reminder: Monday 1/15 is the last day for early-bird registration for PyCon (you'll save $65). I'm told that my Django tutorials are nearing capacity, so if you're interested in either of them, you should likely sign up sooner rather than later. See you in Dallas! Jacob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
