Let me know if I'm off base here.
Regards,
Steven Berry
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an e
]: http://gunicorn-docs.readthedocs.org/en/latest/settings.html#ssl
> [2]: https://docs.djangoproject.com/en/1.8/howto/deployment/wsgi/gunicorn/
>
> -- Gert
>
> Twitter: @gvangool <http://twitter.com/gvangool>
> Web: http://gertvangool.be
>
> On Sat, May 9, 2015 at 4:19
ps://code.djangoproject.com/ticket/21978). Windows support still
> remains an unsolved issue (https://github.com/benoitc/gunicorn/issues/524),
> but I don't think the lack of Windows support should stall that effort or
> justify adding SSL support to the homegrown runserver.
>
should be? Is it good enough to have simple
TLS? Is it essential for developers to be able to specify the TLS version
and ciphers?
On Monday, May 11, 2015 at 6:30:39 PM UTC-4, Florian Apolloner wrote:
>
>
> On Monday, May 11, 2015 at 10:13:03 PM UTC+2, Steven Berry wrote:
>>
>
Florian,
I was merely presenting a rhetorical question to illustrate a point.
Perhaps there weren't other available web servers then, but there are now,
as has been pointed out. Prevalence and expectation of TLS/SSL is another
thing that's changed since 2005. We can choose to maintain runserver
Pull request https://github.com/django/django/pull/4633/ withdrawn.
Closing comments attached to the issue describing my interim (and likely
permanent) fix to all of my Django sites after taking Gert's suggestion.
I'll likely create a few blog posts detailing deployment processes instead
of pes
Hey all,
A note on Carl's first suggestion. I currently override the authenticate
function with my own that does something similar. Instead of passing in a
single backend I pass in an iterable (usually a set for O(1) checks) that
optionally overrides settings.AUTHENTICATION_BACKENDS.
I haven't
