Re: modularity of apps
James Bennett wrote:
> The more I think about it, the more I like the idea of using imports
> in __init__.py to specify an application's dependencies; the thing
> that'd make it especially nice would be some method -- either
> conventional or built straight in to Django -- of checking for
> "importable" versus "installed" and for throwing nicer error messages.
> Something like this, maybe:
>
> from django.conf import settings
>
> dependencies = (
> {'name': 'tags', 'module': 'foo.tags'},
> {'name': 'todo', 'module': 'bar.todo'},
> {'name': 'comments', 'module': 'django.contrib.comments'},
> )
IMO, the dependency checking is the easy part. In the README or
something, I say MyCoolApp requires the admin app. It's the
configuration settings of the admin app that's hairy.
So let's say MyCoolApp needs the admin app to function. (Let's ignore
the fact that, by default, Django adds everything to settings.py that
the admin app needs to run even though I don't need most of them if I'm
not using the admin app.) So, in MyCoolApp.__init__.py I put the
following:
dependencies = (
{'name': 'admin', 'module': 'django.contrib.admin'},
)
What has this bought me?
Not much considering I still need to make sure I have
ADMIN_MEDIA_PREFIX set, SECRET_KEY set,
'django.template.loaders.app_directories.load_template_source' in my
TEMPLATE_LOADERS,
"django.contrib.sessions.middleware.SessionMiddleware" and
"django.contrib.auth.middleware.AuthenticationMiddleware" and
"django.middleware.doc.XViewMiddleware" in my MIDDLEWARE_CLASSES,
'django.core.context_processors.auth' and
'django.core.context_processors.i18n' and
'django.core.context_processors.request' in my
TEMPLATE_CONTEXT_PROCESSORS,
'django.contrib.auth.backends.ModelBackend' in my
AUTHENTICATION_BACKENDS, "django.contrib.admin" in my INSTALLED_APPS,
and (r'^admin/', include('django.contrib.admin.urls')) in my urls.py.
Somebody help me if I ever wanted to bring down an application for
maintenance. Just removing it from INSTALLED_APPS ain't going to do
it. You can check the importing of an app or it's presence in
INSTALLED_APPS, but that app could still be a good ways from being
"installed."
> Anything more complex would be tending a bit too much toward the "app
> server", I think.
What do you mean a bit too much toward the app server? Isn't that what
we are all doing with django? Building and serving blog apps and forum
apps and news publishing apps and ...
--~--~-~--~~~---~--~~
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: modularity of apps
James Bennett wrote: > On 8/13/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > The Lawrence guys have mentioned on this list previously that they have > > many different applications they pull together in various projects. > > :) > > If we couldn't modularize, we wouldn't be able to sell different > "editions" of Ellington. Maybe they could enlighten us on how they modularize. --~--~-~--~~~---~--~~ 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: Session support
I think you meant "I used property() so you can use request.session.expires = 213123. " I wouldn't worry about the smart times -- just having seconds is good enough. --~--~-~--~~~---~--~~ 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: ANN: Small security hole in compile-messages.py fixed
On Aug 16, 2006, at 2:31 PM, Adrian Holovaty wrote: > > The Django team discovered and fixed a small security hole in the > django/bin/compile-messages.py helper script, which is the script that > compiles message files (.po files) into binary format (.mo files). Informative. I am certain that such security advisory will greatly enhance Django's image. Thanks to the excellent work of Adrian and the whole Django team! －Cheng Zhang http://www.ifaxian.com 1st Django powered site in Chinese ;-) --~--~-~--~~~---~--~~ 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: Trac and Akismet rejected spam
On 8/16/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > I have the same. I've tried to clean up the main wiki page and it > rejects the changes. Core-dev-types: would it be okay to whitelist these guys? --~--~-~--~~~---~--~~ 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
In China GB18030 is required to be used by law, any most sites just assume the browser uses that as the default, so they don't even specify a character encoding. Your likely setup for international web sites is to have Unicode in the database (since databases have special support for it and it is a good base encoding), but to serve up different encodings wherever UTF-8 proves problematic (for technical or legal reasons). Hopefully, over time, there'll be less and less resistance to using UTF-8. Rgds, Bjorn --~--~-~--~~~---~--~~ 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: > > currently my plan is to have the following behaviour: > > 1. i assume that every GET/POST param comes in encoded as > settings.DEFAULT_CHARSET, and will decode it accordingly. if it fails, > then it fails. Assuming "you got served" with settings.DEFAULT_CHARSET, then sure. > 3. will assume the database is in DEFAULT_CHARSET > - maybe can we somehow ask the db for it's charset? It would be a start. > so, what do you think? > or should we make it possible to have a system with mixed charsets? I could imagine serving web content with one encoding, but lumping things in and out of the db with another.I guess people will need mixed encodings - like wanting to serve utf8 rss feeds, but have latin1 come in and out of mysql. But so long as we sweep out bytestrings inside django for unicode objects, mixed i/o should be possible to add on later. Would being able to spec the db char encoding via settings.py be a needed option, or is that even possible across databases? cheers Bill --~--~-~--~~~---~--~~ 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/16/06, gabor <[EMAIL PROTECTED]> wrote: > 3. will assume the database is in DEFAULT_CHARSET > - maybe can we somehow ask the db for it's charset? I think you really have to allow for different charset in the DB-- legacy integration, remember. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Session support
I created a patch to implement a common feature. http://code.djangoproject.com/ticket/2548 The patch implements setting the expire per session. Are there any standards for django how APIs should be created? I like using request.session.expires = 213123. However is this okay API wise for Django? I'm going to be implementing request.sessions.expires = "3 weeks" soon. Also, I used property() so you can use request.session.expires(213123). Tsume --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
My current solution to auto-escaping
Having to remember to escape every variable node in an html template when it's the normal behaviour seems so un-DRY.What I wanted was a way of adding the escape filter to every variable node (eg {{
object.name }}) without changing the core django code.So I made a block tag which can add filters to all child variable nodes (finalfilter) and a filter for variable nodes which shouldn't be touched (finalized).
My current usage is to wrap my entire "base.html" with {% load filtertags %}{% finalfilter escape %} {% endfinalfilter %}.If every I have a variable node which I don't want to escape, I just do {% load filtertags %}{{ already_escaped|finalized }}, but this isn't very often.
I also made a block tag to apply filters to each item of a list to work with the unordered_list filter (listfilter). This one is just a fringe-need because undordered_list is ugly and I don't know why anyone would want to use it, but it could be useful for other custom filters I guess.
Anyway, here's the docstring for the finalfilter block tag: Add common filters to all variable nodes within this block tag. Use the `finalized` filter in a variable node to skip adding the filters
to that node. If a common filter has already been explicitly added to a variable node, it will *not* be added again. Filters can also be piped through each other, and they can have arguments -- just like in variable syntax.
Note: This tag adds the filter(s) at render time so this happens across all extended block tags. Example usage:: {% finalfilter escape %} {{ html_menu|finalized }}
{{ object.company }} {{ object.first_name }} {{ object.last_name }}
{% endfinalfilter %} This example would add the escape filter to the end of each variable node except for `html_menu`.
--~--~-~--~~~---~--~~
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 -~--~~~~--~~--~--~---
from django.template import Library, Node, TemplateSyntaxError
from django.template import VariableNode, Parser, FilterExpression, FILTER_SEPARATOR
register = Library()
FINALIZED_FILTER_NAME = 'finalized'
class FinalFilterNode(Node):
def __init__(self, nodelist, filters):
self.nodelist = nodelist
self.filters = filters
def render(self, context):
nodelist = self.nodelist
for node in nodelist.get_nodes_by_type(VariableNode):
node_filters = node.filter_expression.filters
filter_funcs = [filter[0] for filter in node_filters]
if finalized not in filter_funcs:
# Ignore the node if it has the finalized functions in
# its filters.
for filter in self.filters:
if filter[0] not in filter_funcs:
# Don't double-up on filters which have already
# been applied to this VariableNode.
node_filters.append(filter)
return nodelist.render(context)
class ListFilterNode(Node):
def __init__(self, context_list, filter_expr):
self.context_list = context_list
self.filter_expr = filter_expr
def render(self, context):
if context.get(self.context_list):
context[self.context_list] = self.recursive_filter(context[self.context_list])
return ''
def recursive_filter(self, item):
if hasattr(item, '__iter__'):
# If the item is iterable then recurse.
return map(self.recursive_filter, item)
return self.filter_expr.resolve({self.filter_expr.var: item}, ignore_failures=True)
def finalfilter(parser, token):
"""
Add common filters to all variable nodes within this block tag.
Use the `finalized` filter in a variable node to skip adding the filters
to that node. If a common filter has already been explicitly added to a
variable node, it will *not* be added again.
Filters can also be piped through each other, and they can have
arguments -- just like in variable syntax.
Note: This tag adds the filter(s) at render time so this happens across
all extended block tags.
Example usage::
{% finalfilter escape %}
{{ html_menu|finalized }}
{{ object.company }}
{{ object.first_name }} {{ object.last_name }}
{% endfinalfilter %}
This example would add the escape filter to the end of each variable node
except for `html_menu`.
"""
nodelist =
Re: django unicode-conversion, beginning
Jeremy Dunck wrote: > On 8/16/06, Bill de hÓra <[EMAIL PROTECTED]> wrote: >> Now. Most (all?) browser UAs sniff the content to second guess the media >> type. They don't much pay attention to Content-Type (I think maybe IE >> ignores it altogether). The problem for this example is they might be >> doing something similar for character encodings declared on the form >> page's GET request. Browsers do this because so much served content is >> mislabelled (eg feeds served as text/html and video as text/plain). > > IE doesn't totally ignore it. I just does some horrible, wrong things > while considering it. > http://blogs.msdn.com/ie/archive/2005/02/01/364581.aspx > http://msdn.microsoft.com/workshop/networking/moniker/overview/appendix_a.asp > > Ian Hickson says contenttype is dead: > http://ln.hixie.ch/?start=1144794177=1 > http://ln.hixie.ch/?start=1154950069=1 > hmmm.. sad to hear that.. but it hopefully does not affect the django-unicode issue too much... currently my plan is to have the following behaviour: 1. i assume that every GET/POST param comes in encoded as settings.DEFAULT_CHARSET, and will decode it accordingly. if it fails, then it fails. - might make an exception and in case of post-data check the content-type header of the request, whether it contains any charset stuff -if you really-really-really need to do some crazy is-sent-as-foo-but-has-to-be-treated-as-bar, you can always use the raw-postdata and raw-getdata. 2. will render the template in DEFAULT_CHARSET 3. will assume the database is in DEFAULT_CHARSET - maybe can we somehow ask the db for it's charset? so, what do you think? or should we make it possible to have a system with mixed charsets? (well, maybe having a different DB_CHARSET and a DEFAULT_CHARSET could work. maybe) gabor --~--~-~--~~~---~--~~ 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/9/06, gabor <[EMAIL PROTECTED]> 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... On Windows, I used UltraEdit, which is a very popular editor. $25ish with very nice features. It claims to support unicode, but I've tested with it and it horribly mangles anything but UTF-8. Worse, you can open a UTF-8 file as though it were ASCII, then save as unicode, causing double-encoding. I hearby degree that all strings in computing should have a charset associated with them. ... Damn, it didn't work. --~--~-~--~~~---~--~~ 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/16/06, Bill de hÓra <[EMAIL PROTECTED]> wrote: > Now. Most (all?) browser UAs sniff the content to second guess the media > type. They don't much pay attention to Content-Type (I think maybe IE > ignores it altogether). The problem for this example is they might be > doing something similar for character encodings declared on the form > page's GET request. Browsers do this because so much served content is > mislabelled (eg feeds served as text/html and video as text/plain). IE doesn't totally ignore it. I just does some horrible, wrong things while considering it. http://blogs.msdn.com/ie/archive/2005/02/01/364581.aspx http://msdn.microsoft.com/workshop/networking/moniker/overview/appendix_a.asp Ian Hickson says contenttype is dead: http://ln.hixie.ch/?start=1144794177=1 http://ln.hixie.ch/?start=1154950069=1 Happily, Mark Pilgrim did a lot of the hard work by converting Mozilla's charset detection routines to Python in support of his feed parser. http://chardet.feedparser.org/docs/how-it-works.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 -~--~~~~--~~--~--~---
Re: django unicode-conversion, beginning
Gábor Farkas wrote: > for example, using this html file: > > http://localhost:7000;> > > > > (+ additional xhtml-headers, http-equiv-content-type=utf-8 etc) > > firefox submits this: > > > POST / HTTP/1.1 > Host: localhost:7000 > User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1b1) > Gecko/20060601 BonEcho/2.0b1 (Ubuntu-edgy) > Accept: > text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 > Accept-Language: en-us,en;q=0.5 > Accept-Encoding: gzip,deflate > Accept-Charset: UTF-8,* > Keep-Alive: 300 > Connection: keep-alive > Cookie: sessionid=9f5f5a5c387a07dd6b7e4d34a04e38b9 > Content-Type: application/x-www-form-urlencoded > Content-Length: 14 > > gabor1=farkas1 > = > > so, in what charset is the POSTDATA? I don't have good news for you. If we are talking about HTML forms in this case - undefined. There's no charset attribute defined on the form. In that case the value is assumed to be "unknown" and clients can (not must) map this value as the character encoding that was used to send the html form. You can't assume in ISO-8859-1 for a form as that only comes to as a default for text/* types. > so, i agree with you, that if they do send it, we should honor it. but > they are not sending it (i assume they should send it in the > Content-Type header). To spec? Then client UAs /must/ treat the Content-Type header as the authoritative declaration of the character encoding if there is a charset - it overrides *everything*. HTTP 1.1 and recent W3C findings are explicit on this. Now. Most (all?) browser UAs sniff the content to second guess the media type. They don't much pay attention to Content-Type (I think maybe IE ignores it altogether). The problem for this example is they might be doing something similar for character encodings declared on the form page's GET request. Browsers do this because so much served content is mislabelled (eg feeds served as text/html and video as text/plain). So the heuristic "browsers send content back in the encoding they receive it" can be assumed in, but you have to allow for cases where they are sniffing content and ignoring server directives. But, as a server implementor, my advice is to *always* send the Content-Type header and charset, and assume the data will be returned in that encoding. In order to be as stateless as possible, that means serving all forms in the same encoding, and typically your best bet in that case is to serve as UTF-8. Serving latin1 might work also for cases where people are using keyboard shorts for things like my surname (I'd need to test this to be sure; all I can say after 10 years of shopping online is that it's been pot luck). For cut and pasted content from word, we'd need to transcode down from cp1252 to latin1. cheers Bill --~--~-~--~~~---~--~~ 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: Streaming uploads and progress info.
Error detected New patch http://code.djangoproject.com/attachment/ticket/2070/3581-streaming_uploads_and_uploadprogress_middleware_wsgi_fix.diff --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Streaming uploads and progress info.
Considering this patch done unless anyone can find fatal bugs or have some comments about it. Ticket http://code.djangoproject.com/ticket/2070 Patch http://code.djangoproject.com/attachment/ticket/2070/3581-streaming_uploads_and_uploadprogress_middleware_fixes_and_pretty_bar.diff To use streaming uploads put django.middleware.upload.StreamingUploadMiddleware in MIDDLEWARE_CLASSES To use upload progress put django.middleware.upload.UploadStateMiddleware before django.middleware.upload.StreamingUploadMiddleware and set admin js to: class Admin: js = ['js/UploadProgress.js'] Upload progress js should be compatible with mod_uploadprogress, so wsgi users just use: http://blog.lighttpd.net/articles/2006/08/01/mod_uploadprogress-is-back Not sure if django.middleware.upload.StreamingUploadMiddleware has any added efficiency or using wsgi since requests to django are delayed by lighttpd. --~--~-~--~~~---~--~~ 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
"Gary Wilson" <[EMAIL PROTECTED]> writes: > Scott Paul Robertson wrote: >> 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. > Not sure how common it is, as this is the only ldap setup I have worked > with. The directory has controlled access via issued service accounts, > in addition to user accounts. The service accounts allow applications > to access the directory without having to use a regular user's > credentials. I believe this gives the system better access control and > logging. For what it's worth, and to provide one more anecdote (the plural of anecdote is data!), my site is using an LDAP setup that is the same as this one in terms of authentication procedure (bind with service account, search your username's full DN, bind with your full DN and password). -- +---+ | Jason F. McBrayer[EMAIL PROTECTED] | | A flower falls, even though we love it; and a weed grows, | | even though we do not love it.-- Dogen| --~--~-~--~~~---~--~~ 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
Bill de hÓra wrote: > gabor wrote: > >> so what do you think about the following approach: >> >> try ascii-decoding >> if fails, try utf8-decoding >> if fails do iso-8859-1-decoding (this cannot fail). >> >> ? > > Dumb question maybe. How do you know this encoding ladder will work? it depends on how you define 'will work' :-) it will not fail (every string can be decoded as iso-8859-1). > >> but imho this should happen only in "special" cases like >> environ-variables.. for example in get/post params i would prefer to >> raise an exception when the data cannot be en/de-coded using the >> configured charset. > > You'd need to honor charset parameters sent out of Django apps and sent > back by the client. A sensible default encoding to emit is UTF-8. i would honor them if they would be sent :-) for example, using this html file: http://localhost:7000;> (+ additional xhtml-headers, http-equiv-content-type=utf-8 etc) firefox submits this: POST / HTTP/1.1 Host: localhost:7000 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1b1) Gecko/20060601 BonEcho/2.0b1 (Ubuntu-edgy) Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: UTF-8,* Keep-Alive: 300 Connection: keep-alive Cookie: sessionid=9f5f5a5c387a07dd6b7e4d34a04e38b9 Content-Type: application/x-www-form-urlencoded Content-Length: 14 gabor1=farkas1 = so, in what charset is the POSTDATA? so, i agree with you, that if they do send it, we should honor it. but they are not sending it (i assume they should send it in the Content-Type header). the only usable assumption i have found up to now is that the browsers sends the data back encoded in the submitting-html-page's charset. or is there a better way? gabor --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
ANN: Small security hole in compile-messages.py fixed
The Django team discovered and fixed a small security hole in the django/bin/compile-messages.py helper script, which is the script that compiles message files (.po files) into binary format (.mo files). The compile-messages.py script uses the name of the .po file to build arguments to a system command, and it didn't sufficiently validate the filename for potentially malicious content. Users who relied on the translation files provided with Django, or who wrote and compiled their own translations, were never at risk. Users who never ran the compile-messages.py script were never at risk. Only users who compiled third-party translations without examining the filenames first were potentially vulnerable. No exploit based on this vulnerability, proof-of-concept or otherwise, is known to have existed. Due to the nature of the vulnerability, we do not feel this merits a new release of Django. However, users who rely on third parties to supply translation files -- such as Django's own i18n maintainers -- are encouraged either to patch their code in one of these ways: * Upgrade to the latest Django trunk (the Django development version). * Simply overwrite your copy of django/bin/compile-messages.py with the new version found here: http://code.djangoproject.com/svn/django/trunk/django/bin/compile-messages.py This file has not changed in any backwards-incompatible way since before Django version 0.90, so it's safe to copy over, regardless of which Django version you're using. * We've applied the patches to Subversion "bug-fix" branches for both previous Django versions, 0.90 and 0.91. You can access those branches here: svn co http://code.djangoproject.com/svn/django/branches/0.90-bugfixes svn co http://code.djangoproject.com/svn/django/branches/0.91-bugfixes If none of those solutions is possible, we strongly encourage users to examine the names of translation files carefully before compiling them. Of course, the same standards should be applied when examining translation files from untrusted third parties as would be applied to any code received from an untrusted source. (All users are advised, as always, to keep in mind the risks of using *any* file from a third-party source, and to carefully examine any third-party code before executing it.) This security hole was fixed in changeset 3592. The patch is available here: http://code.djangoproject.com/changeset/3592 If you're interested in how we fixed the error, see the excellent document "String replacements in command lines": http://cyberelk.net/tim/articles/cmdline/ar01s02.html . Thanks to Rene Dudfield for reporting this. -The Django team (Cross-posted to django-announce, django-i18n, django-developers and django-users. We recently created the django-announce mailing list but it isn't yet well-known -- hence the wide net of mailing lists.) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
