Re: mod_python, apache and django

[Graham Dumpleton]

On Aug 28, 5:21 am, Jesse  wrote:
> I'm loading django onto Windows XP professional with Apache.
> Unfortunately, I need mod_python which only works with python 2.3.
> Django needs python 2.4 and above.  Is there a way around this?

The mod_python download page at www.modpython.org links to binaries
for Windows for Python 2.3, 2.4 and 2.5. So not sure why you think it
only works with Python 2.3.

As mentioned by others, you may want to consider alternatives to
mod_python however.

Graham

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: What replaced mod_python

[Graham Dumpleton]

On Aug 28, 9:56 am, Reinout van Rees  wrote:
> On 08/28/2010 01:35 AM, Jesse wrote:
>
> > I'm trying to load django/python 27/apache onto Windows XP.  I'm
> > following the instructions that recommends mod_python.  Mod_python is
> > no longer available.  What is it's replacement?  Will apache work
> > without it?
>
> mod_wsgi.

For which there is a precompiled Windows binary available from the
mod_wsgi site at www.modwsgi.org for Python 2.6 and 2.7.

Graham

> (wsgi = web service gateway interface, normally pronounced "wiskey"...)
>
> (I'm having to install django on windows for the first time these weeks.
> Asked a question about it.  mod_wsgi + apache will work, but I got the
> tip of running it under IIS instead: there's a wsgi module for IIS, too.
>   I still have to follow up on that tip: that'll be on monday.).
>
> Reinout
>
> --
> Reinout van Rees - rein...@vanrees.org -http://reinout.vanrees.org
> Collega's gezocht!
> Django/python vacature in Utrecht:http://tinyurl.com/35v34f9

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

How to store and retrieve objects to/from session?

[Andy]

I know I can store simple key/value pairs to session. Is it possible
to store entire objects to session?

I want to enable un-logged-in users to submit form data. After the
form is submitted, I want to store the form data in session and then
redirect the user to sign-in. After they sign in, I'd retrieve the
stored form data from session and save it to database.

For example:

if request.method == 'POST':
form_object = CommentForm(request.POST)

Now if the user is not signed in, I want to save form_object to
session, and later retrieve it from session after the user has signed
in.

Is there a way to save entire objects to session?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: How to store and retrieve objects to/from session?

[Jonas Obrist]

Have you tried to just dump the object into the session?

On Aug 28, 2010 12:41 PM, "Andy"  wrote:
> I know I can store simple key/value pairs to session. Is it possible
> to store entire objects to session?
>
> I want to enable un-logged-in users to submit form data. After the
> form is submitted, I want to store the form data in session and then
> redirect the user to sign-in. After they sign in, I'd retrieve the
> stored form data from session and save it to database.
>
> For example:
>
> if request.method == 'POST':
> form_object = CommentForm(request.POST)
>
> Now if the user is not signed in, I want to save form_object to
> session, and later retrieve it from session after the user has signed
> in.
>
> Is there a way to save entire objects to session?
>
> --
> You received this message because you are subscribed to the Google Groups
"Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
.
> For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

reverse() and include('app, namespace='app)

[Almad]

Hi,

I have encountered strange behavior with urls.py: namespacing
application breaks all reverse()s inside it.

Detailed description is here:
http://stackoverflow.com/questions/3578922/how-to-do-reverse-url-search-in-django-namespaced-reusable-application

Have I missed something, is it a feature or shall it be reported as a
bug?

Thanks,

Almad

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: mod_wsgi setup issue

[Robbington]

I use a Cherokee, Uwsgi setup. It really takes the hassle out of it as
the Cherokee admin interface just has a wizard that you point to the
uwsgi.xml file.

On Aug 28, 7:53 am, Graham Dumpleton 
wrote:
> On Aug 28, 2:48 pm, Joel Klabo  wrote:
>
> > All the files are shown here:http://gist.github.com/554724
>
> > I don't know what I'm doing wrong but I'm still getting 500
>
> Go look in the Apache error log for the reason for the error and post
> that here.
>
> Better still, go watch the mod_wsgi presentation linked from the wiki
> tab on the mod_wsgi site as it goes through the errors you would get
> for a 500 error and tells you what to do.
>
> Most likely as pointed out by others, it is because sys.path is not
> set correctly, but there can be other reasons as well.
>
> Graham

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

set_language redirect view with Internet Explorer

[Stephan]

On a page I give the user the option to choose different languages.
For this I use the set_language redirect view. This works fine with
the Mozilla Firefox Browser. Only with the Internet Explorer it does
not work. There are no changes in the language. What can I do to make
it even works in Internet Explorer?

Greetings
Stephan

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Мобильная версия

[Vanger - irk]

Спасибо за перевод моего вопроса, но тут дело в том, что я уже видел
эту страницу, и список там далеко не полный, и тем более, список этот
постоянно пополняется, с выходом новых ОС для мобильников.
Как реализовать универсальный проверку? Создать свой словарь из кусков
возможных User Agent'ов без использования цифр версий ОС и тд и
проверять его вхождение в полученный User Agent зашедшего на сайт
пользователя?

On 27 авг, 21:01, Рогалевич (Ковалевич)  wrote:
> Question was: how to determine that user comes from mobile phone to show him
> mobile version of site. May be by parsing user agent. (for 
> examplehttp://en.wikipedia.org/wiki/List_of_user_agents_for_mobile_phones)
>
> 2010/8/27 Lachlan Musicman 
>
> > That come out wrong on re reading. I didn't mean to offend if I did, apols.
>
> --
> Best Regards,
> Mila

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

potential issue re in memory django file uploading.

[david b.]

Ok so I was looking through the code and I saw this (in
django/core/files/uploadhandler.py) :


FileUploadHandler
...

   def new_file(self, field_name, file_name, content_type,
content_length, charset=None):
   """
   Signal that a new file has been started.

   Warning: As with any data from the client, you should not trust
   content_length (and sometimes won't even get it).
   """

So the content_length we control right? - Maybe I missed something but
... I can say I want to upload a small file then upload a file that
triggers an oom condition / use a lot of memory no ? ...

And then this.

class MemoryFileUploadHandler(FileUploadHandler):
   """
   File upload handler to stream uploads into memory (used for small
files).
   """

   def handle_raw_input(self, input_data, META, content_length,
boundary, encoding=None):
   """
   Use the content_length to signal whether or not this handler
should be in use.
   """
   # Check the content-length header to see if we should
   # If the post is too large, we cannot use the Memory handler.
   if content_length > settings.FILE_UPLOAD_MAX_MEMORY_SIZE:
   self.activated = False
   else:
   self.activated = True

   def new_file(self, *args, **kwargs):
   super(MemoryFileUploadHandler, self).new_file(*args, **kwargs)
   if self.activated:
   self.file = StringIO()
   raise StopFutureHandlers()

   def receive_data_chunk(self, raw_data, start):
   """
   Add the data to the StringIO file.
   """
   if self.activated:
   self.file.write(raw_data)
   else:
   return raw_data

   def file_complete(self, file_size):
   """
   Return a file object if we're activated.
   """
   if not self.activated:
   return

   self.file.seek(0)
   return InMemoryUploadedFile(
   file = self.file,
   field_name = self.field_name,
   name = self.file_name,
   content_type = self.content_type,
   size = file_size,

There is a regression test for this  BUT --> in the test suite there
is # A small file (under the 5M quota)
which is governed by
(django/tests/regressiontests/file_uploads/uploadhandler.py)


def receive_data_chunk(self, raw_data, start):
   self.total_upload += len(raw_data)
   if self.total_upload >= self.QUOTA:
  raise StopUpload(connection_reset=True)
   return raw_data

So obviously my proposed attack is to simply say "content length is
tiny" and "this file is actually HUGE".
I hope I missed something :) I don't really want this to occur ...

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: App for Registration/Authorization which is Email & Password based (not username)

[Alexandre González]

Try to start with this tutorial:
http://docs.b-list.org/django-registration/0.8/quickstart.html

You can find
the templates (my biggest problem when I did it :p):
http://github.com/yourcelf/django-registration-defaults/tree/master/registration_defaults/templates/registration/

Good
luck! And ask here what you want!

On Fri, Aug 27, 2010 at 22:29, nobosh  wrote:

> Thanks Alexandre, I also found this one:
> http://github.com/redvasily/django-emailauth
>
> Given I'm a newbie, which path do you recommend I pursue?
>
> On Aug 27, 11:33 am, Alexandre González  wrote:
> > I've using django-registration to do that...
> >
> > class RegistrationFormTOSAndUniqueEmail(RegistrationFormTermsOfService,
> > RegistrationFormUniqueEmail):
> > def __init__(self, *args, **kwargs):
> > super(RegistrationFormTOSAndUniqueEmail, self).__init__(*args,
> **kwargs)
> >
> > def clean_email(self):
> > self.cleaned_data['username'] = md5(self.cleaned_data['email'] +
> > str(time.time())).hexdigest()
> > return super(RegistrationFormTOSAndUniqueEmail,
> self).clean_email()
> >
> > It's little "complicated" because I like to reg with mail and I like to
> show
> > the Terms Of Service.
> >
> > At clean_email I'm creating a hash to save as unique in the username
> field.
> >
> > I can help you more if you like, but I did this lot of time ago... it's
> > complicated :p But django-registration is very good documented
> >
> >
> >
> >
> >
> > On Fri, Aug 27, 2010 at 18:59, Eric Chamberlain  wrote:
> >
> > > On Aug 26, 2010, at 9:31 PM, nobosh wrote:
> >
> > > > Hello, I'm on day 7 learning Django and would appreciate any info
> > > > around getting my Django app started with a
> Registration/Authorization
> > > > which is Email & Password based (not username). I'll don't currently
> > > > have a need for usernames. Is there an app or a clean/smart way to
> > > > implement. I'm trying to avoid bad habits as this is my first step
> > > > after reading the book.
> >
> > > We've done a few apps that use email for auth.  In some cases, we
> generate
> > > a random 30-character username, the odds of a collision are very low
> and we
> > > don't run into issues trying to truncate an email address so it will
> conform
> > > to the username field character and length requirements.  In other
> cases,
> > > where we need a deterministic username, we base64 encode a UUID for the
> > > username.
> >
> > > We try to not tie the username to a derivative of the email address, so
> we
> > > can avoid username collisions if the user changes their email address.
> >
> > > Don't forget to add an index to the email field.
> >
> > > --
> > > Eric Chamberlain, Founder
> > > RF.com -http://RF.com/
> >
> > > --
> > > You received this message because you are subscribed to the Google
> Groups
> > > "Django users" group.
> > > To post to this group, send email to django-us...@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > > django-users+unsubscr...@googlegroups.com
> 
> > > .
> > > For more options, visit this group at
> > >http://groups.google.com/group/django-users?hl=en.
> >
> > --
> > Please, don't send me files with extensions: .doc, .docx, .xls, .xlsx,
> .ppt
> > and/or .pptx
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>


-- 
Please, don't send me files with extensions: .doc, .docx, .xls, .xlsx, .ppt
and/or .pptx

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: potential issue re in memory django file uploading.

[Graham Dumpleton]

On Aug 28, 7:58 pm, "david b."  wrote:
> Ok so I was looking through the code and I saw this (in
> django/core/files/uploadhandler.py) :
>
> FileUploadHandler
> ...
>
>    def new_file(self, field_name, file_name, content_type,
> content_length, charset=None):
>        """
>        Signal that a new file has been started.
>
>        Warning: As with any data from the client, you should not trust
>        content_length (and sometimes won't even get it).
>        """
>
> So the content_length we control right? - Maybe I missed something but
> ... I can say I want to upload a small file then upload a file that
> triggers an oom condition / use a lot of memory no ? ...
>
> And then this.
>
> class MemoryFileUploadHandler(FileUploadHandler):
>    """
>    File upload handler to stream uploads into memory (used for small
> files).
>    """
>
>    def handle_raw_input(self, input_data, META, content_length,
> boundary, encoding=None):
>        """
>        Use the content_length to signal whether or not this handler
> should be in use.
>        """
>        # Check the content-length header to see if we should
>        # If the post is too large, we cannot use the Memory handler.
>        if content_length > settings.FILE_UPLOAD_MAX_MEMORY_SIZE:
>            self.activated = False
>        else:
>            self.activated = True
>
>    def new_file(self, *args, **kwargs):
>        super(MemoryFileUploadHandler, self).new_file(*args, **kwargs)
>        if self.activated:
>            self.file = StringIO()
>            raise StopFutureHandlers()
>
>    def receive_data_chunk(self, raw_data, start):
>        """
>        Add the data to the StringIO file.
>        """
>        if self.activated:
>            self.file.write(raw_data)
>        else:
>            return raw_data
>
>    def file_complete(self, file_size):
>        """
>        Return a file object if we're activated.
>        """
>        if not self.activated:
>            return
>
>        self.file.seek(0)
>        return InMemoryUploadedFile(
>            file = self.file,
>            field_name = self.field_name,
>            name = self.file_name,
>            content_type = self.content_type,
>            size = file_size,
>
> There is a regression test for this  BUT --> in the test suite there
> is # A small file (under the 5M quota)
> which is governed by
> (django/tests/regressiontests/file_uploads/uploadhandler.py)
>
> def receive_data_chunk(self, raw_data, start):
>        self.total_upload += len(raw_data)
>        if self.total_upload >= self.QUOTA:
>           raise StopUpload(connection_reset=True)
>        return raw_data
>
> So obviously my proposed attack is to simply say "content length is
> tiny" and "this file is actually HUGE".
> I hope I missed something :) I don't really want this to occur ...

A decent web server such as Apache (under mod_wsgi) will stop reading
the original content at the content length specified in the request.
Thus not possible to force more than content length down to the
application level.

Graham

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: potential issue re in memory django file uploading.

[dave b]

On 28 August 2010 22:46, Graham Dumpleton  wrote:
>
>
> On Aug 28, 7:58 pm, "david b."  wrote:
>> Ok so I was looking through the code and I saw this (in
>> django/core/files/uploadhandler.py) :
>>
>> FileUploadHandler
>> ...
>>
>>    def new_file(self, field_name, file_name, content_type,
>> content_length, charset=None):
>>        """
>>        Signal that a new file has been started.
>>
>>        Warning: As with any data from the client, you should not trust
>>        content_length (and sometimes won't even get it).
>>        """
>>
>> So the content_length we control right? - Maybe I missed something but
>> ... I can say I want to upload a small file then upload a file that
>> triggers an oom condition / use a lot of memory no ? ...
>>
>> And then this.
>>
>> class MemoryFileUploadHandler(FileUploadHandler):
>>    """
>>    File upload handler to stream uploads into memory (used for small
>> files).
>>    """
>>
>>    def handle_raw_input(self, input_data, META, content_length,
>> boundary, encoding=None):
>>        """
>>        Use the content_length to signal whether or not this handler
>> should be in use.
>>        """
>>        # Check the content-length header to see if we should
>>        # If the post is too large, we cannot use the Memory handler.
>>        if content_length > settings.FILE_UPLOAD_MAX_MEMORY_SIZE:
>>            self.activated = False
>>        else:
>>            self.activated = True
>>
>>    def new_file(self, *args, **kwargs):
>>        super(MemoryFileUploadHandler, self).new_file(*args, **kwargs)
>>        if self.activated:
>>            self.file = StringIO()
>>            raise StopFutureHandlers()
>>
>>    def receive_data_chunk(self, raw_data, start):
>>        """
>>        Add the data to the StringIO file.
>>        """
>>        if self.activated:
>>            self.file.write(raw_data)
>>        else:
>>            return raw_data
>>
>>    def file_complete(self, file_size):
>>        """
>>        Return a file object if we're activated.
>>        """
>>        if not self.activated:
>>            return
>>
>>        self.file.seek(0)
>>        return InMemoryUploadedFile(
>>            file = self.file,
>>            field_name = self.field_name,
>>            name = self.file_name,
>>            content_type = self.content_type,
>>            size = file_size,
>>
>> There is a regression test for this  BUT --> in the test suite there
>> is # A small file (under the 5M quota)
>> which is governed by
>> (django/tests/regressiontests/file_uploads/uploadhandler.py)
>>
>> def receive_data_chunk(self, raw_data, start):
>>        self.total_upload += len(raw_data)
>>        if self.total_upload >= self.QUOTA:
>>           raise StopUpload(connection_reset=True)
>>        return raw_data
>>
>> So obviously my proposed attack is to simply say "content length is
>> tiny" and "this file is actually HUGE".
>> I hope I missed something :) I don't really want this to occur ...
>
> A decent web server such as Apache (under mod_wsgi) will stop reading
> the original content at the content length specified in the request.
> Thus not possible to force more than content length down to the
> application level.
>
> Graham

The documentation and code  in django suggests that this is not the
case. So lets assume we are not using apache but another httpd of some
sort - then this problem will be present.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4 seems to
say otherwise from my reading.

Also as per the django code comment (in django/core/files/uploadhandler.py):

def new_file(self, field_name, file_name, content_type,
content_length, charset=None):
"""
Signal that a new file has been started.

Warning: As with any data from the client, you should not trust
content_length (and sometimes won't even get it).
"""
self.field_name = field_name
self.file_name = file_name
self.content_type = content_type
self.content_length = content_length
self.charset = charset

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Мобильная версия

[Christoffer Viken]

There is a PHP solution:
http://www.brainhandles.com/techno-thoughts/detecting-mobile-browsers
(thanks google)
But mostly it looks for a "HTTP_X_WAP_PROFILE" header, and does the usual
user-agent test...
But the good thing is that you can use keyword search... i.e "Blackberry",
"iPhone", "Android", etc... you probably need to make sure that the page you
serve is compatible anyway.

http://www.thewirelessfaq.com/how_to_distinguish_a_mobile_browser_from_a_desktop_browser

2010/8/28 Vanger - irk 

> Спасибо за перевод моего вопроса, но тут дело в том, что я уже видел
> эту страницу, и список там далеко не полный, и тем более, список этот
> постоянно пополняется, с выходом новых ОС для мобильников.
> Как реализовать универсальный проверку? Создать свой словарь из кусков
> возможных User Agent'ов без использования цифр версий ОС и тд и
> проверять его вхождение в полученный User Agent зашедшего на сайт
> пользователя?
>
> On 27 авг, 21:01, Рогалевич (Ковалевич)  wrote:
> > Question was: how to determine that user comes from mobile phone to show
> him
> > mobile version of site. May be by parsing user agent. (for examplehttp://
> en.wikipedia.org/wiki/List_of_user_agents_for_mobile_phones)
> >
> > 2010/8/27 Lachlan Musicman 
> >
> > > That come out wrong on re reading. I didn't mean to offend if I did,
> apols.
> >
> > --
> > Best Regards,
> > Mila
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>


-- 
--Desktop Browser-
Christoffer Viken / CVi

i=0

str="kI4dJMtXAv0m3cUiPKx8H"

while i<=20:

if i%3 and not i%4:

print str[i],

i=i+1

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: potential issue re in memory django file uploading.

[dave b]

On 28 August 2010 23:09, dave b  wrote:
> On 28 August 2010 22:46, Graham Dumpleton  wrote:
>>
>>
>> On Aug 28, 7:58 pm, "david b."  wrote:
>>> Ok so I was looking through the code and I saw this (in
>>> django/core/files/uploadhandler.py) :
>>>
>>> FileUploadHandler
>>> ...
>>>
>>>    def new_file(self, field_name, file_name, content_type,
>>> content_length, charset=None):
>>>        """
>>>        Signal that a new file has been started.
>>>
>>>        Warning: As with any data from the client, you should not trust
>>>        content_length (and sometimes won't even get it).
>>>        """
>>>
>>> So the content_length we control right? - Maybe I missed something but
>>> ... I can say I want to upload a small file then upload a file that
>>> triggers an oom condition / use a lot of memory no ? ...
>>>
>>> And then this.
>>>
>>> class MemoryFileUploadHandler(FileUploadHandler):
>>>    """
>>>    File upload handler to stream uploads into memory (used for small
>>> files).
>>>    """
>>>
>>>    def handle_raw_input(self, input_data, META, content_length,
>>> boundary, encoding=None):
>>>        """
>>>        Use the content_length to signal whether or not this handler
>>> should be in use.
>>>        """
>>>        # Check the content-length header to see if we should
>>>        # If the post is too large, we cannot use the Memory handler.
>>>        if content_length > settings.FILE_UPLOAD_MAX_MEMORY_SIZE:
>>>            self.activated = False
>>>        else:
>>>            self.activated = True
>>>
>>>    def new_file(self, *args, **kwargs):
>>>        super(MemoryFileUploadHandler, self).new_file(*args, **kwargs)
>>>        if self.activated:
>>>            self.file = StringIO()
>>>            raise StopFutureHandlers()
>>>
>>>    def receive_data_chunk(self, raw_data, start):
>>>        """
>>>        Add the data to the StringIO file.
>>>        """
>>>        if self.activated:
>>>            self.file.write(raw_data)
>>>        else:
>>>            return raw_data
>>>
>>>    def file_complete(self, file_size):
>>>        """
>>>        Return a file object if we're activated.
>>>        """
>>>        if not self.activated:
>>>            return
>>>
>>>        self.file.seek(0)
>>>        return InMemoryUploadedFile(
>>>            file = self.file,
>>>            field_name = self.field_name,
>>>            name = self.file_name,
>>>            content_type = self.content_type,
>>>            size = file_size,
>>>
>>> There is a regression test for this  BUT --> in the test suite there
>>> is # A small file (under the 5M quota)
>>> which is governed by
>>> (django/tests/regressiontests/file_uploads/uploadhandler.py)
>>>
>>> def receive_data_chunk(self, raw_data, start):
>>>        self.total_upload += len(raw_data)
>>>        if self.total_upload >= self.QUOTA:
>>>           raise StopUpload(connection_reset=True)
>>>        return raw_data
>>>
>>> So obviously my proposed attack is to simply say "content length is
>>> tiny" and "this file is actually HUGE".
>>> I hope I missed something :) I don't really want this to occur ...
>>
>> A decent web server such as Apache (under mod_wsgi) will stop reading
>> the original content at the content length specified in the request.
>> Thus not possible to force more than content length down to the
>> application level.
>>
>> Graham
>
> The documentation and code  in django suggests that this is not the
> case. So lets assume we are not using apache but another httpd of some
> sort - then this problem will be present.
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4 seems to
> say otherwise from my reading.

Just to clarify this - I meant that the http content length header
item is *not* required - as per
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4 (also see
4.4.2), so I do not believe that apache would do what you said :) -
there is a default limit in a apache of around 2gb for the attackers
file to reach though.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: potential issue re in memory django file uploading.

[dave b]

On 28 August 2010 23:21, dave b  wrote:
> On 28 August 2010 23:09, dave b  wrote:
>> On 28 August 2010 22:46, Graham Dumpleton  wrote:
>>>
>>>
>>> On Aug 28, 7:58 pm, "david b."  wrote:
 Ok so I was looking through the code and I saw this (in
 django/core/files/uploadhandler.py) :

 FileUploadHandler
 ...

    def new_file(self, field_name, file_name, content_type,
 content_length, charset=None):
        """
        Signal that a new file has been started.

        Warning: As with any data from the client, you should not trust
        content_length (and sometimes won't even get it).
        """

 So the content_length we control right? - Maybe I missed something but
 ... I can say I want to upload a small file then upload a file that
 triggers an oom condition / use a lot of memory no ? ...

 And then this.

 class MemoryFileUploadHandler(FileUploadHandler):
    """
    File upload handler to stream uploads into memory (used for small
 files).
    """

    def handle_raw_input(self, input_data, META, content_length,
 boundary, encoding=None):
        """
        Use the content_length to signal whether or not this handler
 should be in use.
        """
        # Check the content-length header to see if we should
        # If the post is too large, we cannot use the Memory handler.
        if content_length > settings.FILE_UPLOAD_MAX_MEMORY_SIZE:
            self.activated = False
        else:
            self.activated = True

    def new_file(self, *args, **kwargs):
        super(MemoryFileUploadHandler, self).new_file(*args, **kwargs)
        if self.activated:
            self.file = StringIO()
            raise StopFutureHandlers()

    def receive_data_chunk(self, raw_data, start):
        """
        Add the data to the StringIO file.
        """
        if self.activated:
            self.file.write(raw_data)
        else:
            return raw_data

    def file_complete(self, file_size):
        """
        Return a file object if we're activated.
        """
        if not self.activated:
            return

        self.file.seek(0)
        return InMemoryUploadedFile(
            file = self.file,
            field_name = self.field_name,
            name = self.file_name,
            content_type = self.content_type,
            size = file_size,

 There is a regression test for this  BUT --> in the test suite there
 is # A small file (under the 5M quota)
 which is governed by
 (django/tests/regressiontests/file_uploads/uploadhandler.py)

 def receive_data_chunk(self, raw_data, start):
        self.total_upload += len(raw_data)
        if self.total_upload >= self.QUOTA:
           raise StopUpload(connection_reset=True)
        return raw_data

 So obviously my proposed attack is to simply say "content length is
 tiny" and "this file is actually HUGE".
 I hope I missed something :) I don't really want this to occur ...
>>>
>>> A decent web server such as Apache (under mod_wsgi) will stop reading
>>> the original content at the content length specified in the request.
>>> Thus not possible to force more than content length down to the
>>> application level.
>>>
>>> Graham
>>
>> The documentation and code  in django suggests that this is not the
>> case. So lets assume we are not using apache but another httpd of some
>> sort - then this problem will be present.
>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4 seems to
>> say otherwise from my reading.
>
> Just to clarify this - I meant that the http content length header
> item is *not* required - as per
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4 (also see
> 4.4.2), so I do not believe that apache would do what you said :) -
> there is a default limit in a apache of around 2gb for the attackers
> file to reach though.
>

