Re: Security Advisory: BREACH and Django

[simonb]

How about requiring that if csrfmiddlewaretoken is set, no matter what http 
method (GET, POST...), it is correct otherwise 403 response.

Simon

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC] Revamping validation framework and merging django-secure once again

[Russell Keith-Magee]

On Wed, Aug 7, 2013 at 4:03 AM, Christopher Medrela  wrote:

> I'm still working at polishing after reviewing. I've deprecated
> `requires_model_validation` and `validate`. I've started at adding tests
> for
> contenttype fields: `GenericForeignKey` and `GenericRelation`.
>
> I've updated gsoc2013-checks-review branch [1]. Now it's the same as
> gsoc2013-checks branch [2]. I will push new work to the latter while the
> former
> will remain unchanged. I'm working at contenttype tests in
> gsoc2013-checks-contenttypes [3] branch. The work is not finished yet and
> there
> are some failing tests.
>
> @Shai Berger: Thank you for creating the ticket. I'm sorry that I
> procrastinated accepting it -- I finally did it and proposed a patch. [4]
>
> [1] https://github.com/chrismedrela/django/tree/gsoc2013-checks-review
> [2] https://github.com/chrismedrela/django/tree/gsoc2013-checks
> [3]
> https://github.com/chrismedrela/django/tree/gsoc2013-checks-contenttypes
> [4] https://code.djangoproject.com/ticket/20814
>
> Questions:
>
> 1. Output formatting. We decided that every error/warning will take one
> line plus
> additional one for a hint if it's provided. The justification is that a
> Django
> user may type "grep HINT" to filter all hints. But now I think it's
> unpractical
> since the lines with hints doesn't say which object is invalid. So we can:
> (1)
> put hint in the same line as the error message or (2) change the format to
> sth
> like this:
>
> applabel.modellabel: Error message.
> applabel.modellabel: HINT: Hint.
>

For my money, the label on the second line isn't needed. I know I gave grep
as a use case, but in retrospect, that's probably isn't as useful as you'd
think. The reason to have the newline break with an indent is so that
theres a visual cue for any hint. It makes the hint stand out. Putting a
prefix on that line obscures this.

applabel.modellabel: Error message
HINT: the hint


> 2. Is it allowed to use `GenericRelation` pointing to a model if the model
> lacks
> `GenericForeignKey`?
>

In theory, I suppose you could, as long as there was a pair of object and
content type fields. However, in practice, I don't think this is a very
likely use case. I'd be completely comfortable if you confirmed the
existence of a GenericForeignKey. Raising this as a warning might be a good
approach here.

3. I've added unicode_literals import to django/core/management.py but this
> affected `BaseCommand.verbosity` default value. In order not to break
> commands,
> I left the attribute as a bytestring [5]. Changing it to an unicode breaks
> some admin_scipts tests, i. e. `CommandTypes.test_app_command` expects in
> stdout:
>
> ... options=[('pythonpath', None), ... ('verbosity', '1')]
>
> while the command prints:
>
> ... options=[('pythonpath', None), ... ('verbosity', u'1')]
>

I can see what you're doing here, but I'm not sure it's needed. u'1' == '1'
under Python 2.7, and under Python 3 it's all unicode anyway.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Security Advisory: BREACH and Django

[Wim Lewis]

On 6 Aug 2013, at 12:34 PM, Tim Chase wrote:
> On 2013-08-06 12:53, Donald Stufft wrote:
>> This incurs the cost that every request to Django invalidates all
>> existing CSRF tokens [] OR requires you to store a separate CSRF token 
>> for each
>> request and look up the submitted CSRF token in that set of stored
>> tokens.
> 
> After through the PDF, my understanding that it requires the token
> to be constant across all requests.  One might be able to mitigate it
> a bit by randomly inserting values into the CSRF token that then get
> stripped back out before being checked.  So the actual transmitted
> value changes every time (per 3.4 in the PDF), but the server knows
> how to strip the random junk back out.  

