Bonjour,
Django provides everything fedeproxy needs to process incoming requests. A middleware can be used to add an instance of the fedeproxy class to the request. A decorator can be added to the DRF view to verify the http signature is valid.
The requests package provides everything fedeproxy needs to send http requests, including adding the http signature.
Integration testing to verify both work well together can be done by running an APILiveServerTestCase. Using an APIClient would not work because it is not compatible with the requests package. For instance the requests auth argument has no equivalent in APIClient. It goes like this:
- requests.post(url, auth=fun)
- create the request with headers
- call
fun(prepared request)so that it can examine the request and modify it - send the modified http request to the
url
The django test tools (APILiveServerTestCase is based on those) are not designed to support pytest fixtures. Since the preferred method to test fedeproxy is to use fixtures, tests that depend on them can only use APIClient. As a consequence, integration tests that depend on APILiveServerTestCase cannot not rely on fixtures which significantly limit the contexts in which they can be used.
The integration tests that require a live server should be limited to code paths that can be tested with Fedeproxy mocks (for instance http signatures).
Cheers