date:20060809

Hey John,

On Wed, 2006-08-09 at 10:41 +0100, John Sutherland wrote:
> Hi all,
> 
> I don't want sound like an arse, but has anyone seen changeset 3541 [1]?
> 
> I understand it's still a branch [2], but are we going to be getting
> all that YahooUI stuff in trunk?
> 
> I don't want to get in a flame-war about the whole AJAX/JavaScript
> thing, but I'm of the impression that Django is for the server-side
> stuff, if I wanted to do cool-guy AJAX stuff I'd choose a JS framework
> and get own with writing the missing bits myself.

> [1] 
> [2] 
> 

I saw it go past, but was personally not too worried about it at the
moment for a few reasons (really personal opinion only, read nothing
more into this): It's a Summer of Code project, so there's no policy
setting or anything going on there. Presumably (hopefully!) the
per-object functionality is not dependent upon that particular admin
interface implementation, so when we evaluate the results at the end of
the project, we should be able to separate out the various pieces and we
can decide then whether or not the admin implementation is something we
want to adopt. Setting up a working implementation of "here's how the
admin interface could work for this" is not a crazy idea, though.

It's a sandbox for Chris Long's "in development" work. I'm inclined not
to worry about in progress stuff too much just yet.

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: django unicode-conversion, beginning

2006-08-09 Thread Aidas Bendoraitis


Shouldn't the UTF-8 encoding be also defined in all files as described
here: http://www.python.org/dev/peps/pep-0263/ ?

That is using

#!/usr/bin/python
# -*- coding: UTF-8 -*-

at the beginning of python code files.

This works pretty good at least when you need to create new instances
of models containing multilingual characters via python script file.


Regards,
Aidas Bendoraitis [aka Archatas]


On 8/9/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> Hey Gabor,
>
> On Wed, 2006-08-09 at 01:03 +0200, gabor wrote:
> > today i experimented a little with the django source code,
> > and here are the results.
> >
> > if you apply a very small patch (65lines, attached), you can write a view
> > completely in unicode.
> > means:
> > - GET/POST contains unicode data
> > - request.META contains unicode data
> > - you can put unicode text into the HttpResponse (this was already possible
> > without the patch)
> >
> > of course, this patch is a demonstration only. the charset is hardcoded
> > to UTF-8 (should be settings.DEFAULT_CHARSET), and it only handles the
> > WSGI way (the mod_python one is not handled). also templating and ORM
> > are not touched. (not to mention the ugliness of the code)
> >
> > but still, i was quite surprised that with such small changes so much
> > can be done.
>
> The low-hanging fruit are definitely the place to start for this sort of
> thing.
>
> >
> > i think unicodizing django can be done in 4 easily separated steps/parts:
> >
> > 1. request/response
> > 2. templating-system
> > 3. database-system
> > 4. "overall unicode-conversion". this is mostly about replacing
> > bytestrings with u"bla" in the code, and switching __str__ to __unicode__
> >
> > my biggest problem currently is, that i do not know how to continue...
> > should i just write more and more patches to increase the
> > "unicode-coverage" to more parts of django? or maybe a more coordinated
> > approach would be better?
>
> Ultimately, getting you a svn branch to work in will probably be
> easiest. Maintaining a bunch of separate patches against a rapidly
> changing tree can be fairly time consuming. I'm not sure what the
> procedure is for that. Adrian?
>
> Keeping the changes as reasonably independent as possible is a great
> idea as far as you can take it. It will make review and testing a lot
> easier, as well as keeping you saner because you will only have to be
> looking at one layer at a time.
>
> A couple of comments on the patch itself. I realise it's only a proof of
> concept at the moment, so take as more things to think about when you
> want to tidy it up:
>
> (1) A docstring like """needed to workaround the cgi.parse_sql
> unicode-problem""" is not very future-proof. *What* parse_sql unicode
> problem? How will we know if/when it goes away? Either a quick
> description of the problem or a URL if it's tricky and explained
> elsewhere will help people who need to read this code in six months
> time.
>
> (2) You can't necessarily assume the environment is always in ASCII (or
> maybe you can; see below). For example, my current locale is set to
> en_AU.UTF-8 and I can do
>
> export foo="€50,00"
>
> If I'm not careful when parsing os.environ['foo'] this comes out as
> rubbish (I need to do unicode(os.environ['foo'], 'utf-8') or similar).
>
> Probably some playing around with the locale module to work out the
> right behaviour and getting a few people to test things (e.g. Windows
> vs. Linux vs. Macs, etc) will be necessary. It's also important not to
> go too overboard here, but since arbitrary environment variables can be
> set through Apache, we need to be able to work with that to be
> "correct". Hmm ... what are the restrictions on what webservers can put
> in their config files? Maybe ASCII-only is reasonable. *shrug*
>
> Maybe more investigation needed here.
>
> (3) I know there are some software projects apparently using unicodize
> as a word, but ... *shudder*. Using "code" as an analogy, "unicodify"
> would be nicer (nobody uses "codize", I would hope).
>
> (4) As you go through this process, keep a list somewhere of what people
> need to do to port existing applications across to using this
> functionality. Ideally, the answer would be "not much" and we can cast
> from the default encoding to unicode internally where necessary. But I'm
> sure there will be some changes required, so keeping a list of things to
> watch out for as you go will help people test this for you.
>
> Good to see somebody working on this. :-)
>
> 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
-~--~~~~--~~--~--~---

