Re: If there was massive security hole found in Django, are there plans in place to deal with it?
On 8/10/06, e <[EMAIL PROTECTED]> wrote: > Hopefully this is not out-of-line in this thread. I am a Rails person, > not a Django person, although I have written a lot of Python in the > past. I can give you some more information about the fallout in the > rails community which might help you formulate your policy. Thanks very much for that detailed writeup, Evan! It's very helpful, indeed. 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 -~--~~~~--~~--~--~---
Re: Admin lockout
On 8/10/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > I'm not so sure about this... It seems like protecting people from > themselves. Presumably the "real" superuser has access to Python code > and the database, so that person can make the change in the database, > or via the Python API, if worse comes to worse. Yeah, that's what I did. I just didn't know that superuser=coder. Thanks, Jeremy --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Admin lockout
On 8/10/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > In the admin, it's possible to disable all superuser accounts. It'd > be good to not allow the last one, or to warn against it. I'm not so sure about this... It seems like protecting people from themselves. Presumably the "real" superuser has access to Python code and the database, so that person can make the change in the database, or via the Python API, if worse comes to worse. 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 -~--~~~~--~~--~--~---
Admin lockout
In the admin, it's possible to disable all superuser accounts. It'd be good to not allow the last one, or to warn against it. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: If there was massive security hole found in Django, are there plans in place to deal with it?
Hi, Hopefully this is not out-of-line in this thread. I am a Rails person, not a Django person, although I have written a lot of Python in the past. I can give you some more information about the fallout in the rails community which might help you formulate your policy. I agree with Simon, except that I think that close to full disclosure would have been much better considering the circumstances. What the problem came down to was that the patches offered by Rails core were very shoddy. They introduced new vulnerabilities where previously there were none, and broke a lot of applications. If they had kept quiet about the issue for a few more days and then released all the patches along with a small note "recommended security update", and a non-alarmist discussion of the source of the issue, there would not have been so much trouble. The primary cause of the problem had been reported in the ticket system for some months already, so it shouldn't have been a surprise. But suddenly someone in rails core realized you could combine that with another unrelated feature to cause data loss. If the patches had worked, people wouldn't have minded the zero disclosure so much. But without good patches and also without full disclosure everyone was left high and dry. Even partial disclosure would have helped a lot (and it was definitely a possibility, since exploiting the flaw requires a combination of unrelated parts of the application stack). People in situations requiring risk management had absolutely no options, and everyone lost a lot of time. Also, the response of some community members to those pressing for full disclosure was very nasty, along the lines of "it worked fine on my blog, suck it up and upgrade", "diff it yourself" (for a problem deep inside the application stack), and "we don't want the enterprise here anyway". Evan I am sure there are other sides to the story, but here is how I perceived it. Timeline (inexact) 5 pm EST: I was working on a plugin and the latest Rails svn co suddenly broke some auto-loading functionality. Inspection of the source showed sweeping changes in the routing and library loading. 7 pm: weblog.rubyonrails.org posts a hand-wringing warning: "This is a MANDATORY upgrade for anyone not running on a very recent edge (which isn't affected by this). If you have a public Rails site, you MUST upgrade to Rails 1.1.5. The security issue is severe and you do not want to be caught unpatched.The issue is in fact of such a criticality that we're not going to dig into the specifics. No need to arm would-be assalients." Channel #rubyonrails on freenode goes nuts. 11 pm: incompatibilities and breakages are being widely reported with the patch for recent Rails installs on Windows, and for applications that use a type of scaffolder called "Engines". Also, there are many known incompatibilities between Rails 1 and Rails 1.1.5. Response from core seems to be "suck it up". Everyone starts manually upgrading their old apps. Not wanting to upgrade one of my apps from a May svn co, but obviously not having a specific patch for that random revision, I investigate the changes along with some others on IRC. 3 am: first reports from diff'ers willing to publicly disclose appear on ruby-forum and on personal blogs. Accuracy increases as the night goes on, but basically we had it right. The vulnerability seems severe but not impossible to migitate without resorting to patches. 4 am: same people report that there is no reason to think that Rails 1 is affected. Also, the 1.1.5 patch is incomplete and apparently introduces part of the vulnerability into previously safe Rails 1 installations. 7 am: Rails core confirms that the vulnerability does not effect 1. 7 pm: Rails core posts a new patch, 1.1.6, to fix problems in the previous patch, as well as backports to all affected tags. Testing on all combinations of webservers and rails versions is still going on, and the patch might not be final. The patch does still not support Rails Engines. They also partially verify what the actual problem is and suggest that their hand was forced by the reports circulating on the web. Simon Willison wrote: > James Bennett wrote: > > On 8/9/06, Jason Huggins <[EMAIL PROTECTED]> wrote: > > > I can see how a policy like that is "tricky"... What's to keep an evil > > > blackhat from subscribing to the very same list so he he knows when to > > > get busy cracking sites using the same information? > > > > I've been watching people go round and round about this in various > > places today, and I have to say that I can respect the Rails team's > > policy of not releasing full details of the vulnerability until after > > their users have had a little time to patch. Full disclosure still > > happens, but it's slightly safer for end users this way. A couple > > other open-source projects I've used/been involved with have followed > > a similar policy of "update ASAP, and we'll release details once > > people have
Re: Dependency problem in flatpages...
- Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: [snip] > Have a poke around in django/core/management.py in the > _get_sql_model_create() function and see if you can work out why we're > getting this wrong. > > The fact that the generated SQL has a "...REFERENCES ..." clause on the > problem line, rather than trying an "ALTER TABLE..." statement later > (out of _get_sql_for_pending_references()) means that the code thinks > that table has already been created. We try hard not to do that. So I > suspect this is a silly bug somewhere and it might be easy to fix if you > drop in a few print statements and have an already failing example. > > I didn't know we allowed wildcards there (although it makes sense that > it would work, whether intended or not), but the output is close to > correct, so it might easy enough to work out what is going wrong. Thanks! I'll try and take a look this weekend and see if I can resolve this issue. -John --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Proposal: make templatetag loading magic a little more invisible
On 8/11/06, James Bennett <[EMAIL PROTECTED]> wrote: > The reason for this is that django/templatetags/__init__.py, when it > loops over INSTALLED_APPS to find templatetag libraries, > indiscriminately quashes ImportError -- apparently on the assumption > that any ImportError being raised is a result of a non-existent > 'templatetags' module. > > This is both frustrating and counterintuitive. I agree. Similar ignoring of ImportErrors in core/management.py has caused me many hours of unproductive head-slapping. > > There are two ways I can think of to solve this problem: > 2) Tweak django/templatetags/__init__.py to introspect the ImportError > it gets and figure out whether the exception came from a non-existent > 'templatetags' module (in which case it can be safely quashed) > Obviously I prefer the latter, since it results in more intuitive > behavior, but I'm interested in hearing what other people think about > this. I agree. Django should not be asking it's users to write boiler-plate code, even if that boiler-plate may be found somewhere 'obvious' in the documentation. a --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: django and LDAP support
On Thu, Aug 10, 2006 at 12:41:21PM -0600, Scott Paul Robertson wrote: > 2. An option that is a function that will be called to generate a bind > string for the user. This gives a lot of flexibility in allowing for a > large variety of pre-bind methods to occur, and gives a lot of > flexibility. I like the idea of adding this rather than an additional > method to be added into the main backend code. > > Let me know what you think of having that as a function you call rather > than being directly in the backend. I'm not against adding it in, I just > think this gives a lot more flexibility. Heck, we could add the method > of pre-auth binding as a default method provided by the backend and just > have users set the option to that if they want to use it. I actually > like that idea, I might code that up this afternoon. :) > Ok, I've added a newer patch that fixes a small bug (the bind string functions now expects the ldap object and the username), and added a method that performs the pre-auth as requested, with an example of how to use it. So now we've got that functionality, and any additional ways to generate bind strings that you can dream of. I'm enjoying this far too much. I need to get back to work :) Scott (url: http://code.djangoproject.com/attachment/ticket/2507/backends.py.3.diff) -- Scott Paul Robertson http://spr.mahonri5.net GnuPG FingerPrint: 09ab 64b5 edc0 903e 93ce edb9 3bcc f8fb dc5d 7601 signature.asc Description: Digital signature
Proposal: make templatetag loading magic a little more invisible
This is a bit long for a ticket writeup, but I wanted to get some
comments on it, so here goes:
The "magic" that still goes on in the templatetag system has been
discussed before on the list[1], and the consensus was that, since
it's relatively invisible and harmless, it's OK for it to stay.
Except it's not completely invisible and harmless. Consider a
templatetag library, living in 'myproject/myapp/templatetags/', which
looks like this:
from django.template import Library
import foo
register = Library()
def add_foo():
return foo.bar()
register.simple_tag(add_foo)
If the application which includes this library is installed on a
machine which doesn't have the 'foo' module, we would expect to get an
ImportError saying "No module named foo".
But instead, if we try to do '{% load myapp %}' in a template, we'll
get a TemplateSyntaxError and the message that 'myapp' is not a valid
tag library. Even worse, the ImportError will have completely
disappeared; the exception will appear to have originated as
InvalidTemplateLibrary.
The reason for this is that django/templatetags/__init__.py, when it
loops over INSTALLED_APPS to find templatetag libraries,
indiscriminately quashes ImportError -- apparently on the assumption
that any ImportError being raised is a result of a non-existent
'templatetags' module.
This is both frustrating and counterintuitive.
There are two ways I can think of to solve this problem:
1) Document the way templatetag loading works, and advise tag authors
to wrap any imports they need in try/except and handle the situation
as appropriate (for example, by returning nothing from their tag, or
possibly raising ImproperlyConfigured with a message that a given
third-party module needs to be installed). This is a bit of a wart,
but at least it would get the issue documented so that people don't
have to go digging in the source to figure out what causes it.
2) Tweak django/templatetags/__init__.py to introspect the ImportError
it gets and figure out whether the exception came from a non-existent
'templatetags' module (in which case it can be safely quashed) or from
something in a tag library failing to import a needed module (in which
case the exception should keep propagating in some form so it will
appear in the eventual traceback). Given that we know what the
exception would look like for a non-existent templatetag library ("No
module named myapp.templatetags"), this probably wouldn't be terribly
hard to accomplish.
Obviously I prefer the latter, since it results in more intuitive
behavior, but I'm interested in hearing what other people think about
this.
[1]
http://groups.google.com/group/django-developers/browse_thread/thread/f9aec919b1449539/cb7a69b7e4b6447e
--
"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
-~--~~~~--~~--~--~---
Thoughts on extensibility of the admin app
Hi all I'm just thinking out loud here. Don't know if something like this is even wanted in django land. I've been playing around with trac lately and am rather fond of their light weight component architecture [1]. I was wondering if an approach like this may be a good idea for the django admin application. If done right it would make it possible/easy to hook into the admin app and extend it or change existing features and behavior. Anyway, I just wanted to hear what other people think about this. best wishes Steven [1] http://trac.edgewall.org/wiki/TracDev/ComponentArchitecture --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: django and LDAP support
On Wed, Aug 09, 2006 at 10:22:24PM -0600, Scott Paul Robertson wrote: > > Also, in the ldap setup I deal with, you must bind to the server using > > a service account before attempting a bind with the user-supplied > > credentials. The process goes something like > > > > 1. Retrieve the username and password from the user. > > 2. Bind to the directory using DN and password of service account. > > 3. Issue a search query to determine the user's DN based on their > > username. > > 4. Attempt to bind to the directory using the user's DN retrieved in > > step 3 and the password supplied by the user in step 1.. > > 5. A successful bind means that the user has been authenticated. An > > unsuccessful bind means that the credentials provided are invalid. > > > > This also seems to be the method used/needed in the second resource > > link you listed in your first post. It would be great if this method > > could be supported. It would require a few more options like > > LDAP_SERVICE_BIND_DN > > LDAP_SERVICE_BIND_PASSWORD > > and then an additional check in authenticate() (after the call to > > initialize() and before the bind with the user's DN and password) to > > see if first a bind should be attempted with the service account DN and > > password. > > > > I'll start on this tomorrow. Out of curiosity how common is this sort of > setup? I've only seen a handful of LDAP implementations, and this is new > to me. > Ok, I've added a patch that adds two new things: 1. You can have a hash of ldap options (key: ldap.SOME_OPTION, value: 'the value') that will be applied before the initialize call. 2. An option that is a function that will be called to generate a bind string for the user. This gives a lot of flexibility in allowing for a large variety of pre-bind methods to occur, and gives a lot of flexibility. I like the idea of adding this rather than an additional method to be added into the main backend code. Let me know what you think of having that as a function you call rather than being directly in the backend. I'm not against adding it in, I just think this gives a lot more flexibility. Heck, we could add the method of pre-auth binding as a default method provided by the backend and just have users set the option to that if they want to use it. I actually like that idea, I might code that up this afternoon. :) (url: http://code.djangoproject.com/attachment/ticket/2507/backends.py.2.diff) -- Scott Paul Robertson http://spr.mahonri5.net GnuPG FingerPrint: 09ab 64b5 edc0 903e 93ce edb9 3bcc f8fb dc5d 7601 signature.asc Description: Digital signature
Re: If there was massive security hole found in Django, are there plans in place to deal with it?
Adrian Holovaty wrote: > On 8/10/06, Jason Huggins <[EMAIL PROTECTED]> wrote: > > At this point, I'll leave it to the project admins to decide how to > > procede. But a new "django-announce" Google group sounds like the > > logicial next step. > > I've created the django-announce mailing list: Thanks, Adrian. :-) - Jason --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: If there was massive security hole found in Django, are there plans in place to deal with it?
James Bennett wrote: > On 8/9/06, Jason Huggins <[EMAIL PROTECTED]> wrote: > > I can see how a policy like that is "tricky"... What's to keep an evil > > blackhat from subscribing to the very same list so he he knows when to > > get busy cracking sites using the same information? > > I've been watching people go round and round about this in various > places today, and I have to say that I can respect the Rails team's > policy of not releasing full details of the vulnerability until after > their users have had a little time to patch. Full disclosure still > happens, but it's slightly safer for end users this way. A couple > other open-source projects I've used/been involved with have followed > a similar policy of "update ASAP, and we'll release details once > people have had time to patch", and it's caused no harm that I've > seen. There are two principle reasons the Rails issue has gone over badly with the community: 1. Forced upgrade to 1.1.5. This caused big problems for users on versions of Rails older than 1.1.4 - people still using Rails 1.0 for example. With hindsight, I think it's obvious to everyone that the Rails team should have prepared patches for other affected versions rather than forcing people to upgrade. Thankfull, Django security policy already takes this in to account: http://www.djangoproject.com/documentation/contributing/#reporting-security-issues "Halt all other development as long as is needed to develop a fix, including patches against the current and two previous releases." 2. The full disclosure problem. The argument against fully disclosing the problem seems pretty solid: it's a serious exploit (it appears to allow remote Ruby code execution) and they wanted to give Rails users a head-start on the attackers. Here's the argument against (for those who haven't been following along): - The flaw can be found by running diff against 1.1.4 and 1.1.5. Any half decent attacker could do this. The Rails team actually included a red herring (an SQL injection unit test) to try to throw people off the scent, but that was never going to hold back anyone with a modicum of talent. Once one black hat had figured it out it would spread quickly via underground mailing lists and IRC channels, leaving white hats at a disadvantage. - Because users didn't know what the flaw was, they couldn't evaluate the solution to confirm that it was going to work. More importantly, they had nothing to judge how urgent the upgrade was or if there was some other short-term measure they could take to protect themselves. The biggest complaints are due to a combination of the above factors. The initial announcement stated that more versions of Rails were affected than was actually the case. This resulted in some users spending hours upgrading their applications, only to later find that the version of Rails they were running was safe. This would not have been an issue had full disclosure let them (or the community) analyse the problem in more depth. It also wouldn't have been an issue if patches had been released for older Rails versions. Based on all that, I think the principle lesson from the whole thing is that getting patches out for older releases is critically important. Luckily this is already listed as Django policy. I doubt that full disclosure would have been as much of an issue as it has if they had got those patches out straight away. Like Jeremy said, this stuff is hard. Some good background reading on the Rails situation: http://weblog.rubyonrails.org/2006/8/10/security-update-rails-1-0-not-affected (the comments) http://www.ruby-forum.com/topic/76671 Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: If there was massive security hole found in Django, are there plans in place to deal with it?
On 8/10/06, Jason Huggins <[EMAIL PROTECTED]> wrote: > At this point, I'll leave it to the project admins to decide how to > procede. But a new "django-announce" Google group sounds like the > logicial next step. I've created the django-announce mailing list: http://groups.google.com/group/django-announce django-announce is a low-traffic, read-only mailing list that distributes announcements about the Django Web framework. Topics include new Django releases, significant feature additions and security alerts. 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 -~--~~~~--~~--~--~---
Re: If there was massive security hole found in Django, are there plans in place to deal with it?
Jyrki Pulliainen wrote: > On 8/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > For notification what about a low-volume django-announce group / > > mailing list specifically for disclosures and point version upgrades? > > This gives something for vendors etc to subscribe to and follow, and > > patches etc can be announced in here before djangoproject.com or, say, > > reddit. > > I second Simon on this one. And I third it. :-)... At this point, I'll leave it to the project admins to decide how to procede. But a new "django-announce" Google group sounds like the logicial next step. - Jason --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: If there was massive security hole found in Django, are there plans in place to deal with it?
On 8/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > For notification what about a low-volume django-announce group / > mailing list specifically for disclosures and point version upgrades? > This gives something for vendors etc to subscribe to and follow, and > patches etc can be announced in here before djangoproject.com or, say, > reddit. I second Simon on this one. I've been an admin for different platforms and softwares for a long time now. Propably the one of open source projects people on this list might know is the Gallery. What gallery has is an separate announce list. The clear advantage is the fact that when the announce list is a read-only (eg. no discussion on that list), all the vital information does not get lost between other posts. Also, the announce list doesn't fill your mail account to the limits with "How does the feature xyz work? How can I change the background?"-posts, it only has all the vital information about new versions and possible security flaws (which, sadly, the Gallery has a _lot_). So, a separate announce-list would make it easier for the end user or vendor to filter all update and security related material related to Django. You all propably agree with me, that catching that kind of information from the django-users list is almost impossible. -- Jyrki // [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 -~--~~~~--~~--~--~---
Re: JavaScript and Changeset 3541
The main reason why I switched was more timing then anything else. I wanted to try a few different toolkits to practice with them and find out the differences. I have never touched AJAX before this summer. I tried Dojo first and did like it, and wrote some working code, which I should be able to rewrite to be more efficient (or the other option I stated below). When I started with YUI I had a much better understanding of what I wanted to do and AJAX/Javascript itself, so I found the code I wrote with YUI working a bit better. The work can be moved to Dojo fairly easily, as it mostly is rewriting the actual AJAX communication, the animations (which can easily be removed, mostly there from me practicing with them, and the DOM commands). The remaining JS is outputting the return message, creating a new row, etc. which is non-toolkit specific. If the opinion is to remove the AJAX code totally, I can do this in such a way that it can be easily reinserted at such a point where we want to implement AJAX into the admin interface. For now, I'll separate the AJAX JS and the non-AJAX js and it can be decided what remains and what goes. Cheers, 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 -~--~~~~--~~--~--~---
Re: Dependency problem in flatpages...
On Thu, 2006-08-10 at 05:55 -0400, John Szakmeister wrote: > Now that the magic has been removed, and Django released 0.95, I decided to > start porting my applications over. I knew the merge of magic-removal was > coming, so I never deployed the apps. So, I decided to dump the tables that > I had (there was no useful information in them) and start over. Well, my > project had the following in the settings file: > INSTALLED_APPS = ( > 'django.contrib.*', > 'www.apps.blog', > 'www.apps.jobs', > ) [...] > The problem is that the tables for django.contrib.sites aren't created > before the flatpages tables. I made a simple change to the settings > file to include the sites app before the others, so it was an easy > fix. > > The reason I bring it up at all is that if were going to allow a > wildcard, it seems reasonable to expect that interdependencies are > going to be worked out, and the tables will be created in the right > order. Otherwise, the wildcard loses some of it's appeal. Is there a > simple way to extract the dependencies on other apps models, before > the tables are created? If so, I can take a stab at fixing syncdb to > Do The Right Thing. Have a poke around in django/core/management.py in the _get_sql_model_create() function and see if you can work out why we're getting this wrong. The fact that the generated SQL has a "...REFERENCES ..." clause on the problem line, rather than trying an "ALTER TABLE..." statement later (out of _get_sql_for_pending_references()) means that the code thinks that table has already been created. We try hard not to do that. So I suspect this is a silly bug somewhere and it might be easy to fix if you drop in a few print statements and have an already failing example. I didn't know we allowed wildcards there (although it makes sense that it would work, whether intended or not), but the output is close to correct, so it might easy enough to work out what is going wrong. Regards, Malcolm --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: If there was massive security hole found in Django, are there plans in place to deal with it?
For notification what about a low-volume django-announce group / mailing list specifically for disclosures and point version upgrades? This gives something for vendors etc to subscribe to and follow, and patches etc can be announced in here before djangoproject.com or, say, reddit. --Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: django unicode-conversion, beginning
On 8/10/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > > Malcolm Tredinnick wrote: > > I completely agree this is painful and normally I would punt. But my > > crystal ball tells me that you will then get bug reports from Mr > > Sagalaev, who is generally both very diligent in his debugging and likes > > to use some language with a funny alphabet. If whatever you come up with > > works naturally in places like Ivan's setup and maybe somebody who lives > > in Hong Kong or Japan or some other East Asian locale, you could > > consider this "solved" to some extent. > > I'm afraid I'm not very good tester with this exact problem. Python on > my Ubuntu happily says 'UTF-8' when asked > 'locale.getpreferredencoding()'. But indeed I can always try these > things with my compatriots using Windows or configuring their linuxes > with old single-byte 'KOI8-R'. > > In fact I was under impression that a string returned from this function > can be safely used for decoding. For example on Russian Windows it > returns 'cp1251' which works perfectly well while not being a standard > ISO name which is 'windows-1251' and works well also. > > So may be we can just rely on Python's smart little brain and do > something like this: > In python Lib/encodings/aliases.py, you would find the encoding name mapping table. -- I like python! My Blog: http://www.donews.net/limodou My Django Site: http://www.djangocn.org NewEdit Maillist: http://groups.google.com/group/NewEdit --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: django unicode-conversion, beginning
gabor wrote: > hmmm.. are you sure that the situation with unicode-aware editors is so bad? > > could you name some non-unicode-aware editors? > for me it seems that from notepad through vim to eclipse everything does > unicode fine... Ok, I should rephrase it. Even if most editors do support utf-8 they aren't configured to do so by default. Unfortunately there is some notion that unicode is something "new" and "scary" and "who knows what problems it will cause". So there is a case when on systems where utf-8 is not default environment setting (meaning all Windows and many Linuxes) if a programmer starts his favorite text editor odds are that it will not save a new file in utf-8. But to be sure I'll better run a poll on my forum about it... --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: django unicode-conversion, beginning
Malcolm Tredinnick wrote: > I completely agree this is painful and normally I would punt. But my > crystal ball tells me that you will then get bug reports from Mr > Sagalaev, who is generally both very diligent in his debugging and likes > to use some language with a funny alphabet. If whatever you come up with > works naturally in places like Ivan's setup and maybe somebody who lives > in Hong Kong or Japan or some other East Asian locale, you could > consider this "solved" to some extent. I'm afraid I'm not very good tester with this exact problem. Python on my Ubuntu happily says 'UTF-8' when asked 'locale.getpreferredencoding()'. But indeed I can always try these things with my compatriots using Windows or configuring their linuxes with old single-byte 'KOI8-R'. In fact I was under impression that a string returned from this function can be safely used for decoding. For example on Russian Windows it returns 'cp1251' which works perfectly well while not being a standard ISO name which is 'windows-1251' and works well also. So may be we can just rely on Python's smart little brain and do something like this: - try decoding from locale.getpreferredencoding() - failing that try something safe like iso-8859-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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: If there was massive security hole found in Django, are there plans in place to deal with it?
James Bennett wrote: > One would hope that anyone who's using Django is subscribed to > django-users and/or watches the Django blog This would be less and less true as time goes because Django will spread beyond early adopters to a new forming local communities. For example there is russian Django's LiveJournal community where I suspect many people read just that list and not django-users because either they're already happy with local list or just don't feel comfortable enough with English to read it on a dialy basis. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
"relative" limit_choices_to
Hi all,
I saw many posts on this list on the dynamic limit_choices_to but I
think my
question is a little bit different, but very common as well.
Here is a very simple example. I'd like to filter the streets in the
DrugStore edit page so that only the streets in the selected city appear, the
clumsy 'self'.city.id is here to illustrate that ... (it sounds to me like
the 'self' keyword used for recursive model linkage)
class City(models.Model):
pass
class Street(models.Model):
city = models.ForeignKey(City)
class DrugStore(models.Model):
city = models.ForeignKey(City)
street = models.ForeignKey(City, limit_choices_to =
{id_exact : 'self'.city.id})
Basically, my question is : is there a way to do that ("'self'.city.id") ? Can
you give me hints about how to code it if you have ideas and you think it
makes sense.
Cheers,
Z.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: JavaScript and Changeset 3541
James Bennett wrote: > On 8/9/06, Linicks <[EMAIL PROTECTED]> wrote: >> 1. Chris, would it be reasonable to move your work to Dojo? > > From the looks of things, that's how he'd implemented it at first; he > then switched to YUI. Do you know the reason? I am curious to know what was wrong. Thanks, Eugene --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
