search

PSPDFKit-labs / bypass

Bypass provides a quick way to create a custom plug that can be put in place instead of an actual HTTP server to return prebaked responses to client requests.
https://hex.pm/packages/bypass
MIT License
964 stars 111 forks source link

[WIP] TLS support #92

Closed lucacorti closed 3 years ago

lucacorti commented 4 years ago

This is a first stab at TLS support. For now, TLS support can be enabled by passing ssl: true to Bypass.open. A self-signed certificate is generated automatically at runtime, via code shamelessly stolen from phoenix mix phx.gen.cert.

I also changed Bypass.open to return {:ok, pid} since there was no way to detect startup errors and I guess this could be acceptable for a 2.0.

There are no tests yet because I'm having a hard time understanding all the workarounds around dependencies and test logic. I think some cleanup and dependecy updates are sorely needed.

@ream88 at least this is a starting point and there are no test regressions for HTTP tests.

lucacorti commented 4 years ago

@ream88 Do you have any feedback and/or interest in moving this forward?

ream88 commented 4 years ago

@lucacorti Looks awesome, and yes the test dependencies are a mess right now!

ream88 commented 4 years ago

Hey @lucacorti, I talked with @MSch and we decided to not change the API to an {:ok, bypass} tuple. Using bypass should be as easy as possible, and any errors should result in a crash during start up, instead of having the user to lift the burden of potential failure.

About the SSL/TLS support: What is intention behind this? I guess for (unit) tests it is ok to skip all the TLS hassle, and just use plain HTTP. But I'm happy to hear your opinion on this! 😊

lucacorti commented 4 years ago

@ream88 @MSch Thanks for the feedback.

On the error tuple vs crash side I have no strong opinions. I'd just note that this behaviour somewhat different to the de facto way most elixir libraries handle this (error tuples).

On the SSL thing. I started this pull request because I need to test some HTTPS only code, so if you have code relying on HTTPS support (HTTP/2, HTTP/3), like I do not having TLS support means you can't use Bypass for testing and must roll your own. Clearly we are not talking about unit testing here, but integration testing of something that needs TLS support.

If you have specific issues with adding TLS support we can address those, if you are generally against the introduction of the feature I'd like to know that and will just drop this PR and roll my own.

Nezteb commented 1 year ago

I learned about this PR from a recent blog post by @danschultzer where he talks about an alternative tool he built: https://danschultzer.com/posts/testserver-mock-third-party-services