Woop I hit send a bit early, I meant to also include:
So now the attack can now just not specify the content length and um...

>>> None < 2621440
True


We pass the check ;) as far as I know. Look if I really have missed
something do tell me :)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Мобильная версия

[Sergey Panfilov]

Замучаетесь поддерживать список user-agent. По-моему, я видел
приложение django-mobile, которое использует базу данных wurfl.

On 27 авг, 05:42, Vanger - irk  wrote:
> не могу понять, как лучше реализовать определение того, что человек
> зашел сейчас с мобилы, и что мне нужно подсунуть ему мобильную
> версию ?
> Может быть кто-то уже реализовывал эти моменты?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: mod_wsgi setup issue

[Timothy Makobu]

here is my config:

***
[m...@web101 www]$ cat myproject.wsgi
import os
import sys

sys.path = ['/home/mako/webapps/www'] + sys.path
from django.core.handlers.wsgi import WSGIHandler

os.environ['DJANGO_SETTINGS_MODULE'] = 'timssite.settings'
application = WSGIHandler()
***

that's right outside the actual project folder, timssite.

hope this shakes something loose.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: potential issue re in memory django file uploading.

[Steve Holden]

On 8/28/2010 9:50 AM, dave b wrote:
> On 28 August 2010 23:21, dave b  wrote:
>> On 28 August 2010 23:09, dave b  wrote:
[...]
>>> The documentation and code  in django suggests that this is not the
>>> case. So lets assume we are not using apache but another httpd of some
>>> sort - then this problem will be present.
>>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4 seems to
>>> say otherwise from my reading.
>>
>> Just to clarify this - I meant that the http content length header
>> item is *not* required - as per
>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4 (also see
>> 4.4.2), so I do not believe that apache would do what you said :) -
>> there is a default limit in a apache of around 2gb for the attackers
>> file to reach though.
>>
> 
> Woop I hit send a bit early, I meant to also include:
> So now the attack can now just not specify the content length and um...
> 
 None < 2621440