ImportError: No module named future

2006-08-09 Thread David Martin


Mod_python error: "PythonHandler django.core.handlers.modpython"

Traceback (most recent call last):

  File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line
287, in HandlerDispatch
log=debug)

  File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line
457, in import_module
module = imp.load_module(mname, f, p, d)

  File "/home/django/django/core/handlers/modpython.py", line 1, in ?
from django.core.handlers.base import BaseHandler

  File "/home/django/django/core/handlers/base.py", line 2, in ?
from django.dispatch import dispatcher

  File "/home/django/django/dispatch/dispatcher.py", line 28, in ?
from __future__ import generators

ImportError: No module named __future__


I've setup Django before without major problems, but I'm setting it up
on another personal server, and for some reason this time I get this
error message.  when the httpd.conf -> PythonPath has sys.path
included, it can only be included by putting it in the single quotes as
such 'sys.path',   When I add it assys.path +   it tells me it
can't find the django module.  Any ideas?


--~--~-~--~~~---~--~~
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

2006-08-09 Thread Chris Long


Hi,

I'm the developer working on the branch.

A few things, hopefully to answer your concerns.

1) The HTML and JS is written that the AJAX can be turned off very
easily(currently it works better with JS disabled then enabled). And I
plan on implementing a method of selecting if you wish to use the AJAX
or not. I might even implement it so you have to install the YUI
toolkit seperately rather then increse Django's size (though w/ the YUI
toolkit it works out to about 50-75kb increase in size).

2) The current way I have the interface set up, I find it improves the
interface greatly to have AJAX send the request to the server and
update the page. I plan on adding some "Apply selected" and "Delete
selected" buttons in the next few days but the AJAX does help.

3) The Admin interface already uses a lot of javascript code, I'm just
the first to use a toolkit rather then bits and pieces.

Hopefully that answers some of your concerns. I'm curious as to the
communities take on it, if in general the opinion is to remove it then
I will. I personally think the admin interface would work well with
some AJAX built into it, but I know that isn't the case with everyone.
Comments? Concerns?

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: weird problem regarding crud coming into the request

just as a follow up to this, after debugging it with Malcom,we discovered we weren't copy()'ing the extra context parameter when we passed it into the request.so the previous request was modifying it and we then passed it back into the new one.On 07/08/2006, at 9:57 AM, Ian Holsman wrote:On 07/08/2006, at 9:49 AM, Malcolm Tredinnick wrote:Hey Ian,On Mon, 2006-08-07 at 09:28 +1000, Ian Holsman wrote: this problem has me stumped.. and i have no idea why this ishappening. [...] for some reason every once and a while it thinks basepath is anothercompletly different (but valid) URLeg /aggy/tag/play/which I'm guessing is someone else's request. I'm getting a headache just thinking about it. You do realise it's firstthing Monday morning, right? This isn't a good way to start theweek. :-(yeah.. tell me about it ;(What's your setup? Apache + mod_python or something else?apache + mod-pythonin this instance Apache/2.0.52 (Red Hat) mod_python/3.2.8 Python/2.4.3 Also, if I send a request for /aggy/tag/play/popular, will it get thatfar in the code? I've seen some very bizarre URLs sent to my weblog thatmake me think there are (for example) some horribly broken feed readersout there that just don't understand relative URLs *at all*. So is itpossible that somebody is just sending a completely bogus path?nope.. but /aggy/tag/play/ would. it's a valid request.and this is happening on the page it renders.. it is showing the invalid links *in* the HTML. it's like the template processor is grabbing some stuff from another request or something weird.Regards,Malcolm  --Ian Holsman[EMAIL PROTECTED]http://zyons.com/ build a Community with Django 

--~--~-~--~~~---~--~~
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

from my understanding having YUI in this section is very localized, and would not affectyour choice of AJAX library to use within your applications.On 09/08/2006, at 9:05 PM, Chris Long wrote:Hi,I'm the developer working on the branch.A few things, hopefully to answer your concerns.1) The HTML and JS is written that the AJAX can be turned off veryeasily(currently it works better with JS disabled then enabled). And Iplan on implementing a method of selecting if you wish to use the AJAXor not. I might even implement it so you have to install the YUItoolkit seperately rather then increse Django's size (though w/ the YUItoolkit it works out to about 50-75kb increase in size).2) The current way I have the interface set up, I find it improves theinterface greatly to have AJAX send the request to the server andupdate the page. I plan on adding some "Apply selected" and "Deleteselected" buttons in the next few days but the AJAX does help.3) The Admin interface already uses a lot of _javascript_ code, I'm justthe first to use a toolkit rather then bits and pieces.Hopefully that answers some of your concerns. I'm curious as to thecommunities take on it, if in general the opinion is to remove it thenI will. I personally think the admin interface would work well withsome AJAX built into it, but I know that isn't the case with everyone.Comments? Concerns?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: ImportError: No module named future

