search

sparkapi / spark_api

Ruby client library for communication with the Spark API
http://sparkplatform.com/docs/overview/api
Other
55 stars 35 forks source link

Using Multiple User Accounts with spark gem #67

Closed david-harkness closed 7 years ago

david-harkness commented 11 years ago

We are developing an app using your gem (version 1.3.10). The flow is that users will authenticate via oauth against the spart platform. Which yields us a user token. However we're confused about how to allow many user accounts to work simultaneously.

As far as I understand your gem does not allow to handle multiple concurrent requests using different user accounts. This is because of static implementation of connection (https://github.com/sparkapi/spark_api/blob/master/lib/spark_api.rb#L34) that is used from models (https://github.com/sparkapi/spark_api/blob/master/lib/spark_api/models/base.rb#L48)

Am I correct? If so do you have any suggestions or future plans to implement this?

wlmcewen commented 11 years ago

Hi David,

The authentication implementation in this gem is pretty basic but extendable, and we extend this gem in house for all rails specific logic. None of this has been open sourced as it hasn't been made things generic enough for public use. All of our applications run with concurrent requests disabled, so we have not dedicated effort to ensure that threading works for your use case. However, I don't believe it makes concurrency impossible, and could be handled at another level with the right extension.

All requests go through a class that is responsible for loading user sessions (https://github.com/sparkapi/spark_api/blob/master/lib/spark_api/authentication/oauth2.rb#L28). With the right session provider implementation, I believe user state could be maintained across concurrent requests. The default provider is very lightweight, and stores session info in local memory (https://github.com/sparkapi/spark_api/blob/master/lib/spark_api/authentication/oauth2_impl/simple_provider.rb). Our internal implementation stores the session in memcached across all our applications, but as I mentioned, it deals with concurrency at the process level.

If we do migrate to concurrent threads in our infrastructure, we'll need to addess this problem. However, we don't have plans to do so in the near future. We do accept pull requests if you're interested in pursuing this in the meantime.

To aid us in future discussions, may I ask what ruby environment you are using and are you using rails or some other web stack?

bhornseth commented 7 years ago

Closing stale issue