> True
> 
> 
> We pass the check ;) as far as I know. Look if I really have missed
> something do tell me :)
> 
Would you mind trimming your replies to exclude the irrelevant stuff
from earlier in the thread. That way, I might actually read them ... ;-)

regards
 Steve
-- 
DjangoCon US 2010 September 7-9 http://djangocon.us/

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

authentication through http authorization header

[yupu]

Dear Djangoer:

I am new to Django. Please excuse me if the question is naive.

I am trying to figure out if I could integrate my company's "access
manager" with Django's authorization.

Every time a user try to login my Django application, he/she got
redirect to "access Manager" to put the company username and password
in. Access Manager then does the authorization for me against the LDAP
and pass the base64 encode username in the authorization header.

I found the following doc helpful:http://docs.djangoproject.com/en/dev/
howto/auth-remote-user/#.

I guess my situation belongs to auth-remote-user with custom header
but I am not sure how to subclass RemoteUserMiddleware.

Thanks,
Yupu


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: potential issue re in memory django file uploading.

[Graham Dumpleton]

On Aug 28, 11:21 pm, dave b  wrote:
> >>> So obviously my proposed attack is to simply say "content length is
> >>> tiny" and "this file is actually HUGE".
> >>> I hope I missed something :) I don't really want this to occur ...
>
> >> A decent web server such as Apache (under mod_wsgi) will stop reading
> >> the original content at the content length specified in the request.
> >> Thus not possible to force more than content length down to the
> >> application level.
>
> >> Graham
>
> > The documentation and code  in django suggests that this is not the
> > case. So lets assume we are not using apache but another httpd of some
> > sort - then this problem will be present.
> >http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4seems to
> > say otherwise from my reading.
>
> Just to clarify this - I meant that the http content length header
> item is *not* required - as 
> perhttp://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4(also see
> 4.4.2), so I do not believe that apache would do what you said :) -
> there is a default limit in a apache of around 2gb for the attackers
> file to reach though.

