Ensure request.user is available to response middleware.
#2155
Conversation
Very well explained and yes I think some forward thinking on this is worthwhile. Not able to do this comment justice right now, but there are some future horizon questions there. Eg do we consider DRF as middleware which could solve the issue, do we look at bringing some if this back into Django core etc. Those sorts of things are likely far off, but def worth opening the conversation on. Thanks! |
|
I've had this reported before multiple times on django-rest-framework-jwt. Last one with a "workaround" was this one. |
|
On further review I don't see any problem with the pull request as it stands. Anyone else? |
|
Probably we need a test case to demonstrate the change in behavior tho. |
|
We might want to consider something similar for |
|
I added a test. Let me know if this seems ok. |
|
Yeah this looks to me as is. |
| def test_logged_in_user_is_set_on_wrapped_request(self): | ||
| login(self.request, self.user) | ||
| self.assertEqual(self.wrapped_request.user, self.user) | ||
|
|
There was a problem hiding this comment.
I was actually hoping for a test demonstrating the change this has against middleware.
The test as it is here demonstrates the implementation, but doesn't make the motivation clear.
There was a problem hiding this comment.
Right, perhaps write a simple Middleware that you can unittest process_response() and demonstrate being able to access the expected user there?
|
I wrote a test using a simple Middleware. I'm not so sure about the way I did it though. I'm going to need your guidance.
|
Sounds right.
I'm not personally a huge fan of this, but I can't see an easy way to test this other than pushing the data onto the response and testing the response. |
|
I haven't tested this, so it's just a guess. But have you tried going through the middleware stack manually? middleware = MyMiddleware()
factory = RequestFactory()
request = factory.get('/', HTTP_AUTHORIZATION=auth)
response = middleware.process_request(request)
middleware.process_response(request, response)
self.assertEquals(request.user, user)
self.assertTrue(request.user.is_authenticated()) |
|
@maryokhin yeah that sounds about the right approach. |
|
The goal of this test is to document the fact that the middleware can access the authenticated user in My first instinct was to push the user onto the response and test the response in the test case, as suggested by @kevin-brown, but I think it just makes it harder to understand. |
|
I think either ways it currently works. @tomchristie you might want to take another look at this and perhaps just merge as is. Thoughts? |
Set authenticated user on wrapped request
|
Go go go. |
tomchristie
changed the title
request.user is available to response middleware.
Because of the way DRF handles authentication, middleware classes don't have access to the currently authenticated user. If we set the user on the wrapped request during authentication, middleware classes can at least access it in the
process_responsemethod.I'm not aware of all the implications of doing that, so this PR is mostly meant to start a discussion.
I use DRF in several projects and I met this issue at least twice while trying to integrate with other libraries. I realize there is a reason why the authentication is not handled in DRF as it is in django, but I think it is worth exploring possible solutions to mitigate the issues that it can cause.