Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

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

Merged
lovelydinosaur merged 3 commits intoencode:masterfrommartinmaillard:set-user-on-wrapped-request
Dec 17, 2014
Merged

Ensurerequest.user is available to response middleware.#2155

lovelydinosaur merged 3 commits intoencode:masterfrommartinmaillard:set-user-on-wrapped-request
Dec 17, 2014

Conversation

@martinmaillard
Copy link
Contributor

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 theprocess_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
Copy link
Contributor

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
Copy link
Contributor

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

@lovelydinosaur
Copy link
Contributor

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

@lovelydinosaur
Copy link
Contributor

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

@lovelydinosaur
Copy link
Contributor

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

@lovelydinosaurlovelydinosaur self-assigned thisDec 11, 2014
@martinmaillard
Copy link
ContributorAuthor

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

@jpadilla
Copy link
Contributor

Yeah this looks to me as is.

Copy link
Contributor

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.

Copy link
Contributor

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
Copy link
ContributorAuthor

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 intest_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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

@maryokhin yeah that sounds about the right approach.

@martinmaillard
Copy link
ContributorAuthor

The goal of this test is to document the fact that the middleware can access the authenticated user inprocess_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
Copy link
Contributor

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 added a commit that referenced this pull requestDec 17, 2014
@lovelydinosaurlovelydinosaur merged commit7fbf5b0 intoencode:masterDec 17, 2014
@lovelydinosaur
Copy link
Contributor

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

@lovelydinosaurlovelydinosaur changed the titleSet authenticated user on wrapped requestEnsurerequest.user is available to response middleware.Dec 17, 2014
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

No reviews

Assignees

@lovelydinosaurlovelydinosaur

Projects

None yet

Milestone

3.0.2 Release

Development

Successfully merging this pull request may close these issues.

5 participants

@martinmaillard@lovelydinosaur@jpadilla@kevin-brown@maryokhin

[8]ページ先頭

©2009-2025 Movatter.jp