On Wed, 2006-08-09 at 04:04 -0700, David Martin wrote:
[...]
> ImportError: No module named __future__
> 
> 
> I've setup Django before without major problems, but I'm setting it up
> on another personal server, and for some reason this time I get this
> error message.  when the httpd.conf -> PythonPath has sys.path
> included, it can only be included by putting it in the single quotes as
> such 'sys.path',   When I add it assys.path +   it tells me it
> can't find the django module.  Any ideas?

This definitely suggests you don't have the standard Python paths in
your environment (__future__.py is a real file and is going to be
in /usr/lib/python2.4/ in your case -- you might want to check it really
exists, I guess, just to be sure).

Sounds like you need to work with your mod_python PythonPath line a bit
more. For quick reference, one of my setups looks like this:

PythonPath "['/home/malcolm/code'] + sys.path"

and I have /usr/lib/python2.3/site-packages/django symlinked to the
django directory in my Django source tree. You should be able to put as
many extra paths as you like in the [...] portion of that statement, so
you don't need your Django code anywhere near your Python site-packages/
directory if you don't want to.

Cheers,
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: JavaScript and Changeset 3541

2006-08-09 Thread John Sutherland


Hi all,

Thanks for your responses - concerns have been relieved.

I wasn't aware that there was no obligation to include the SoC stuff.

I think that the admin would gain a lot from having more JS/AJAX stuff
and that it would be a wise decision to pick a framework and run with
it. However as soon a a JS framework is bundled with Django it will
start to influence the rest of the project.

I'd rather have bits and pieces of JS in the admin than a framework if
only to halt influence on the developers and us ending up knee deep in
a JS framework like Rails (recognising though that Prototype was
developed as part of Rails).

Cheers, John.

PS. I am totally looking forward to the per-object permissions stuff,
so keep up the good work :D


On 8/9/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
>
> from my understanding having YUI in this section is very localized, and
> would not affect
> your choice of AJAX library to use within your applications.
>
>
>
> On 09/08/2006, at 9:05 PM, Chris Long wrote:
>
>
> Hi,
>
> I'm the developer working on the branch.
>
> A few things, hopefully to answer your concerns.
>
> 1) The HTML and JS is written that the AJAX can be turned off very
> easily(currently it works better with JS disabled then enabled). And I
> plan on implementing a method of selecting if you wish to use the AJAX
> or not. I might even implement it so you have to install the YUI
> toolkit seperately rather then increse Django's size (though w/ the YUI
> toolkit it works out to about 50-75kb increase in size).
>
> 2) The current way I have the interface set up, I find it improves the
> interface greatly to have AJAX send the request to the server and
> update the page. I plan on adding some "Apply selected" and "Delete
> selected" buttons in the next few days but the AJAX does help.
>
> 3) The Admin interface already uses a lot of javascript code, I'm just
> the first to use a toolkit rather then bits and pieces.
>
> Hopefully that answers some of your concerns. I'm curious as to the
> communities take on it, if in general the opinion is to remove it then
> I will. I personally think the admin interface would work well with
> some AJAX built into it, but I know that isn't the case with everyone.
> Comments? Concerns?
>
> Chris
>
>
>
>  >
>
>


-- 
[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

2006-08-09 Thread Adrian Holovaty


On 8/9/06, Chris Long <[EMAIL PROTECTED]> wrote:
> Hopefully that answers some of your concerns. I'm curious as to the
> communities take on it, if in general the opinion is to remove it then
> I will. I personally think the admin interface would work well with
> some AJAX built into it, but I know that isn't the case with everyone.
> Comments? Concerns?

I have not looked at this branch at all, but I'll strongly suggest
that you remove the YUI stuff.

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: django unicode-conversion, beginning

2006-08-09 Thread Ivan Sagalaev

First of all, Gabor, thank you very much for doing this!

gabor wrote:
> today i experimented a little with the django source code,
> and here are the results.
> 
> if you apply a very small patch (65lines, attached), you can write a view
> completely in unicode.
> means:
> - GET/POST contains unicode data
> - request.META contains unicode data
> - you can put unicode text into the HttpResponse (this was already possible
> without the patch)

Here's a problem that I didn't know how to solve last time this topic
was discussed.

You can put unicode in HttpResponse. Does it imply that template 
processing should be done in unicode too? I mean, should context data
be in unicode? This would be convenient later because we will get all
the data from DB in unicode also. But this poses a problem of encoding
of actual template files.

We need to know the encoding of a template file. This can be done by
just mandating that they should be in settings.DEFAULT_CHARSET or we
should create a new setting (TEMPLATE_CHARSET). The reason of having
two different settings is that enforcing default UTF-8 in templates
means enforcing people to use unicode-aware text editors that are not
that common.

--~--~-~--~~~---~--~~
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: manipulator-aware validators in post-MR

2006-08-09 Thread Tom Tobin

On 8/9/06, Tom Tobin <[EMAIL PROTECTED]> wrote:
>
> I've already gotten the first case working, and I'll tackle the second
> after work tomorrow; I'll report back with my thoughts after comparing
> the two.

I actually implemented the second case (a ``takes_manipulator``
decoration) last night as well, and I'm leaning towards it as feeling
cleaner right now.

Also, I thought I'd add that you *can* implement manipulator-aware
validators in trunk, as `pointed out by Matthew on Django-users`__;
the key problem is that they don't work in the admin, which is what my
solution aims to solve (and, furthermore, the existing method seems
convoluted and messy IMHO).

.. __: http://groups.google.com/group/django-users/msg/a76be4c94631ec80

--~--~-~--~~~---~--~~
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

2006-08-09 Thread gabor


Ivan Sagalaev wrote:
> First of all, Gabor, thank you very much for doing this!
> 

thanks :)