What you are talking about is chunked transfer encoding. This is the
only way you can not have a content length.

Chunked transfer encoding on request content isn't well supported.
Specifically, chunked transfer encoding is not supported by:

  mod_python

  FASTCGI
  SCGI
  AJP
  CGI

  WSGI

So, basically every standard way that Django can be hosted doesn't
support chunked transfer encoding on request content.

What you should instead see is an immediate HTTP_LENGTH_REQUIRED error
response from web server.

That said, some pure Python WSGI servers, eg., wsgiref in Python
standard library, may be broken and don't properly error when no
content length. However, for WSGI applications at least, they will be
broken if they try and read more than content length anyway, where it
takes on value of 0 if not specified, because reading more than
content length is a violation of the WSGI specification.

All up, I would suggest you are getting worked up over nothing.

BTW, have you actually tried to test your hypothesis to see whether it
is correct? If you have, post what server arrangement you are using.

Graham

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: potential issue re in memory django file uploading.

[Steve Holden]

On 8/28/2010 6:10 PM, Graham Dumpleton wrote:
> On Aug 28, 11:21 pm, dave b  wrote:
> So obviously my proposed attack is to simply say "content length is
> tiny" and "this file is actually HUGE".
[...]
> All up, I would suggest you are getting worked up over nothing.
+1

