#14116 closed (fixed)
TestClient skips Csrf Middleware
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | Testing framework | Version: | 1.2 |
Severity: | Keywords: | TestClient | |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
The following code is found in TestClient
try: request = WSGIRequest(environ) # sneaky little hack so that we can easily get round # CsrfViewMiddleware. This makes life easier, and is probably # required for backwards compatibility with external tests against # admin views. request._dont_enforce_csrf_checks = True response = self.get_response(request)
While this is nice, it makes the test behave in a way that does not really verify the site works.
Some of my views are run when accessed from a desktop program, and the desktop program does not send a CSRF token, resulting in a 403 Forbidden error, but does not happen when a test is run because of the above code.
Can we get an option to turn this off?
Thanks.
Change History (4)
comment:1 by , 14 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:2 by , 14 years ago
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
Triage Stage: | Unreviewed → Accepted |
Luke - I'm going to reopen (and very soon, close again with a fix). Specifically, I think the change you suggest -- a client that *doesn't* disable CSRF protection -- is something that could be useful. I've just hit this problem writing tests for contrib.flatpages trying to fix #14156. This is a problem that is specifically about checking the way CSRF protection is handled; while it *could* be tested in other ways, a simple client request is easiest to read and understand by quite some margin.
I agree that *most* people won't need this option, but there is an edge case where it can be useful.
comment:3 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
An option to turn it off would not be very helpful. Much better would be a subclass of Client that didn't do this that you can use as needed. You can code that yourself without needing to change core Django behaviour (subclass ClientHandler and override
get_response
, subclass Client to use the new handler, subclass TestCase and override_pre_setup
addingself.client = MyClient()
).The fact of the matter is that the test client does not behave like a browser does in many other ways, and in each way it differs it is also failing to verify that your site actually works. If you want that kind of testing, you need to use something like Twill or Windmill.
Also, I'm not sure how your tests are running, but I can't see that changing this behaviour would actually make your tests more robust. If you are doing functional tests of your desktop program, you shouldn't be using the test client at all. If you are using the test client to send requests in your tests, then you are by definition not testing what your desktop app is actually sending.
Anyway, we are not intending to turn the test client into a proper browser simulator. It is intended to do basic checks of views, and for that purpose it is nicer to separate concerns and avoid the CSRF checks altogether. So I'm closing WONTFIX.
Thanks.