> gabor wrote:
>> today i experimented a little with the django source code,
>> and here are the results.
>>
>> if you apply a very small patch (65lines, attached), you can write a view
>> completely in unicode.
>> means:
>> - GET/POST contains unicode data
>> - request.META contains unicode data
>> - you can put unicode text into the HttpResponse (this was already possible
>> without the patch)
> 
> Here's a problem that I didn't know how to solve last time this topic
> was discussed.
> 
> You can put unicode in HttpResponse. Does it imply that template 
> processing should be done in unicode too? I mean, should context data
> be in unicode? 

yes

> This would be convenient later because we will get all
> the data from DB in unicode also. But this poses a problem of encoding
> of actual template files.
> 
> We need to know the encoding of a template file. This can be done by
> just mandating that they should be in settings.DEFAULT_CHARSET or we
> should create a new setting (TEMPLATE_CHARSET). The reason of having
> two different settings is that enforcing default UTF-8 in templates
> means enforcing people to use unicode-aware text editors that are not
> that common.

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...

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

2006-08-09 Thread gabor


Malcolm Tredinnick wrote:
> A couple of comments on the patch itself. I realise it's only a proof of
> concept at the moment, so take as more things to think about when you
> want to tidy it up:
> 
> (1) A docstring like """needed to workaround the cgi.parse_sql
> unicode-problem""" is not very future-proof. *What* parse_sql unicode
> problem? How will we know if/when it goes away? Either a quick
> description of the problem or a URL if it's tricky and explained
> elsewhere will help people who need to read this code in six months
> time.

ok

> 
> (2) You can't necessarily assume the environment is always in ASCII (or
> maybe you can; see below). For example, my current locale is set to
> en_AU.UTF-8 and I can do
> 
> export foo="€50,00"
> 
> If I'm not careful when parsing os.environ['foo'] this comes out as
> rubbish (I need to do unicode(os.environ['foo'], 'utf-8') or similar).
> 
> Probably some playing around with the locale module to work out the
> right behaviour and getting a few people to test things (e.g. Windows
> vs. Linux vs. Macs, etc) will be necessary. It's also important not to
> go too overboard here, but since arbitrary environment variables can be
> set through Apache, we need to be able to work with that to be
> "correct". Hmm ... what are the restrictions on what webservers can put
> in their config files? Maybe ASCII-only is reasonable. *shrug*
> 

phew... the immortal 
how-tolerant-we-should-be-when-doing-unicode-conversion problems :-)

i generally prefer to do as little guesswork as possible, but in the 
case of the environ-variables it seems we cannot avoid it.. after all, 
it cannot crash when parsing the environ variables, because there's no 
way from the programmer's side to affect them.

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).

?


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.

> Maybe more investigation needed here.
> 
> (3) I know there are some software projects apparently using unicodize
> as a word, but ... *shudder*. Using "code" as an analogy, "unicodify"
> would be nicer (nobody uses "codize", I would hope).
> 

ok

> (4) As you go through this process, keep a list somewhere of what people
> need to do to port existing applications across to using this
> functionality. Ideally, the answer would be "not much" and we can cast
> from the default encoding to unicode internally where necessary. But I'm
> sure there will be some changes required, so keeping a list of things to
> watch out for as you go will help people test this for you.
> 

will try.

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 and LDAP support

2006-08-09 Thread Scott Paul Robertson

On Tue, Aug 01, 2006 at 12:08:25PM -0700, Scott Paul Robertson wrote:
> I'm actually doing LDAP auth with something I wrote myself, which I feel
> is a little more general than the mentioned code (not that I'm
> opinionated or anything). I'll be posting it in a day or so once it's
> cleaned up a bit more. During OSCON I mentioned to Adrian that I'd be
> willing to work on one that would make it into django.
> 

I've finished the code for a backend that works with LDAP. It pulls all
the needed variables from your settings.py file, and covers everything
that I could think of. I don't have an ssl based ldap server to test
with, but I think if you want ssl you only have to have the uri be
ldaps:// instead of ldap://.

I've submitted it as a patch to trac:
http://code.djangoproject.com/ticket/2507/

Scathing comments are encouraged.

-- 
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: django unicode-conversion, beginning

On Wed, 2006-08-09 at 21:51 +0200, gabor wrote:
[...]
> phew... the immortal 
> how-tolerant-we-should-be-when-doing-unicode-conversion problems :-)

Agreed. This is much easier on my side of the fence (lobbing problems),
than your side (solving them).

> i generally prefer to do as little guesswork as possible, but in the 
> case of the environ-variables it seems we cannot avoid it.. after all, 
> it cannot crash when parsing the environ variables, because there's no 
> way from the programmer's side to affect them.
> 
> 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).