regards
 Steve
-- 
DjangoCon US 2010 September 7-9 http://djangocon.us/

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: potential issue re in memory django file uploading.

[dave b]

On 29 August 2010 08:28, Steve Holden  wrote:
> On 8/28/2010 6:10 PM, Graham Dumpleton wrote:
>> On Aug 28, 11:21 pm, dave b  wrote:
>> So obviously my proposed attack is to simply say "content length is
>> tiny" and "this file is actually HUGE".
> [...]
>> All up, I would suggest you are getting worked up over nothing.
> +1
>

Yes I have :) it "works for me tm".
Also, you have to consider the other problem. If the file is > 2.5 mb
it can be put in /tmp and this has no size limits which again is going
to make the system slower and can be used to attack it? in either case
there seem to be real protections against this in django core as far
as I can see.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: potential issue re in memory django file uploading.

[dave b]

On 29 August 2010 13:17, dave b  wrote:
> On 29 August 2010 08:28, Steve Holden  wrote:
>> On 8/28/2010 6:10 PM, Graham Dumpleton wrote:
>>> On Aug 28, 11:21 pm, dave b  wrote:
>>> So obviously my proposed attack is to simply say "content length is
>>> tiny" and "this file is actually HUGE".
>> [...]
>>> All up, I would suggest you are getting worked up over nothing.
>> +1
>>
>
> Yes I have :) it "works for me tm".
> Also, you have to consider the other problem. If the file is > 2.5 mb
> it can be put in /tmp and this has no size limits which again is going
> to make the system slower and can be used to attack it? in either case
> there seem to be real protections against this in django core as far
> as I can see.
>

