Serving https with runserver
cool-RR
would have been useful.
Ram.
Andrej
host and then use reverse proxy:
ProxyPass / http://localhost:8000/
ProxyPassReverse / http://localhost:8000/
cool-RR
it. I enjoy the low headache factor of runserver. But it'll be nicer
if it served through https as well.
On Mar 1, 12:53 am, Andrej <amas...@gmail.com> wrote:
> because you need to load apache ssl gear. Set up your normal virtual
> host and then use reverse proxy:
>
> ProxyPass /http://localhost:8000/
> ProxyPassReverse /http://localhost:8000/
Janusz Harkot
J.
Adnan Sadzak
Anyway, as Janusz said http://www.stunnel.org/
So you can use stunnel: http://www.stunnel.org/
J.
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
cool-RR
Gonzalo Delgado
> Adnan, I'm really baffled by your response. No, my reasons for using
> SSL here is not because I'm afraid someone will sniff my data, We are
> talking here about `runserver`, which is the development server which
> is never used for production. The goal of `runserver` is to be able to
> easily test how your Django project behaves before you upload it to
> the real server.
test *exactly* how a Django project behaves before uploading it to a
production server. There are a couple of cases where it will always fall
short, like serving static media or using SSL. It also can't help you
much to test how a site behaves with a big number of requests per second.
For those cases a staging[0] server is used, which is a copy of the
production server but for testing how the site behaves under certain
conditions or with new features, etc.
[0] http://en.wikipedia.org/wiki/Staging_site
--
Gonzalo Delgado <gonza...@gmail.com>
Ian Lewis
behavior on your local machine before running it on a production
server. Setup can be pretty annoying for one.
I wrote a blog post on how to do this very thing a while back. I used
stunnel, as Janusz mentioned, to test SSL redirect behavior on the
development server. You need to run two dev servers one for http and
one for https. You also need to make sure that you set HTTPS=on as an
environment variable so that request.is_secure() returns true
properly.
http://www.ianlewis.org/en/testing-https-djangos-development-server
Ian
On Mon, Mar 1, 2010 at 7:43 PM, Gonzalo Delgado <gonza...@gmail.com> wrote:
> El 01/03/10 07:07, cool-RR escribió:
> --
> You received this message because you are subscribed to the Google Groups "Django users" group.
> To post to this group, send email to django...@googlegroups.com.
> To unsubscribe from this group, send email to django-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
>
>
--
=======================================
株式会社ビープラウド イアン・ルイス
〒150-0012
東京都渋谷区広尾1-11-2アイオス広尾ビル604
email: ianm...@beproud.jp
TEL：03-5795-2707
FAX：03-5795-2708
http://www.beproud.jp/
=======================================
Adnan Sadzak
Gonzalo Delgado
> Then maybe web server is the best option. In all cases you have to
> configure something until someday 'runserver' come with ssl support.
It doesn't seem like that day will ever come:
"""
DON'T use this server in anything resembling a production environment.
It's intended only for use while developing. (*We're in the business of
making Web frameworks, not Web servers*.)
"""
(
http://docs.djangoproject.com/en/1.1/intro/tutorial01/#the-development-server
)
--
Gonzalo Delgado <gonza...@gmail.com>
Jirka Vejrazka
>> configure something until someday 'runserver' come with ssl support.
I think that no one would really object if runserver was SSL-aware,
however people requesting it need to be aware that having an SSL-aware
webserver is significantly more difficult that having a simple HTTP
web server. The things that come to mind are:
- extra dependencies: I'm not sure about all of those, but at least
openssl comes to mind
- the need to have a server certificate: While not a terribly
complex task to generate one, some decisions need to be made (e.g.
where it will be stored?).
- more complex URL handling for testing. As local server uses port
8000 by default and links are usually relative, it's not a big deal.
But if people start relying on having HTTPS dev webserver, they might
get confused if that one is not running on default port 443. So, if
dev web server was running on port 8443, people would need to keep
this in mind when working on their templates / redirects.
On top of those, I can see 2 big risks:
- if SSL-aware development server exists and easily available (just
one command), people could start relying on it as it'd be much easier
to set up than any other SSL website. That would be a big mistake, the
dev server would be very insecure, missing lots of necessary features
(and almost certainly having a self-signed certificate).
- it'd probably only escalate things. If people get SSL-enabled dev
server, they start asking why it does not support client-side
certificates :)
Just my 2 cents.
Jirka
Kenneth Gonsalves
> >> Then maybe web server is the best option. In all cases you have to
> >> configure something until someday 'runserver' come with ssl support.
>
> I think that no one would really object if runserver was SSL-aware,
>
or you could have an nginx server proxying to the dev server - nginx looks
after the ssl and listens on port 443 - runserver does not need to know
anything about ssl. And you do not need to restart on code change and you can
have print output on the console - in short, have your cake and eat it too.
--
regards
Kenneth Gonsalves
Senior Associate
NRC-FOSS
http://certificate.nrcfoss.au-kbc.org.in