I was thinking you could use the locale module to help you somewhat:
locale.getdefaultlocale() and locale.getpreferredencoding() might both
be useful, although experimentation is needed. For example, on my
(Linux) system, getdefaultlocale() returns ('en_AU', 'utf') and I'm
pretty sure 'utf' isn't an encoding (utf-8 is, utf-16 also, but not
plain old utf.. :-( ).

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.

All that being said, you could start off implementing your list and go
from there (although surely utf-8 decoding will also handle ASCII
strings, so you could skip the first step).

> 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.

*Providing* what we send in the headers is that restrictive. A server
can send what character set encodings it will accept in the header. The
client can pick any one of those to send back. So keep that on your list
of things to check (this is HTTP-level stuff).

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
-~--~~~~--~~--~--~---

If there was massive security hole found in Django, are there plans in place to deal with it?


I'm really feeling for our Rails Core friends... they're getting
blasted right now for not having a complete policy for releasing and
communicating urgent security flaws. I'm not poking fun, this is pretty
serious stuff.

Read here for some of the comments they're getting today via
Reddit.com:
"Mandatory security patch issued for Rails, but the vulnerability is
not disclosed. "
http://programming.reddit.com/info/cvlr/comments

Rather than poke fun or make light of the today's situation with Rails,
I'd rather like to turn the focus on the Django project and play the
"But what if it happened to you?" game.

I heard way-back-when that Django was security-audited, and found to be
secure, but that was (I think) before Django was open-sourced, and I
don't remember seeing many details.. However, doing a quick search for
"security" of the Dev list shows this message from Jacob:
http://groups.google.com/group/django-developers/msg/682543e6c084ff75

Should someone commission a new audit given the amount of code changes
in Django since last year? (It would be a great opportunity for some
company  to
sponsor.

A few questions:
1) If there was critical security flaw found in Django (any version)
today, are there plans in place on how to deal with it? If so, are
those plans posted anywhere? If not, let's roll up our sleaves and do
it! :-)

2) Is there a Django mailing list for security alerts? If not, let's
create one!

3) What are some projects to emulate in terms of "They do security
right"? I've heard Debian has good policies and execution on those
plans. Any others?

Having an emergency plan ready to go the moment a security issue crops
up is one of those things that will really ease the mind of an
"enterprise" flirting with the idea of going Django. It's also an area
where Django can really shine compared to other web frameworks (Python
or otherwise).

-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?

I'm on the Apache security list, and I'll offer my 2c's on how they do it.1) A security@ email alias which is private and is a alias for the core developers. be prepared for a *LOT* of spam, and a lot of questionswhich should have been asked on dev@ or [EMAIL PROTECTED] security providers like to send stuff with GPG encryption. make sure that you have a GPG key with good trust pathsso that they can send encrypted information to you.2) Acknowledge each email on it, the security 'researchers' like prompt feedback, and will post on full-disclosure if theydon't feel like they are getting a fast enough response.3) a vendors-announce@ mailing list which goes to the major vendors who use django. people like redhat, debian, and possiblysome of the large ISPs who provide django hosting. They usually get notified that there is an issue (not what it is) and the expected announce dateso they can have some resources to deal with it when it comes out. you should also notify agencies like CERT and get a CVE id for the issue.4) a regular announce@ mailing list for the rest of us mortals.apache also has a private SVN repo for keeping track of issues, but I'm not sure if that is warranted here.. django is much smaller5) when a security release happens, the release notes acknowledge the security research firm that found it. This will encourage them to tell you about itfirst.oh.. and security usually comes in waves.. now that a vulnerability has been found in Rails, I expect it will attract several other research firms to look at rails (and django) very carefully.On 10/08/2006, at 11:41 AM, Jason Huggins wrote:I'm really feeling for our Rails Core friends... they're gettingblasted right now for not having a complete policy for releasing andcommunicating urgent security flaws. I'm not poking fun, this is prettyserious stuff.Read here for some of the comments they're getting today viaReddit.com:"Mandatory security patch issued for Rails, but the vulnerability isnot disclosed. "http://programming.reddit.com/info/cvlr/commentsRather than poke fun or make light of the today's situation with Rails,I'd rather like to turn the focus on the Django project and play the"But what if it happened to you?" game.I heard way-back-when that Django was security-audited, and found to besecure, but that was (I think) before Django was open-sourced, and Idon't remember seeing many details.. However, doing a quick search for"security" of the Dev list shows this message from Jacob:http://groups.google.com/group/django-developers/msg/682543e6c084ff75Should someone commission a new audit given the amount of code changesin Django since last year? (It would be a great opportunity for somecompany tosponsor.A few questions:1) If there was critical security flaw found in Django (any version)today, are there plans in place on how to deal with it? If so, arethose plans posted anywhere? If not, let's roll up our sleaves and doit! :-)2) Is there a Django mailing list for security alerts? If not, let'screate one!3) What are some projects to emulate in terms of "They do securityright"? I've heard Debian has good policies and execution on thoseplans. Any others?Having an emergency plan ready to go the moment a security issue cropsup is one of those things that will really ease the mind of an"enterprise" flirting with the idea of going Django. It's also an areawhere Django can really shine compared to other web frameworks (Pythonor otherwise).-Jason --Ian Holsman[EMAIL PROTECTED]http://peopleintopoker.com/ -- where the poker people go
--~--~-~--~~~---~--~~
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 Wed, 2006-08-09 at 18:41 -0700, Jason Huggins wrote:
[...]
> A few questions:
> 1) If there was critical security flaw found in Django (any version)
> today, are there plans in place on how to deal with it? If so, are
> those plans posted anywhere? If not, let's roll up our sleaves and do
> it! :-)
> 
> 2) Is there a Django mailing list for security alerts? If not, let's
> create one!