I meant "no" real protections against this in django core.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: potential issue re in memory django file uploading.

[Graham Dumpleton]

On Aug 29, 1:17 pm, dave b  wrote:
> On 29 August 2010 08:28, Steve Holden  wrote:
>
> > On 8/28/2010 6:10 PM, Graham Dumpleton wrote:
> >> On Aug 28, 11:21 pm, dave b  wrote:
> >> So obviously my proposed attack is to simply say "content length is
> >> tiny" and "this file is actually HUGE".
> > [...]
> >> All up, I would suggest you are getting worked up over nothing.
> > +1
>
> Yes I have :) it "works for me tm".
> Also, you have to consider the other problem. If the file is > 2.5 mb
> it can be put in /tmp and this has no size limits which again is going
> to make the system slower and can be used to attack it? in either case
> there seem to be real protections against this in django core as far
> as I can see.

Use Apache/mod_wsgi and you can say:

  LimitRequestBody 100

and Apache/mod_wsgi will give back a HTTP_REQUEST_ENTITY_TOO_LARGE
error when it goes over that size before it even passes the request to
Django and even before any of the request content is read by Apache.

So, add the protections where most appropriate if you want to outright
block requests with large content. If your issue is efficient handling
of large posts, where you do want to handle them, then that is an
issue for Django.

