Ticket #25328 - LiveServerTestCase with HTTPS - opinions?

[Jakub Gocławski]

Hi,

Ticket: https://code.djangoproject.com/ticket/25328

I made a proposal to include a LiveServerTestCase, which runs an HTTPS server instead of standard HTTP server. I've been asked to get more feedback for this idea.

If my refactor is merged I can release the test case as a separate app. But including it in Django itself would encourage to write HTTPS-only applications and to write Selenium tests for them.

I've seen recent moves to encourage various security "good habits" into Django, like integrating "security header" in 1.8 (https://docs.djangoproject.com/en/1.8/ref/middleware/#module-django.middleware.security). Let's Enrypt (which should be released in November) will futher ease enabling HTTPS.

Testing HTTPS-enabled site in Django should be just as easy as testing a standard HTTP site.

Do you think it's a good idea to add it to Django core? Or should I release it as as a separate app?

[Tim Graham]

Could you explain what types of tests require https (or otherwise expand on the rationale for adding this)? If the answer is that we don't want to have a separate "test settings" with all the SSL settings disabled (CSRF_COOKIE_SECURE, SECURE_HSTS_SECONDS, etc.) then I understand this, however, there was previous discussion about adding SSL support to runserver met with mixed reaction [1] and it seems a little funny to me that we'd including a test SSL server and not a runserver solution.

[1] https://groups.google.com/d/topic/django-developers/PgBcSEiUdw0/discussion

[Shai Berger]

Hi,

On Monday 31 August 2015 21:24:53 Tim Graham wrote:
> however, there was previous discussion about adding SSL support to
> runserver met with mixed reaction [1] and it seems a little funny to me
> that we'd including a test SSL server and not a runserver solution.
>
> [1]
> https://groups.google.com/d/topic/django-developers/PgBcSEiUdw0/discussion
>

Note that the main counter-argument for HTTPS on runserver was that it is easy
enough to achieve with external tools. I'm not sure this arguments holds for
test-cases as well (if it does, perhaps a documentation patch is in order).

Shai.

[Jakub Gocławski]

The argument that adding LiveServerTestCase with HTTPS as a separate tool is easy - it is valid in this case, after my refactor has been merged.

The real use-case when I (and someone else may) need HTTPSLiveServerTestCase is the one I wrote before:

• in a HTTPS-only application you can use custom secure cookies (not only CSRF or session, but application specific). But if you don't have a HTTPSLiveServerTestCase you cannot test it with Selenium as those cookies won't be passed to the server, which runs as HTTP
  

I'm not aware of any other issues, but maybe there is something more.

But my main point and what I wanted to suggest is that Django should encourage writing HTTPS-only applications. In my opinion HTTPS as default (instead of HTTP as default) should be seriously considered and thus, testing a HTTPS application shouldn't require to install external packages. 

HTTPS is the future considering the SPDY/HTTP2 protocol development. Getting and deploying a certificate will also be much easier when Let's Encrypt launches in about a month from now.

This argument holds for runserver as well, but it's indeed another thread, so I will stick to running tests here :)

So "the problem" solved by HTTPSLiveServerTestCase is rather minor and can be achieved by using an external app. 

But "the idea" to encourage HTTPS is another thing and adding a test case is a small step into this direction. And of course adding a HTTPS runserver would be a bigger step :)

Considering the above and the discussion about HTTPS runserver - I will just release the testcase as a separate app.