See
http://www.djangoproject.com/documentation/contributing/#reporting-security-issues

If somebody did find a security problem, I would hope they would have
the presence of mind to look in the "how to contribute" document if they
could find no other way to contact people. Also note that the email
address there is the "obvious" one in some sense for reporting security
problems.

Finally, a little while ago somebody did report what they thought was a
security hole via Trac (an unfortunate choice, but that's the way it
goes) and it was looked at immediately.

> 3) What are some projects to emulate in terms of "They do security
> right"? I've heard Debian has good policies and execution on those
> plans. Any others?

Which policies in particular are you thinking about?

To provide some background about how distros work: Each professional
distribution (Debian, Suse, Mandrake, Red Hat, Ubuntu, Slackware,
*BSD, ...) has a security team that has representatives on the contacts
list specifically for notifying vendors of security problems in advance
of a release. It's why when you read about, e.g., an Apache release, you
also see most major distributions putting out update packages on the
same day. It isn't magic -- it's coordination and it's a very
professional group of people to work with.

> Having an emergency plan ready to go the moment a security issue crops
> up is one of those things that will really ease the mind of an
> "enterprise" flirting with the idea of going Django. It's also an area
> where Django can really shine compared to other web frameworks (Python
> or otherwise).

Revolutionary ideas aren't really needed here, since the current
system(s) work fairly well and using proven practices in cases like this
is absolutely the right thing to do. The thing that seems to have bitten
Ruby on Rails (and is applicable to us as well) is that they have a
broad installation base via grass-roots support, rather than via
distributions. Python, for example, has had security flaws in the past
(usually due to third-party libraries) and they have handled the release
and disclosure process very well.

I'm not completely sure I agree with the way the Ruby team are handling
this release, but since I don't know the details yet, I can't really
work out what is happening; they may have very good justification for
the way they are doing it, or they may just be slightly shell-shocked.
It just didn't cross my radar on any of the security-related lists I'm
on that normally cover these types of security announcements. They are
the places that this "enterprise" group watch for results. Presumably
there was a post to the Ruby-users mailing list, wherever that is and
that is the other place people are going to be watching: if you're using
something that is essentially pre-release for mission-critical work, you
are implicitly taking on the responsibility of watching carefully for
things like this.

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: JavaScript and Changeset 3541

2006-08-09 Thread Linicks


> Hopefully that answers some of your concerns. I'm curious as to the
> communities take on it, if in general the opinion is to remove it then
> I will. I personally think the admin interface would work well with
> some AJAX built into it, but I know that isn't the case with everyone.
> Comments? Concerns?
>
> Chris

AJAX integration is a nice touch, but I think that the use of YUI goes
against the established use of Dojo with Django.  After reading the
proceeding threads in this post, a couple of questions come to mind:

  1.  Chris, would it be reasonable to move your work to Dojo?

  2.  Project leaders,  if Chris were to move his Ajax work to Dojo,
would it be well received?


--Nick


--~--~-~--~~~---~--~~
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


On Wed, 2006-08-09 at 19:25 -0700, Linicks wrote:
[...]
> AJAX integration is a nice touch, but I think that the use of YUI goes
> against the established use of Dojo with Django. 

Where are we using Dojo at the moment?

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
-~--~~~~--~~--~--~---

Proposed solution to deleting contents of FileField

2006-08-09 Thread Bryan Chow


Hi All,

Ian Clelland and I have been working on a way to address the problem
that Django FileFields and ImageFields can't be cleared once they've
been set. We've posted a proposed solution here [1].

Our solution differs from the one proposed in Ticket #22 [2] in that
it's somewhat simpler, isn't restricted to admin, works within the
existing FormWrapper framework, and is compatible with post-MR code.
It currently subclasses FileField and works as a drop-in replacement,
but we hope that eventually the core FileField code could be changed
to include this functionality.

Ultimately, we'd like to submit this as a patch to Django's FileField,
but would like to get some feedback from the community before we move
further. Comments please :)

Bryan


[1] http://www.verdjn.com/wiki/FileField
[2] http://code.djangoproject.com/ticket/22

--~--~-~--~~~---~--~~
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

2006-08-09 Thread Eugene Lazutkin


Linicks wrote:
> 
> AJAX integration is a nice touch, but I think that the use of YUI goes
> against the established use of Dojo with Django.  After reading the
> proceeding threads in this post, a couple of questions come to mind:
> 
>   1.  Chris, would it be reasonable to move your work to Dojo?
> 
>   2.  Project leaders,  if Chris were to move his Ajax work to Dojo,
> would it be well received?

I am not sure if it is reasonable to use Ajax for "per object 
permissions". But if the decision is made, I can help to move it to 
Dojo. In any case putting any 3rd-party JS library code in Django's 
repository doesn't feel right for me --- we are not going to maintain it 
anyway.

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
-~--~~~~--~~--~--~---

Re: django and LDAP support

