[Django] #25328: Add LiveServerTestCase that runs an HTTPS server
Django
-----------------------------------+--------------------
Reporter: jgoclawski | Owner: nobody
Type: New feature | Status: new
Component: Testing framework | Version: 1.8
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 1
Easy pickings: 0 | UI/UX: 0
-----------------------------------+--------------------
Enabling HTTPS for the whole site is becoming more and more common.
Especially considering that Django uses CSRF and session cookies that may
be set as "secure". Moreover, soon Let's Encrypt will enable developers to
run HTTPS really easily. Let's hope that enabling HTTPS will become a
standard behaviour in the near future.
But with current shape of LiveServerTestCase, testing an HTTPS enabled
website is impossible. It's not even easy to extend the base class as
nearly all server-creation logic is tightly coupled in one function.
If you just wanted to test POST-ing a form, you would need to override
@CSRF_COOKIE_SECURE@ just for the test. And each override/mock is
weakining the browser test as it modifies the original environment. Not to
mention if you had your custom secure cookies. You would need to introduce
a new global settings variable, just so you can flip it in your Selenium
test and set the cookie without the "secure" flag, just for the test.
My idea is to do two things:
1. Refactor the base class, so that it can be easily extended.
2. Add LiveHTTPSServerTestCase, which runs a server thread with HTTPS
enabled.
The class can be supplied with custom certificate or can generate a
temporary one on the fly.
The question is whether we want such test case (2.) to be a part of
Django. Personally, I think that it will encourage using HTTPS and
encourage writing at least a basic Selenium test. But I can as well
release it as an app, granted the refactor (1.) will be accepted.
I will add a pull request in a minute.
--
Ticket URL: <https://code.djangoproject.com/ticket/25328>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: jgoclawski | Owner: nobody
Type: New feature | Status: new
Component: Testing framework | Version: 1.8
Keywords: | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by jgoclawski):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Old description:
New description:
Enabling HTTPS for the whole site is becoming more and more common.
Especially considering that Django uses CSRF and session cookies that may
be set as "secure". Moreover, soon Let's Encrypt will enable developers to
run HTTPS really easily. Let's hope that enabling HTTPS will become a
standard behaviour in the near future.
But with current shape of LiveServerTestCase, testing an HTTPS enabled
website is impossible. It's not even easy to extend the base class as
nearly all server-creation logic is tightly coupled in one function.
If you just wanted to test POST-ing a form, you would need to override
@CSRF_COOKIE_SECURE@ just for the test. And each override/mock is
weakining the browser test as it modifies the original environment. Not to
mention if you had your custom secure cookies. You would need to introduce
a new global settings variable, just so you can flip it in your Selenium
test and set the cookie without the "secure" flag, just for the test.
My idea is to do two things:
1. Refactor the base class, so that it can be easily extended.
2. Add LiveHTTPSServerTestCase, which runs a server thread with HTTPS
enabled.
The class can be supplied with custom certificate or can generate a
temporary one on the fly.
The question is whether we want such test case (2.) to be a part of
Django. Personally, I think that it will encourage using HTTPS and
encourage writing at least a basic Selenium test. But I can as well
release it as an app, granted the refactor (1.) will be accepted.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/25328#comment:1>
Django
Reporter: jgoclawski | Owner: nobody
Type: New feature | Status: new
Component: Testing framework | Version: 1.8
Keywords: | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Comment (by jgoclawski):
P. S.
I'm not sure of other possible use cases. Perhaps for mixed HTTPS and HTTP
configuration, we should run both HTTPS and HTTP servers. Let me know,
what you think. The base class for live server test could undergo further
refactoring to decouple server thread creation and enable even greater
customization.
--
Ticket URL: <https://code.djangoproject.com/ticket/25328#comment:2>
Django
Reporter: jgoclawski | Owner: nobody
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by MarkusH):
* needs_better_patch: 0 => 1
* version: 1.8 => master
* stage: Unreviewed => Accepted
Old description:
New description:
Enabling HTTPS for the whole site is becoming more and more common.
Especially considering that Django uses CSRF and session cookies that may
be set as "secure". Moreover, soon Let's Encrypt will enable developers to
run HTTPS really easily. Let's hope that enabling HTTPS will become a
standard behaviour in the near future.
But with current shape of `LiveServerTestCase`, testing an HTTPS enabled
website is impossible. It's not even easy to extend the base class as
nearly all server-creation logic is tightly coupled in one function.
If you just wanted to test POST-ing a form, you would need to override
`CSRF_COOKIE_SECURE` just for the test. And each override/mock is
weakining the browser test as it modifies the original environment. Not to
mention if you had your custom secure cookies. You would need to introduce
a new global settings variable, just so you can flip it in your Selenium
test and set the cookie without the "secure" flag, just for the test.
My idea is to do two things:
1. Refactor the base class, so that it can be easily extended.
2. Add `LiveHTTPSServerTestCase`, which runs a server thread with HTTPS
enabled.
The class can be supplied with custom certificate or can generate a
temporary one on the fly.
The question is whether we want such test case (2.) to be a part of
Django. Personally, I think that it will encourage using HTTPS and
encourage writing at least a basic Selenium test. But I can as well
release it as an app, granted the refactor (1.) will be accepted.
--
Comment:
The refactor sounds like a good thing / cleanup to me and looks straight
forward. Accepting on these grounds.
I'm not sure about the LiveServerTestCase. Feel free to raise that on the
developer mailing list or IRC and get other opinions on that. I tend to
put that in an external package and maybe integrate into Django if the
acceptance is there.
--
Ticket URL: <https://code.djangoproject.com/ticket/25328#comment:3>
Django
Reporter: jgoclawski | Owner: nobody
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timgraham):
[https://groups.google.com/d/topic/django-
developers/bFuPA9UGxSI/discussion django-developers thread] about HTTPS
support for `LiveServerTestCase`.
--
Ticket URL: <https://code.djangoproject.com/ticket/25328#comment:4>
Django
Reporter: jgoclawski | Owner: nobody
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Tim Graham <timograham@…>):
In [changeset:"a7901c2e090d720ef0427552387be7f14cbe2ac6" a7901c2e]:
{{{
#!CommitTicketReference repository=""
revision="a7901c2e090d720ef0427552387be7f14cbe2ac6"
Refs #25328 -- Refactored LiveServerTestCase to make it extensible.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/25328#comment:5>
Django
Reporter: jgoclawski | Owner: nobody
Type: New feature | Status: closed
Component: Testing framework | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* status: new => closed
* resolution: => wontfix
Comment:
Closing as there doesn't seem to be interest in this at this time. We can
reopen if your third-party package sees widespread adoption. Thanks!
--
Ticket URL: <https://code.djangoproject.com/ticket/25328#comment:6>