Note that other Apache modules by which you can host Django may not
work properly in honouring LimitRequestBody directive of Apache. The
mod_python module for example doesn't really get it right, causing an
exception when request content tries to be read by Django application,
resulting in a malformed error response.

Graham

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: potential issue re in memory django file uploading.

[dave b]

On 29 August 2010 13:33, Graham Dumpleton  wrote:
>
>
> On Aug 29, 1:17 pm, dave b  wrote:
>> On 29 August 2010 08:28, Steve Holden  wrote:
>>
>> > On 8/28/2010 6:10 PM, Graham Dumpleton wrote:
>> >> On Aug 28, 11:21 pm, dave b  wrote:
>> >> So obviously my proposed attack is to simply say "content length is
>> >> tiny" and "this file is actually HUGE".
>> > [...]
>> >> All up, I would suggest you are getting worked up over nothing.
>> > +1
>>
>> Yes I have :) it "works for me tm".
>> Also, you have to consider the other problem. If the file is > 2.5 mb
>> it can be put in /tmp and this has no size limits which again is going
>> to make the system slower and can be used to attack it? in either case
>> there seem to be real protections against this in django core as far
>> as I can see.
>
> Use Apache/mod_wsgi and you can say:
>
>  LimitRequestBody 100
>
> and Apache/mod_wsgi will give back a HTTP_REQUEST_ENTITY_TOO_LARGE
> error when it goes over that size before it even passes the request to
> Django and even before any of the request content is read by Apache.
>
> So, add the protections where most appropriate if you want to outright
> block requests with large content. If your issue is efficient handling
> of large posts, where you do want to handle them, then that is an
> issue for Django.
>
> Note that other Apache modules by which you can host Django may not
> work properly in honouring LimitRequestBody directive of Apache. The
> mod_python module for example doesn't really get it right, causing an
> exception when request content tries to be read by Django application,
> resulting in a malformed error response.

