Requests made by client is not wrapping correctly `cert` parameter

[gabriel-farache]

Describe the bug

When using client with cert and verify arguments to make https requests, these arguments seems to NOT be given to request when executing the request

Expected behavior

As per https://github.com/locustio/locust/issues/468#issuecomment-608948112, the client should wrap and pass the cert arguments to requests

Actual behavior

When using client with cert and verify arguments to make https requests, I got a 401 status but when I use directly request to make the request, I get a 200 status

Steps to reproduce

This returns 401 r = self.client.post( f"https://<url>", headers={"Content-Type": "application/json"}, json=json, cert=(<path to pem cert file>, <path to key file>), verify=<path to ca pem file>) This returns 200 r = requests.post( f"https://<url>", headers={"Content-Type": "application/json"}, json=json, cert=(<path to pem cert file>, <path to key file>), verify=<path to ca pem file>)

My server is sending 401 when it receives requests not authenticated by a certificate so this behaviour is nominal.

Environment

• OS: Fedora
• Python version: 3.8
• Locust version: (please dont file issues for anything but the most recent release or prerelease builds) locust 2.8.6 (I got this version even after running pip3 install -U locust)
• Locust command line that you ran:
• Locust file contents (anonymized if necessary):

[cyberw]

That’s strange.. either run it in a debugger or try logggig the exact message sent. Maybe try https://stackoverflow.com/questions/10588644/how-can-i-see-the-entire-http-request-thats-being-sent-by-my-python-application

Maybe the difference is that Locust uses a requests.Session object and your other version is not…

[gabriel-farache]

When I add debug messages as suggested I got:

send: b'GET <url> HTTP/1.1\r\nHost:<host> \r\nUser-Agent: python-requests/2.27.1\r\nAccept-Encoding: gzip, deflate, br\r\nAccept: */*\r\nConnection: keep-alive\r\n\r\n'
reply: 'HTTP/1.1 401 Unauthorized\r\n'
header: Date: Tue, 07 Jun 2022 08:56:36 GMT
header: Content-Length: 0
401

So nothing interesting here as nothing related to he certs is showed It seems that requests version is 2.27.1 which matches the requires

[gabriel-farache]

When I print self.client.verify and self.client.cert it prints True and None, and if I try to set them manually with the my certs, it does not work either. I think the issue may come from the fact that I change the certificate between 2 tasks for the same user:

1. I have a first task with common certs that enrol to a service, then a second task is registering to this service is giving back a cert to use when requesting anything for the registered device.
2. The later task is using this cert to send the GET/POST requests and the server error is cannot use register certificate on this resource which may indicates that the new cert tuple is not correctly used and/or overriding the first cert tuple, like if it was saved somewhere.

When I remove the cert parameter from the 2nd task, it succeed but when I remove it from the 1st task, the 1st task fails with a SSL validation error; that seems to confirm that cert parameter is cached and used again for all requests and that the overriding is not occuring. And in the same spirit, if I do not do any prior request, the request that is failing is successful

Is that due to the use of HttpSession?

[gabriel-farache]

The only workaround I found is to create a new local client and use it for the requests using certs by devices self.registered_client = HttpSession( base_url=self.parent.host, request_event=self.parent.environment.events.request, user=self.parent, pool_manager=self.parent.pool_manager, )

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 10 days with no activity. This does not necessarily mean that the issue is bad, but it most likely means that nobody is willing to take the time to fix it. If you have found Locust useful, then consider contributing a fix yourself!

[Raigi]

We are experiencing the same issue as above in our project. Could this bug be reopened and fixed, please?

[cyberw]

PRs are very welcome. Probably someone experiencing the issue is in the best place to fix it, and I dont have the time to investigate.

[github-actions[bot]]

This issue was closed because it has been stalled for 10 days with no activity. This does not necessarily mean that the issue is bad, but it most likely means that nobody is willing to take the time to fix it. If you have found Locust useful, then consider contributing a fix yourself!