In some cases there can be a method that's detected with
`method_defined?`, but which cannot be removed with `remove_method`,
even though it's on the same class. The only case so far that we've
noticed this is when a class is reopened for monkey patching like in
issue #749.
We'll still try to discourage this sort of use, but here we swallow the
error and issue a warning so at least the program doesn't crash.
Fixes#749.
In #741 I tried to do something too clever by replacing instances of
`Faraday::UploadIO` found in parameters with a human-readable string to
improve `STRIPE_LOG` logging output.
I thought I'd tested it at the time, but apparently not (or not well
enough), and this change caused the regression detailed in #742.
My findings about how Faraday encodes multipart were apparently wrong
and it does use these parameters, so here we remove the step where we
try to nicen them for logging. The logs look a little worse, but it's
not that big of a deal.
I've tested this patch against the API and confirmed that it addresses
the problem.
Fixes#742.
Makes a few tweaks to hopefully simplify clarity things:
* `FaradayStripeEncoder` now becomes the way to encode all of form,
multipart form, and query parameters.
* Introduce a cache in it so that we don't have to encode everything
twice (once for logging, and once for the request body).
* Try to sanitize logging a bit by replacing `Faraday::UploadIO`s found
in incoming parameters with a string representation of the file (note
that all other styles of file input like `File` or `Tempfile` have
been converted to `Faraday::UploadIO` by the time they reach the
encoder).
As reported in #608, integer-indexed maps currently work when passed as
part of the body, but they are reverted to non-indexed maps when passed
in the query.
It turns out that we actually had two problems:
1. We weren't calling our `Util.encode_parameters` on our query
parameters anywhere, and it's this method will does the integer
encoding.
2. Even when I fixed (1) by calling `Util.encode_parameters`, Faraday
would still strip the integer indexes as they were transformed in
its default `NestedParamsEncoder`.
Here we fix both issues by calling `Util.encode_parameters` and sending
Faraday a custom encoder which bypasses its normal shenanigans.
Unfortunately, this has turned out to be somewhat difficult to test
because the integer-indexed maps also seem to confuse Webmock, which
strips them down to standard maps (I even tried testing against a
string, and it still got it wrong). I did use stripe-mock though to
verify that we are now sending the right payload.
Fixes#608.
A tiny tweak to add the port chosen by stripe-mock to the "starting
stripe-mock" output. This gives the user a little more information
(which might be handy if something isn't working), and brings it inline
with Go's output format: https://github.com/stripe/stripe-go/pull/780
When starting a stripe-mock for a custom OpenAPI spec, pass `-http-port
0` on startup, which tells stripe-mock to select a port, then extract
that port from its output.
This is not a total win because we now have to rely on string matching,
but it is better in that (1) it gets a port more efficiently, (2) it
eliminates a race condition where another process could take the port we
found before stripe-mock gets to start, and (3) it starts a little
faster as we take advantage of the fact that we know stripe-mock has
started when we've found a port in its output (in my tests it took ~0.2
to 0.3 seconds compared to a 1 second sleep).
Connect with Express accounts uses a slightly different version of the
OAuth authorize URL [1] in that it's prefixed with `/express`.
Here we add a new option to `Stripe::OAuth.authorize_url` which allows
`express: true` to be passed in to generate the Express variant.
Note that the token endpoint has no equivalent so we don't need the
option there.
Fixes#717.
[1] https://stripe.com/docs/connect/oauth-reference#express-account-differences
