Open snorfalorpagus opened 6 years ago
So I've had an attempt in the past at doing cookies but it leads down a deeper rabbit hole.
The problem with cookies is that requests-mock doesn't imply and order on the way responses are returned. Figuring out that cookies should be maintained across requests was more difficult than i would have expected and so it just never got completed. See #17 for that.
Regarding simply exposing auth and cookies on the requests - sure, i'd be happy to include that. In general I try to follow the naming scheme that requests follows and a requests.Request
has an auth
and cookie
parameter that we could replicate. Adding it to the _RequestObjectProxy
would make it available in the matcher and in the history.
What do you think we return there?
For auth having simply basic auth excludes tokens and other options, but is it better to be explicit like a basic_auth
property or maintain the requests pattern? For cookies do we go the effort of a full CookieJar?
Also, if we add them there do we need them as a regular matcher, eg:
m.get(url, auth=("user", "password"), text="response", status_code=200)
We can go into details, but yes, i'd be happy to have those accessors.
Hi, Jamie. This seems like an interesting challenge. It seems like we are still interested in this on some level even though this conversation has gone stale. I am curious as to what the expectation here is. There should be a line drawn between creating a mock and creating a fully interactive web service. I realize there is a lot of gray area between these two. With that said, I think the focus should be the following (not carrying a live cookie jar throughout an long use case):
Am I understanding the scope? If the interaction needs to be more complex, then returns should be defined in between steps. I think the biggest part is to add cookie matching as part of the criteria.
Hey - so i'll warn up front this is more difficult than I expected. There are a number of cookie handling libraries, but they're not designed to make it easy to extract cookies in a nice way. The other reason this kind of lost momentum is:
So on the fully interactive web service - I completely agree, and one of the things that requests-mock has never guaranteed is ordering. You can hit any mock in any order and so long as it matches you get a response. There was some problems here with cookies that was a problem that I can't quite remember without diving in but are around the long-lived case you mention.
From a UX perspective, i generally try and match parameters to what requests itself provides, which in this case would be: https://requests.readthedocs.io/en/master/user/quickstart/#cookies, though we need to distinguish here on are you trying to match this cookie in a request or are you trying to return this cookie in a response. There's precedence for this in headers though where headers={}
are headers returned on a response, and request_headers={}
are headers that must be matched to trigger the response.
So from your list:
Is there an easy way to access cookies and authentication in a mock request callback?
I want to do something like this:
I wrote a couple of basic helper functions for this:
Does this functionality exist already somewhere? If not, is there interest in including it (with some tests) in requests-mock?