I had a similar thought. More generally: Django could pick a random nonce and 
send nonce + F(nonce, csrftoken) where F can be any of a lot of functions 
(inserting half the nonce before and half after the csrftoken; XORing the 
csrftoken with the nonce; doing a full AES encryption; computing SHA1(nonce + 
token); etc). Django would either reverse the process upon receipt to recover 
the original csrftoken, or if a nonreversible F() is used, it could use the 
returned nonce to compute F(nonce, csrftoken) and compare that with the value 
sent by the client.

As long as the function F() is not something that the compressor can "see 
through" in any way, this should prevent BREACH/CRIME style traffic-size 
attacks.

Does Django need to do something similar to protect session identifiers?


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

django.utils.functional.cached_property

[Daniele Procida]

Is there any reason why django.utils.functional.cached_property should not be 
documented, so that it can easily be used?



I'd have a lot of use for it.

Daniele

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC] Revamping validation framework and merging django-secure once again

[Christopher Medrela]

I'm still working at polishing after reviewing. I've deprecated
`requires_model_validation` and `validate`. I've started at adding tests for
contenttype fields: `GenericForeignKey` and `GenericRelation`.

I've updated gsoc2013-checks-review branch [1]. Now it's the same as
gsoc2013-checks branch [2]. I will push new work to the latter while the 
former
will remain unchanged. I'm working at contenttype tests in
gsoc2013-checks-contenttypes [3] branch. The work is not finished yet and 
there
are some failing tests.

@Shai Berger: Thank you for creating the ticket. I'm sorry that I 
procrastinated accepting it -- I finally did it and proposed a patch. [4]

[1] https://github.com/chrismedrela/django/tree/gsoc2013-checks-review
[2] https://github.com/chrismedrela/django/tree/gsoc2013-checks
[3] https://github.com/chrismedrela/django/tree/gsoc2013-checks-contenttypes
[4] https://code.djangoproject.com/ticket/20814

Questions:

1. Output formatting. We decided that every error/warning will take one 
line plus
additional one for a hint if it's provided. The justification is that a 
Django
user may type "grep HINT" to filter all hints. But now I think it's 
unpractical
since the lines with hints doesn't say which object is invalid. So we can: 
(1)
put hint in the same line as the error message or (2) change the format to 
sth
like this:

applabel.modellabel: Error message.
applabel.modellabel: HINT: Hint.

2. Is it allowed to use `GenericRelation` pointing to a model if the model 
lacks
`GenericForeignKey`?

3. I've added unicode_literals import to django/core/management.py but this
affected `BaseCommand.verbosity` default value. In order not to break 
commands,
I left the attribute as a bytestring [5]. Changing it to an unicode breaks 
some admin_scipts tests, i. e. `CommandTypes.test_app_command` expects in 
stdout:

... options=[('pythonpath', None), ... ('verbosity', '1')]

while the command prints:

... options=[('pythonpath', None), ... ('verbosity', u'1')]

[5] 
https://github.com/chrismedrela/django/blob/09579fdafc05dea90db41f519b26655010a50ac2/django/core/management/base.py#L169

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Security Advisory: BREACH and Django

[Tim Chase]

On 2013-08-06 12:53, Donald Stufft wrote:
> On Aug 6, 2013, at 12:16 PM, Tom Scrace  wrote:
>> On Tuesday, August 6, 2013 3:42:01 PM UTC+1, Jacob Kaplan-Moss
>> wrote:
>> 
>> We plan to take steps to address BREACH in Django itself, but in
>> the meantime we recommend that all users of Django understand
>> this vulnerability and take action if appropriate.
>> 
>> Would randomizing the CSRF token on each request be the correct
>> way to fix this in Django?
> 
> This incurs the cost that every request to Django invalidates all
> existing CSRF tokens (meaning if you start filling out a form, and
> then open another form in a different tab the first form will send
> an error) OR requires you to store a separate CSRF token for each
> request and look up the submitted CSRF token in that set of stored
> tokens.
> 
> There are a few possible solutions each with their own drawbacks.
> Such as secret hiding or disabling compression only for pages that
> have CSRF (or other secret output).

