Opened 9 years ago
Closed 9 years ago
#25328 closed New feature (wontfix)
Add LiveServerTestCase that runs an HTTPS server
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.
Change History (6)
comment:1 by , 9 years ago
Description: | modified (diff) |
---|
comment:2 by , 9 years ago
comment:3 by , 9 years ago
Description: | modified (diff) |
---|---|
Patch needs improvement: | set |
Triage Stage: | Unreviewed → Accepted |
Version: | 1.8 → master |
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.
comment:6 by , 9 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
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!
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.