Yes I understand that both apache and some the mods have limits.
However, this doesn't stop a persistent attacker abusing these
relatively high limits.
IMHO I feel that django should be able to put a cap on the largest
size temporary file size possible. In addition, /tmp is a fine place
to store temporary files if the size may not be known.

I propose the following in psudo code:

1. start reading the file if we are receiving it (regardless of the
default 2.5 mb limit)
2. once it goes over 2.5mb / the configured default  shift to the next
available storage option.

In addition, as you are pointing out that it is really not possible
for django to handle chunked requests and the content length field
must be specified then you should have no problems with the following
patch (in either case this is safe because by default it will revert
back to the temporary file storage) :


--- django/core/files/uploadhandler.py.orig 2010-08-29 13:50:17.0 
+1000
+++ django/core/files/uploadhandler.py  2010-08-29 14:01:15.0 +1000
@@ -153,7 +153,7 @@
 """
 # Check the content-length header to see if we should
 # If the post is too large, we cannot use the Memory handler.
-if content_length > settings.FILE_UPLOAD_MAX_MEMORY_SIZE:
+   if content_length is None or content_length >
settings.FILE_UPLOAD_MAX_MEMORY_SIZE:
 self.activated = False
 else:
 self.activated = True
@@ -170,6 +170,7 @@
 """
 if self.activated:
 self.file.write(raw_data)
+   self.file.truncate(settings.FILE_UPLOAD_MAX_MEMORY_SIZE)
 else:
 return raw_data

http://pastebin.com/5vgGMb5z

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.