Opened 9 years ago
Last modified 9 years ago
#25328 closed New feature
Add LiveServerTestCase that runs an HTTPS server — at Version 1
Reported by: | jgoclawski | Owned by: | nobody |
---|---|---|---|
Component: | Testing framework | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
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:
- Refactor the base class, so that it can be easily extended.
- 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.