Ensure request.user is available to response middleware.

[martinmaillard]

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_response method.

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.

[lovelydinosaur]

I think it is worth exploring possible solutions to mitigate the issues that it can cause.

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!

[jpadilla]

I've had this reported before multiple times on django-rest-framework-jwt. Last one with a "workaround" was this one.

[lovelydinosaur]

On further review I don't see any problem with the pull request as it stands. Anyone else?

[lovelydinosaur]

Probably we need a test case to demonstrate the change in behavior tho.

[lovelydinosaur]

We might want to consider something similar for .data and .files.

[martinmaillard]

I added a test. Let me know if this seems ok.

[jpadilla]

Yeah this looks to me as is.

[lovelydinosaur]

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.

[jpadilla]

Right, perhaps write a simple Middleware that you can unittest process_response() and demonstrate being able to access the expected user there?

[martinmaillard]

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.

• Where should I put the test? I put it in a separate module for now, but it should probably still be in test_request, right?
• The assertions are not in the test method, but in the middleware. This is probably not a good idea but I could not come up with another solution.

[kevin-brown]

Where should I put the test? I put it in a separate module for now, but it should probably still be in test_request, right?

Sounds right.

The assertions are not in the test method, but in the middleware. This is probably not a good idea but I could not come up with another solution.

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.

[maryokhin]

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())

[jpadilla]

@maryokhin yeah that sounds about the right approach.

[martinmaillard]

The goal of this test is to document the fact that the middleware can access the authenticated user in process_response. Your approach would be perfect if we were testing the middleware class itself, but it's not testing anything in this case.

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.

[jpadilla]

I think either ways it currently works. @tomchristie you might want to take another look at this and perhaps just merge as is. Thoughts?

[lovelydinosaur]

Go go go.
Thanks for your hard work @martinmaillard!