After through the PDF, my understanding that it requires the token
to be constant across all requests.  One might be able to mitigate it
a bit by randomly inserting values into the CSRF token that then get
stripped back out before being checked.  So the actual transmitted
value changes every time (per 3.4 in the PDF), but the server knows
how to strip the random junk back out.  Something like

  # a set of characters known not to be in tokens created
  # by the existing method
  JUNK_TO_STRIP = ' \t'
  JUNK_SET = frozenset(JUNK_TO_STRIP)
  MAX_JUNK_PER_CHAR = 5

  def random_junkify(c, junk=JUNK_TO_STRIP, count=MAX_JUNK_PER_CHAR):
return ''.join(
random.choice(junk)
for _ in range(count)
) + c

  def generate_token():
token = existing_token_generation()
return ''.join(
  random_junkify(c)
  for c in token
  )

  def new_check_token(token):
token = ''.join(c for c in token if c not in JUNK_SET)
return existing_token_check(token)

I'd be interested in others' thoughts on whether this might suffice
to stymie this attack.

-tkc









signature.asc
Description: PGP signature

Re: Security Advisory: BREACH and Django

[Donald Stufft]

On Aug 6, 2013, at 1:28 PM, mac...@framestart.com wrote:

> Am I correct that it is still safe to have compression enabled for static 
> files? Assuming you're not sending secrets inside CSS or JS files?
> 
> http://wiki.nginx.org/HttpGzipModule says that the gzip on directive can be 
> set in location.

Yes, any response which does not include secret data can be compressed.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Security Advisory: BREACH and Django

[maciek]

Am I correct that it is still safe to have compression enabled for static 
files? Assuming you're not sending secrets inside CSS or JS files?

http://wiki.nginx.org/HttpGzipModule says that the gzip on directive can be 
set in location.



