Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork7k
Ensurerequest.user is available to response middleware.#2155
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Ensurerequest.user is available to response middleware.#2155
Uh oh!
There was an error while loading.Please reload this page.
Conversation
lovelydinosaur commentedNov 28, 2014
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 commentedNov 29, 2014
I've had this reported before multiple times on django-rest-framework-jwt. Last one with a "workaround" wasthis one. |
lovelydinosaur commentedDec 11, 2014
On further review I don't see any problem with the pull request as it stands. Anyone else? |
lovelydinosaur commentedDec 11, 2014
Probably we need a test case to demonstrate the change in behavior tho. |
lovelydinosaur commentedDec 11, 2014
We might want to consider something similar for |
martinmaillard commentedDec 11, 2014
I added a test. Let me know if this seems ok. |
jpadilla commentedDec 11, 2014
Yeah this looks to me as is. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Right, perhaps write a simple Middleware that you can unittestprocess_response() and demonstrate being able to access the expected user there?
martinmaillard commentedDec 16, 2014
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.
|
kevin-brown commentedDec 16, 2014
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. |
maryokhin commentedDec 16, 2014
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 commentedDec 16, 2014
@maryokhin yeah that sounds about the right approach. |
martinmaillard commentedDec 17, 2014
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. |
jpadilla commentedDec 17, 2014
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
lovelydinosaur commentedDec 17, 2014
Go go go. |
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.