2006-08-09 Thread Gary Wilson

Scott Paul Robertson wrote:
> On Tue, Aug 01, 2006 at 12:08:25PM -0700, Scott Paul Robertson wrote:
> > I'm actually doing LDAP auth with something I wrote myself, which I feel
> > is a little more general than the mentioned code (not that I'm
> > opinionated or anything). I'll be posting it in a day or so once it's
> > cleaned up a bit more. During OSCON I mentioned to Adrian that I'd be
> > willing to work on one that would make it into django.
> >
>
> I've finished the code for a backend that works with LDAP. It pulls all
> the needed variables from your settings.py file, and covers everything
> that I could think of. I don't have an ssl based ldap server to test
> with, but I think if you want ssl you only have to have the uri be
> ldaps:// instead of ldap://.

I believe ssl with RedHat EL works out of the box since in sets
TLS_CACERTDIR /etc/openldap/cacerts
in /etc/openldap/ldap.conf.  My gentoo box needed the ca-certificates
package and I set this up in my python code using
ldap.set_option(ldap.OPT_X_TLS_CACERTDIR, '/usr/share/ca-certificates')
but I think you could alternatively set TLS_CACERTDIR in
/etc/openldap/ldap.conf.

> Scathing comments are encouraged.

line 68 of patch:
if not username and password is not Null: # we need a user/pass
Should be None  

And how about moving the ldap.initialize() call after the above check
so that we don't make an unneeded connection to the ldap server.

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.

Gary Wilson

--~--~-~--~~~---~--~~
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


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.

-- 
"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
-~--~~~~--~~--~--~---

Re: JavaScript and Changeset 3541


On 8/9/06, Chris Long <[EMAIL PROTECTED]> wrote:
> Hopefully that answers some of your concerns. I'm curious as to the
> communities take on it, if in general the opinion is to remove it then
> I will. I personally think the admin interface would work well with
> some AJAX built into it, but I know that isn't the case with everyone.
> Comments? Concerns?

I like the idea of adding AJAX-powered enhancements to the admin
application, but I really think that's something to deal with
separately; perhaps one of these days we should get an "admin-ajax"
branch going, and attack the problem that way.
-- 
"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
-~--~~~~--~~--~--~---

Re: Proposed solution to deleting contents of FileField

On 8/9/06, Bryan Chow <[EMAIL PROTECTED]> wrote:
> Ian Clelland and I have been working on a way to address the problem
> that Django FileFields and ImageFields can't be cleared once they've
> been set. We've posted a proposed solution here [1].

This is certainly a long-standing wart in Django, and on first glance
I like this solution a little better than the patch on #22, but we
also have a Summer of Code student working on major enhancements to
the admin's media support[1]; since there are only a couple weeks left
to go in SoC, I'd advise holding off on comitting any solution until
we see his final results.

[1]http://code.google.com/soc/django/appinfo.html?csaid=D7C2A8570706A6F6

-- 
"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
-~--~~~~--~~--~--~---

Re: JavaScript and Changeset 3541

On 10/08/2006, at 12:45 AM, Adrian Holovaty wrote:On 8/9/06, Chris Long <[EMAIL PROTECTED]> wrote: Hopefully that answers some of your concerns. I'm curious as to thecommunities take on it, if in general the opinion is to remove it thenI will. I personally think the admin interface would work well withsome AJAX built into it, but I know that isn't the case with everyone.Comments? Concerns? I have not looked at this branch at all, but I'll strongly suggestthat you remove the YUI stuff.Adrian,are you referring to the base YUI library, or to the django code Chris wrote which uses it?Adrian-- Adrian Holovatyholovaty.com | djangoproject.com  --Ian Holsman[EMAIL PROTECTED]http://med-chatter.com/ it's about the medicine 
--~--~-~--~~~---~--~~
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

2006-08-09 Thread Linicks


Malcolm Tredinnick wrote:
> On Wed, 2006-08-09 at 19:25 -0700, Linicks wrote:
> [...]
> > AJAX integration is a nice touch, but I think that the use of YUI goes
> > against the established use of Dojo with Django.
>
> Where are we using Dojo at the moment?
>
> Malcolm

Malcolm,
  I'm not sure how much it's being used in the current trunk,  however
it has been discussed many times.  Here are a few links that may
interest you.

  -  http://blog.dojotoolkit.org/2006/02/01/dojo-django

  -  http://lazutkin.com/blog/2006/jan/28/django-dojo/

  -  http://article.gmane.org/gmane.comp.web.dojo.user/3603

  -
http://spoken.phrasewise.com/articles/2006/02/01/django-adopts-dojo-as-ajax-framework

  -  http://groups.google.com/groups/search?q=django+dojo+integration&;


--Nick


--~--~-~--~~~---~--~~
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?

2006-08-09 Thread Jeremy Dunck

On 8/9/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> I'm not completely sure I agree with the way the Ruby team are handling
> this release, but since I don't know the details yet, I can't really
> work out what is happening; they may have very good justification for
> the way they are doing it, or they may just be slightly shell-shocked.

Dave Thomas, who is heavily involved with Ruby yet not Rails-core, and
who I think has very good judgement, thinks the issue is severe enough
that they're doing the right thing to let people hear and upgrade
before full disclosure.