On Tuesday, 6 August 2013 17:58:42 UTC+1, Donald Stufft wrote:
>
>
> On Aug 6, 2013, at 12:45 PM, Rob Yates > 
> wrote:
>
> This is a fascinating attack.  I scanned all of the information that I 
> could find and it wasn't clear how this could be used to breach CSRF 
> protection.  Is there more detail somewhere on that specific attack vector? 
>  
>
>
>
> Essentially if you have a string "abcd" which represents your CSRF token 
> in the body, compression will make it so that if you add the string "fghe" 
> to the output the size of the response will be larger than if you added the 
> string "abcd" to the output (because of compression). It's somewhat harder 
> to attack than that because it also requires an "anchor". In terms of CSRF 
> this likely requires an XSS as well (if your csrf token always has 
> csrf_token=" in front of it you can use that as your anchor, but html 
> escaping would escape it).
>
> Anchoring is a lot simpler for other secrets which are displayed to the 
> user, for instance if you're trying to steal a credit card number which 
> appears on the site as "Credit Card: 1234", then "Credit Card: " could be 
> your anchor, so you'd just need a way to influence the output of the page 
> so that you can add "Credit Card: " to try various combinations until 
> you find one that doesn't increase the size of the response.
>
>
> -Rob
>
> On Tuesday, August 6, 2013 10:42:01 AM UTC-4, Jacob Kaplan-Moss wrote:
>>
>> Hi folks --
>>
>> At last week's Black Hat conference, researchers announced the BREACH 
>> attack (http://breachattack.com/), a new attack on web apps that can 
>> recover data even when secured with SSL connections. Given what we know so 
>> far, we believe that BREACH may be used to compromise Django's CSRF 
>> protection. Thus, we're issuing a security advisory so that our users can 
>> defend themselves.
>>
>> You can read more details, including how the steps you can take to 
>> prevent yourself against this attack, on our blog:
>>
>> https://www.djangoproject.com/weblog/2013/aug/06/breach-and-django/
>>
>> We plan to take steps to address BREACH in Django itself, but in the 
>> meantime we recommend that all users of Django understand this 
>> vulnerability and take action if appropriate.
>>
>> Jacob
>>
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-develop...@googlegroups.com .
> To post to this group, send email to django-d...@googlegroups.com
> .
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  
>
>
>
> -
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 
> DCFA 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Security Advisory: BREACH and Django

[Michael Manfre]

Since the 1.6 release is very close, what are the chances that the security
fix would get backported to Django 1.4.x, even if 1.6 lands before a fix is
backported? There was a blog post about extending support for 1.4, but I
don't remember seeing any discussion on the list to help "figure out the
specifics".

https://www.djangoproject.com/weblog/2013/may/26/django-16-alpha-1/

Regards,
Michael Manfre


On Tue, Aug 6, 2013 at 10:42 AM, Jacob Kaplan-Moss wrote:

> Hi folks --
>
> At last week's Black Hat conference, researchers announced the BREACH
> attack (http://breachattack.com/), a new attack on web apps that can
> recover data even when secured with SSL connections. Given what we know so
> far, we believe that BREACH may be used to compromise Django's CSRF
> protection. Thus, we're issuing a security advisory so that our users can
> defend themselves.
>
> You can read more details, including how the steps you can take to prevent
> yourself against this attack, on our blog:
>
> https://www.djangoproject.com/weblog/2013/aug/06/breach-and-django/
>
> We plan to take steps to address BREACH in Django itself, but in the
> meantime we recommend that all users of Django understand this
> vulnerability and take action if appropriate.
>
> Jacob
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Security Advisory: BREACH and Django

[Donald Stufft]

On Aug 6, 2013, at 12:45 PM, Rob Yates  wrote:

> This is a fascinating attack.  I scanned all of the information that I could 
> find and it wasn't clear how this could be used to breach CSRF protection.  
> Is there more detail somewhere on that specific attack vector?  


Essentially if you have a string "abcd" which represents your CSRF token in the 
body, compression will make it so that if you add the string "fghe" to the 
output the size of the response will be larger than if you added the string 
"abcd" to the output (because of compression). It's somewhat harder to attack 
than that because it also requires an "anchor". In terms of CSRF this likely 
requires an XSS as well (if your csrf token always has csrf_token=" in front of 
it you can use that as your anchor, but html escaping would escape it).

Anchoring is a lot simpler for other secrets which are displayed to the user, 
for instance if you're trying to steal a credit card number which appears on 
the site as "Credit Card: 1234", then "Credit Card: " could be your anchor, so 
you'd just need a way to influence the output of the page so that you can add 
"Credit Card: " to try various combinations until you find one that doesn't 
increase the size of the response.

> 
> -Rob
> 
> On Tuesday, August 6, 2013 10:42:01 AM UTC-4, Jacob Kaplan-Moss wrote:
> Hi folks --
> 
> At last week's Black Hat conference, researchers announced the BREACH attack 
> (http://breachattack.com/), a new attack on web apps that can recover data 
> even when secured with SSL connections. Given what we know so far, we believe 
> that BREACH may be used to compromise Django's CSRF protection. Thus, we're 
> issuing a security advisory so that our users can defend themselves.
> 
> You can read more details, including how the steps you can take to prevent 
> yourself against this attack, on our blog:
> 
> https://www.djangoproject.com/weblog/2013/aug/06/breach-and-django/
> 
> We plan to take steps to address BREACH in Django itself, but in the meantime 
> we recommend that all users of Django understand this vulnerability and take 
> action if appropriate.
> 
> Jacob
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  


-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Security Advisory: BREACH and Django

[Donald Stufft]

On Aug 6, 2013, at 12:16 PM, Tom Scrace  wrote:

> On Tuesday, August 6, 2013 3:42:01 PM UTC+1, Jacob Kaplan-Moss wrote:
> 
> We plan to take steps to address BREACH in Django itself, but in the meantime 
> we recommend that all users of Django understand this vulnerability and take 
> action if appropriate.
> 
> 
> Would randomizing the CSRF token on each request be the correct way to fix 
> this in Django?

This incurs the cost that every request to Django invalidates all existing CSRF 
tokens (meaning if you start filling out a form, and then open another form in 
a different tab the first form will send an error) OR requires you to store a 
separate CSRF token for each request and look up the submitted CSRF token in 
that set of stored tokens.

There are a few possible solutions each with their own drawbacks. Such as 
secret hiding or disabling compression only for pages that have CSRF (or other 
secret output).

> 
> Tom 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  


-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Security Advisory: BREACH and Django

[Rob Yates]

This is a fascinating attack.  I scanned all of the information that I 
could find and it wasn't clear how this could be used to breach CSRF 
protection.  Is there more detail somewhere on that specific attack vector? 
 

-Rob

On Tuesday, August 6, 2013 10:42:01 AM UTC-4, Jacob Kaplan-Moss wrote:
>
> Hi folks --
>
> At last week's Black Hat conference, researchers announced the BREACH 
> attack (http://breachattack.com/), a new attack on web apps that can 
> recover data even when secured with SSL connections. Given what we know so 
> far, we believe that BREACH may be used to compromise Django's CSRF 
> protection. Thus, we're issuing a security advisory so that our users can 
> defend themselves.
>
> You can read more details, including how the steps you can take to prevent 
> yourself against this attack, on our blog:
>
> https://www.djangoproject.com/weblog/2013/aug/06/breach-and-django/
>
> We plan to take steps to address BREACH in Django itself, but in the 
> meantime we recommend that all users of Django understand this 
> vulnerability and take action if appropriate.
>
> Jacob
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Security Advisory: BREACH and Django

[Tom Scrace]

On Tuesday, August 6, 2013 3:42:01 PM UTC+1, Jacob Kaplan-Moss wrote:

>
> We plan to take steps to address BREACH in Django itself, but in the 
> meantime we recommend that all users of Django understand this 
> vulnerability and take action if appropriate.
>
>
Would randomizing the CSRF token on each request be the correct way to fix 
this in Django?

Tom 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deprecate FCGI support in Django 1.7

[Javier Guerra Giraldez]

On Tue, Aug 6, 2013 at 9:40 AM, Andre Terra  wrote:
> Assuming a UNIX environment. In Windowsland, nginx is still one of the best
> alternatives.


I meant use those _behind_ NginX.  neither is really good as an
external-facing HTTP process.

-- 
Javier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Security Advisory: BREACH and Django

[Jacob Kaplan-Moss]

Hi folks --

At last week's Black Hat conference, researchers announced the BREACH
attack (http://breachattack.com/), a new attack on web apps that can
recover data even when secured with SSL connections. Given what we know so
far, we believe that BREACH may be used to compromise Django's CSRF
protection. Thus, we're issuing a security advisory so that our users can
defend themselves.

You can read more details, including how the steps you can take to prevent
yourself against this attack, on our blog:

https://www.djangoproject.com/weblog/2013/aug/06/breach-and-django/

We plan to take steps to address BREACH in Django itself, but in the
meantime we recommend that all users of Django understand this
vulnerability and take action if appropriate.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deprecate FCGI support in Django 1.7

[Andre Terra]

On Tue, Aug 6, 2013 at 10:18 AM, Javier Guerra Giraldez
wrote:

> On Tue, Aug 6, 2013 at 6:28 AM, VernonCole  wrote:
> > I had come the the conclusion that FastCGI was the only way
>
>
> behind NginX, the best two options seem to be uWSGI and gunicorn.
> personally, I like uWSGI, but both are quite performant and
> low-resource.


Assuming a UNIX environment. In Windowsland, nginx is still one of the best
alternatives.


Cheers,
AT

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deprecate FCGI support in Django 1.7

[Javier Guerra Giraldez]

On Tue, Aug 6, 2013 at 6:28 AM, VernonCole  wrote:
> I had come the the conclusion that FastCGI was the only way


behind NginX, the best two options seem to be uWSGI and gunicorn.
personally, I like uWSGI, but both are quite performant and
low-resource.

-- 
Javier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Change username field widget in AuthenticationForm based on USERNAME_FIELD

[Anders Steinlein]

On Mon, Aug 5, 2013 at 10:00 PM, ptone  wrote:

> This seems like a reasonable change. I don't love the fact that the
> contrib.auth built in forms quasi support custom user models, as it leads
> to a less clear delineation about what parts of contrib.auth are tightly
> coupled auth the default User model.
>

OK, I'll go ahead and open a ticket and write a patch for this.

What kind of widgets for a username do you feel it's useful to support? I'm
thinking NumberInput for integer fields, EmailInput for email fields,
URLInput for URL fields, and TextInput for everything else.

/A.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deprecate FCGI support in Django 1.7

[VernonCole]

Let me second the need for a good "How To" document on deployment.  As a 
neophyte django user I suddenly felt very lost last week. After several 
months of development, the ADO interface to the Microsoft SQL server from 
Linux is working (it still needs some tuning, but the data does go in and 
out using runserver) and it is now time to deploy.  The boss requested an 
Nginx server, so I started searching the web for how to do it.  I had come 
the the conclusion that FastCGI was the only way that I could deploy and 
was planning on starting that this morning, until I read this thread.  Now 
I know that I was about to start down an obsolescent path. A "How To" in 
the official documentation would have prevented this false start.

Does anyone know of an existing cookbook that I can refer to as a starting 
point? Or should I be making accurate records of my work with a view to 
contributing a new document?
--
Vernon Cole
 

On Saturday, July 20, 2013 5:32:44 AM UTC-6, Christian Schmitt wrote:
>
> I would recommand to remove FastCGI. 
> That's the thing i love with the Python Community. Remove depracted or 
> obsolete things.
>
> The thing is, there are way more important things to do, than supporting a 
> 'depracted' way to deploy. And it's really not that hard to get mod_wsgi 
> with a httpd running.
> You could strip that down so easily and compile it, even on CentOS.
>
> Maybe it's better to improve the Docs about Apache2 / nginx / HAProxy 
> deployment with mod_wsgi than supporting FCGI.
> I mean some things like that:
>
> > 
> http://ontwik.com/python/django-deployment-workshop-by-jacob-kaplan-moss/
>
> I think that these things are really important. Howto get from development 
> to Production, with security.
> (btw. the talk is from 2011 and some things aren't up 2 date, like the 
> pgpool single point of failure thing, etc. today you could really well 
> deploy a good enviroment or 2 or more servers where you don't have any 
> single point of failure where you don't need to add any extra line of code. 
> okai maybe you need to find a good way to hold cookies in a good memory 
> based database, that you could share them between machines, but that is the 
> only thing you should care about, since that is the only you shouldn't hold 
> in your legacy database.)
>
> Am Sonntag, 14. Juli 2013 21:17:00 UTC+2 schrieb Florian Apolloner:
>>
>> Hi,
>>
>> I'd like to get rid of everything FCGI-specific in Django sooner or later 
>> (rather sooner). Flup isn't maintained since a long time and there is no 
>> ticket tracker to report stuff. Graham pointed out that if someone wants to 
>> use FCGI they can use 
>> http://uwsgi-docs.readthedocs.org/en/latest/Options.html#fastcgi-socketwhich 
>> doesn't even require flup, which sounds like a good compromise to me. 
>> I'd need some help for the docs from some uWSGI users, since I have no idea 
>> about it ;)
>>
>> Thoughts, objections?
>>
>> Cheers,
>> Florian
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.