The squareconnect.configuration object can become corrupted

[GrayHatter]

Despite what the contribution guidelines say (no issues, pulls, suggestions, or requests) @tristansokol asked me to open this issue for further discussion.

Because the squareconnect.configuration is a library level global. The instance is vulnerable to becoming corrupt. A race condition exists where the access_token could be set, [changed by a different thread], and then accessed causing an error that would be very difficult for clients to track down.

The squareconnect.configuration shouldn't be a library global, shouldn't be coerced into a singleton, and (if a configuration class is really the way you want to handle setup/init), should be internal to each API, or at the very least; a variable held by an additional API wrapper that can be passed to each lower API during creation.

@tristansokol suggested that changing the access_token after setting it is a valid use case you need to support, but I'm unable to think of a use case that won't make me sad to read if I later had to maintain said code.

@robinlinden

[frojasg]

Thank you for reporting the problem. We will take a look at it!

[GrayHatter]

The easiest fix would be to write a custom setter that raises an exception if anything tries to change the access_token after it's set the first time. This also has the nice feature of not changing the API again.

The better fix would be to let the user manage the configuration state. This is slightly more complicated of an API, but it has quite a few benefits.

[frojasg]

Thank you for your follow up. I think a reasonable approach is to build a client with a configuration instance. So you can build several clients, each one with a different access_token.

[GrayHatter]

Are there any plans to change this in the next release? Or is a global singleton that clients have to work around the implementation you're planning to stick with?

[bunnyc1986]

We have a backlog task to track this issue, but we don’t have plan to change the current implementation yet.

[frojasg]

We will keep this ticket open meanwhile in case more people have this problem. I hope we can fix it soon.

[GrayHatter]

Is using squareconnect on shared hosting not supported?

[frojasg]

it's not supported in our python sdk yet.

[GrayHatter]

Might want to document that somewhere, I'm working on a application that I would have set up like a shared host environment. But that's not something I can do if users would be able to read others' access_tokens.

[drytoastman]

As a workaround, if you can do the following:

1. Comment out squareconnect/api_client.py:135 (update_params_for_auth call) so that it doesn't override things.

2. Create an ApiClient(header_name='Authorization', header_value='Bearer KEYHERE')

3. Pass the api object as the api_client parameter to any of the api class constructors.

If there was an official solution for passing the configuration to ApiClient without modifying the code that would be great. :)

[StephenJosey]

Hi all, closing this issue - please move to our new Python SDK: https://github.com/square/square-python-sdk.