Hey @ob-stripe this is my first stab at getting response headers out of the python bindings.

I'm trying to follow the same pattern by including a response resource to the returned API models.

However one tricky part is understanding where the best spot is to place an optional flag to include the response field on returned API resources. Each API request method contains a paramsparameter that directly maps to the API's URL parameters. Placing some kind of include_response flag here would stick out since it won't be going to the API.

Another thought was using a static variable somewhere and checking that variable within the api_requestor to include the response or not.

Do you have any opinions here?

In complex enterprise environment, different proxies may be used for communication across the many enterprise network zones, the Internet. Obviously, the HTTP_PROXY and HTTPS_PROXY environment variables are more trouble than help there.

A clean solution would be introducing API level proxy support that limits the proxy scope to just stripe communication. Everybody else would remain unaffected and could continue using either direct or own, different HTTP proxy configuration.

This pull request introduces the proxy API support described. The new proxy-example.py file demonstrates the proxy API usage.

Please consider prompt review of this pull request. Not having the proxy support will affect our project with an externally set, beyond our control hard deadline.

Happy to address any questions or concerns.

Thank you!

Summary

Currently the stripe library is not compatible with the App Engine dev server, this fixes that by disabling the ssl revoked cert check when running on the dev app server.

More detail

Google App Engine blocks access to many C modules including the socket module. It provides its own implementation but this causes a TypeError when used with the ssl C module.

This PR skips the ssl preflight check when a TypeError occurs on the App Engine server, this doesn't add much risk as the attacker would have to be in control of the connection between the user and stripe and also have a copy of the pre-heartbleed ssl private key. In any case the check can be bypassed since connections aren't reused and the check is only done once for the lifetime of an instance so an attacker would simply trigger a stripe request on the target website (buy something with a dummy card) to get the check out the way and then start the MITM attack then trigger another stripe transaction and get the secret key.

Why catch the exception rather than detect the environment?

If a fix for the underlying issue with the App Engine dev server gets released then the check will work again.

Feedback

Not sure whether it is appropriate to include a warning here? If so, what should it say?

A fairly common use case for file uploads is to upload an image to Stripe that was just uploaded to the server, or to retrieve an image from a URL, then upload it to Stripe. As it stands, the file uploader seems to expect to be given a file stored on disk, which isn't really necessary. More specifically, the file uploader wants something that has a .read method, and a .name method.

Right now, if I take a StringIO (which supports .read), then monkey-patch it to have .name="foo", this seems to upload fine, and I more or less get the thing I want. This is a bit gross, though. Ideally, we wouldn't require a file name for the file at all, since this doesn't appear to be getting used in any meaningful way. (The upload response or anything else I can find doesn't seem to make reference to the filename.)

Though it doesn't seem like uploads.stripe.com actually does anything with the file name, it does get unhappy if the parameter is omitted or left blank. As far as I can tell, if I patch stripe-python to just pass a hard-coded dummy value as the file name, this works fine. This is clearly a hack, though. In an ideal world, uploadsrv wouldn't look for a filename at all, though I don't really know if that would be a simple change or not.

Thoughts on whether this is something we'd want to support, and if so, what the cleanest way of doing this is?

Previously, if the user has not set stripe.default_http_client, a new client would be created for every request. This commit changes the APIRequestor to populate stripe.default_http_client if it had not been set by the user, so the client can be reused between requests.

r? @brandur-stripe @ob-stripe cc @stripe/api-libraries

This avoids an ImportError when loading the SSL library in a Google App Engine dev environment. For more details, see: https://code.google.com/p/googleappengine/issues/detail?id=9246

This PR is a followup from an internal ticket. I'll merge once the reporter has confirmed that this fixes the issue in his environment.

This PR implements a retry mechanism if any request would fail when using requests. It closes #464.

More detailed documentation of Retry can be found in the urllib3 documentation

• Total: The amount of total retries
• backoff_factor: it will sleep for: {backoff factor} * (2 ^ ({number of total retries} - 1)) between retries
• status: How many times to retry on bad status codes. The ones on status_forcelist
• status_forcelist: Bad status codes which it will retry on.

@brandur-stripe @ob-stripe Requests 2.14.1 just released and now requires pip >= 8.1.2 and a newish version of setuptools https://github.com/kennethreitz/requests/issues/4006

As of today, stripe-python will fail to install for users of older packaging infrastructure, including Travis. https://travis-ci.org/stripe/stripe-python/jobs/230553497#L497 https://github.com/kennethreitz/requests/pull/4007#issuecomment-300364756

We should deploy an emergency release limiting requests to version 2.13.0 and documentation should be added detailing that in the next major release there will be a minimum required version of pip.

Follows https://github.com/stripe/stripe-ruby/pull/696 and https://github.com/stripe/stripe-php/pull/549 in adding telemetry metadata to request headers.

The telemetry is disabled by default, and can be enabled like so:

stripe.enable_telemetry = True

I'd much rather call this method update, but we can't use that name because StripeObject already has an update method, and I'd rather not make this a breaking change. Note that this PR is not ready merge. There are a few resources that are going to need a custom modify method due to URL format.

I've just updated Stripe API library to the latest version and it stopped working on Google AppEngine due to fact that GAE is blocking imports of some packages such as sockets and SSL.

ERROR    2014-05-10 09:55:16,576 base.py:215] Internal Server Error: /api/billing/subscribe_to_paid_plan/stripe
    Traceback (most recent call last):