> something that is essentially pre-release for mission-critical work, you
> are implicitly taking on the responsibility of watching carefully for
> things like this.

True, but Rails had lots of buzz and has -lots- of prod systems.  Of
the 2 people I talked to with prod rails systems, neither had heard of
this 3 hours after the posting.  I only knew because of luck on
prog.reddit.

Security is freaking hard.

--~--~-~--~~~---~--~~
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

2006-08-09 Thread Scott Paul Robertson

On Wed, Aug 09, 2006 at 08:00:31PM -0700, Gary Wilson wrote:
> > Scathing comments are encouraged.
> 
> line 68 of patch:
> if not username and password is not Null: # we need a user/pass
> Should be None  

d'oh! Figures I'd mistype something like that.

> And how about moving the ldap.initialize() call after the above check
> so that we don't make an unneeded connection to the ldap server.

You know it was on my list, and I missed it when I was going through my
cleanup today. Thanks.

> 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.

Thanks for the comments,
Scott

-- 
Scott Paul Robertson
http://spr.mahonri5.net
GnuPG FingerPrint: 09ab 64b5 edc0 903e 93ce edb9 3bcc f8fb dc5d 7601


pgpTklkBRjQxO.pgp
Description: PGP signature

Re: If there was massive security hole found in Django, are there plans in place to deal with it?

Malcolm Tredinnick wrote:
> See
> http://www.djangoproject.com/documentation/contributing/#reporting-security-issues

Sorry I didn't read that first before posting here. Though I did a Trac
search for "security" and that page didn't come up in the first few
search results...

Though, looking at the guidelines, I wonder how the Django devs would
know who to contact in one-on-one private emails about the
vulnerability and the fix.

> Which policies in particular are you thinking about?

I guess I'm focused on three things:
1) How do Django devs handle security issues when notified? This looks
well covered in the existing reporting-security-issues doc.
2) How should the affected users be notified? Having read the above
doc, I think this could use some more detail.
3) Is there any sort of policy or promise on how many versions back
Django devs are willing to go back and support?

The implicit assumption of using pre 1.0 code (especially open source)
is that there are no promises... But there might need to be something
more explicit like ("we'll make our best effort to support the creation
of any critical security patches for version 'X' for at least Y number
of years after initial release). In the Rails case, they first said
"upgrade to the latest version to get the patch", which made many
people unhappy. Then they back-peddaled and said they'd work on patches
for the older versions, too. Might be better to state up-front how long
Django devs expect to support various versions so people can weigh the
risks of staying on an old release later on. This is a good thing to
decide on when 1.0 ships. By comparison, the Ubuntu project is very
upfront in how they promise to support each release.

- 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/9/06, Jason Huggins <[EMAIL PROTECTED]> wrote:
> 2) How should the affected users be notified? Having read the above
> doc, I think this could use some more detail.

One would hope that anyone who's using Django is subscribed to
django-users and/or watches the Django blog (or that a company which
uses Django has a designated person doing that), because those would
be the obvious channels for notifying users that a security-related
patch/release had been issued.

> 3) Is there any sort of policy or promise on how many versions back
> Django devs are willing to go back and support?

The documentation page Malcolm linked states that patches will be
developed for the current release and the two releases previous to it.
That seems like a fairly sane policy, is roughly in line with what
some of the more popular Linux distros do.

-- 
"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
-~--~~~~--~~--~--~---

Re: If there was massive security hole found in Django, are there plans in place to deal with it?

Jeremy Dunck wrote:
> True, but Rails had lots of buzz and has -lots- of prod systems.  Of
> the 2 people I talked to with prod rails systems, neither had heard of
> this 3 hours after the posting.  I only knew because of luck on
> prog.reddit.

Same here, programming.reddit.com is my most hit site these days...

But all the more reason for letting Django users know *before-hand*
where they should look for stuff like this (which list they should be
subscribed to or RSS feed to check). As Django user/dev, I would *not*
want to *first* hear about something like this on reddit. :-)

Maybe there should be some guideline like.. "If you're going to deploy
Django on a server accessible by the general public, subscribe to our
security RSS feed or mailing list to be notified as needed". Even then,
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?

-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: django and LDAP support

2006-08-09 Thread Gary Wilson


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.

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.

Gary Wilson


--~--~-~--~~~---~--~~
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:
> > 3) Is there any sort of policy or promise on how many versions back
> > Django devs are willing to go back and support?
>
> The documentation page Malcolm linked states that patches will be
> developed for the current release and the two releases previous to it.
> That seems like a fairly sane policy, is roughly in line with what
> some of the more popular Linux distros do.

Ugh. May bad... I must have missed that. Right there it says, "[For
security issues, we'll] Halt all other development as long as is needed
to develop a fix, including patches against the current and two
previous releases."

Thanks for answering my questions, everyone. I'll try to read the docs
more closely next time... :-)

- 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/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.

And as much as some people I've talked to have been wailing and
gnashing teeth about Rails being into Mac OS X 10.5 while Django
isn't, well, I don't envy somebody who gets shipped as part of a major
operating system when it comes time to issue security updates :)

-- 
"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
-~--~~~~--~~--~--~---

Re: If there was massive security hole found in Django, are there plans in place to deal with it?