...
     File "/src/classes/billing/api_views.py", line 3, in <module>
        import stripe
      File "/src/stripe/__init__.py", line 16, in <module>
        from stripe.resource import (  # noqa
      File "/src/stripe/resource.py", line 5, in <module>
        from stripe import api_requestor, error, util
      File "/src/stripe/api_requestor.py", line 5, in <module>
        import ssl
      File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ssl.py", line 60, in <module>
        import _ssl             # if we can't import it, let the error propagate
      File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/devappserver2/python/sandbox.py", line 852, in load_module
        raise ImportError('No module named %s' % fullname)
    ImportError: No module named _ssl

Are there any chances to make it working on Google AppEngine?

I believe the old lib was just fine. It would be pity if we would be forced to use some other payment system as we like Stripe very much!

Codegen for openapi v216. cc @stripe/api-libraries

Changelog

• Remove support for resources Order and Sku
• Remove support for cancel, create, list_line_items, list, modify, reopen, retrieve, and submit methods on resource Order
• Remove support for create, delete, list, modify, and retrieve methods on resource Sku

Describe the bug

the http request client is assigned to a global variable here: https://github.com/stripe/stripe-python/blob/1ae42227d9df745420c1a3db11893589d91ba83e/stripe/api_requestor.py#L103-L105

requests client is defined here: https://github.com/stripe/stripe-python/blob/1ae42227d9df745420c1a3db11893589d91ba83e/stripe/http_client.py#L287

the Session is assigned here: https://github.com/stripe/stripe-python/blob/1ae42227d9df745420c1a3db11893589d91ba83e/stripe/http_client.py#L318-L319

this Session is never closed leading to file descriptor leak and a ResourceWarning -- the correct usage of a Session is to either utilize the with statement or explicitly .close() it

To Reproduce

the simplest reproduction I can come up with is this one liner:

$ python3  -Wonce -c $'import stripe; stripe.api_key="placeholder"; import contextlib\nwith contextlib.suppress(Exception):\n stripe.Account.list()'
sys:1: ResourceWarning: unclosed <ssl.SSLSocket fd=3, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=6, laddr=('10.0.2.15', 44434), raddr=('34.200.27.109', 443)>

the ResourceWarning there is coming from the teardown of that Session object I mentioned above -- it's an unclosed connection to the stripe api:

$ nslookup 34.200.27.109
109.27.200.34.in-addr.arpa	name = api-34-200-27-109.stripe.com.

Authoritative answers can be found from:

Expected behavior

utilization of the stripe api should not lead to ResourceWarnings

Code snippets

above

OS

any, though I'm on linux

Language version

any, though I'm using 3.10.4

Library version

4.1.0

API version

N/A

Additional context

No response

Describe the bug

Incoming webhook events have a request data attribute, but the event instance already has a request bound method, so we end up with a bit of a conflict. The data attribute can still be accessed with event["request"] but it feels weird to need to do that for just that one data attribute and then use dot syntax for everything else.

>>> event = stripe.Webhook.construct_event(...)

>>> event.request
<bound method StripeObject.request of <Event event id=<id_omitted> at 0x1035bb450> JSON: { ...

>>> event["request"]
<StripeObject id=<id_omitted> at 0x102e95810> JSON: {
  "id": "<id_omitted>",
  "idempotency_key": "<idempotency_key_omitted>"
}

event.request and event["request"] both returning different things is rather confusing, and it took me quite a while to figure out what was going on.

To Reproduce

1. Construct a webhook event.
2. Access event.request.
3. Access event["request"].
4. Notice that they are different.

I would probably consider this less of a "bug" and more of an oversight.

Expected behavior

The event.request method should probably be something like event._request so it doesn't conflict with the incoming data. That way I can call event.request and actually get the attribute from the body of the webhook as expected.

Code snippets

No response

OS

macOS

Language version

Python 3.9.10

Library version

stripe-python v2.76.0

API version

2020-08-27

Additional context

No response

Describe the bug

When trying to clear out the list of previously set blocked_categories on a cardholder, calling

stripe.issuing.Cardholder.modify(
    "ich_...",
    spending_controls={'blocked_categories': []},
    stripe_account="acct_...",
)

returns successfully but doesn't clear out the blocked_categories on the cardholder and returns a cardholder instance with the previous blocked_categories list still set.

Instead, it is necessary to replace [] with "":

stripe.issuing.Cardholder.modify(
    "ich_...",
    spending_controls={'blocked_categories': ""},
    stripe_account="acct_...",
)

and that successfully clears the list of blocked_categories—however, there is no mention of the need to make this distinction when calling stripe.issuing.Cardholder.modify or any other method in the Stripe API docs or this library's docs and setting a list to empty by setting its value to "" is not valid Python syntax.

To Reproduce

1. create a stripe connect account via:

stripe.Account.create(
    type="custom",
    country="US",
    email="[email protected]",
    requested_capabilities=["transfers", "card_payments", "card_issuing"],
)

2. complete any requested test KYB information to ensure the account is fully verified and approved
3. create a cardholder via:

stripe.issuing.Cardholder.create(
    name="Jane Doe",
    email="[email protected]",
    status="active",
    type="individual",
    billing={
        "name": "Jane Doe",
        "address": {
            "line1": "117 West St",
            "line2": None,
            "city": "New York",
            "state": "NY",
            "country": "US",
            "postal_code": "10006",
        },
    },
    spending_controls={'blocked_categories': ['floor_covering_stores']},
    stripe_account="acct_...",  # id of the account created above
)

4. attempt to update the cardholder via:

stripe.issuing.Cardholder.modify(
    "ich_...",  # id of the cardholder created above
    spending_controls={'blocked_categories': []},
    stripe_account="acct_...",  # id of the account created above
)

Expected behavior

Setting a list to [] should set that list to empty. It is not intuitive or valid Python syntax to set a list to empty by setting its value to "".

Code snippets

See code snippets in the "Describe the bug" and "To Reproduce" sections

OS

macOS

Language version

Python 3.10.2

Library version

stripe-python v2.67.0

API version

2019-10-17

Additional context

No response

Hello,

It would be great to allow users to format logs in json format instead of the hardcoded logfmt format in the library. For those looking to make this work, this is how we did it:

# strip_log_formatter.py
import datetime
import json

from pythonjsonlogger import jsonlogger


class StripeJsonLogFormatter(jsonlogger.JsonFormatter):  # pragma: no cover
    def add_fields(self, log_record, record, message_dict):
        """
        This method allows us to inject custom data into resulting log messages
        """
        for field in self._required_fields:
            log_record[field] = record.__dict__.get(field)
        log_record.update(message_dict)

        # Add timestamp and application name if not present
        if 'timestamp' not in log_record:
            now = datetime.datetime.utcnow()
            log_record['timestamp'] = now.isoformat()
        if 'application' not in log_record:
            log_record['application'] = 'myapp'

        if 'level' not in log_record:
            log_record['level'] = record.levelname

        jsonlogger.merge_record_extra(record, log_record, reserved=self._skip_fields)

Reference this class from stripe_log_formatter.py in log ini configuration file as follows:

[loggers]
keys=stripe

[handlers]
keys=stripe_file

[formatters]
keys=stripe_json

[logger_stripe]
level=INFO
handlers=stripe_file
qualname=stripe
propagate=0

[handler_stripe_file]
class=logging.handlers.WatchedFileHandler
formatter=stripe_json
args=('/var/log/myapp/stripe.json',)

[formatter_stripe_json]
class=app.stripe_log_formatter.StripeJsonLogFormatter

And then at import time, monkey patch stripe library:

# Monkey patch Stripe logfmt formatter
# Watch for this code if it ever changes, things will break:
# https://github.com/stripe/stripe-python/blob/v2.67.0/stripe/util.py#L82

old_log_fmt = stripe.util.logfmt

def new_logfmt(props):
    return OrderedDict(sorted(props.items(), key=lambda x: x[0]))

stripe.util.logfmt = new_logfmt

Any chance we can get an ability to configure our own log formatter?