Multi token

[ehannes]

Introduces support for multiple Fortnox backends. Each Fortnox Access Token is connected to a specific Fortnox instance.You can now call different Fortnox backends with the same gem instance. For instance (where fortnox1 and fortnox2 represents key sets for different Fortnox instances):

Fortnox::API.configure do |config|
  config.client_secret = 'your-secret'
  config.token_store = { fortnox1: ['token1', 'token2'], fortnox2: ['token1', 'token2'] }
end

Fortnox::API::Repository::Customer.new( token_store: :fortnox_instance_1 )

This pull request changes a lot of stuff, both internally and public:

• Removes support for fetching Access Tokens with the gem (we can easily implement it again if we want, but for now let's leave it outside the gem until someone explicitly asks for it. No need to include features that no one uses).
• The gem is no longer configured with environment variables, but with a configuration
• Dependency to the Dotenv gem is removed.
• Fortnox::API::Base is merged with Fortnox::API::Repository::Base, the former is no longer needed.

TODO:

• [x] Update Readme
• [x] Fix support for default token store

[ehannes]

Old comment

I have not yet found a solution for how to default to :default token store when no explicit token_store is configured:

This works:

Fortnox::API.configure do |config|
  config.token_store = { default: ['token1', 'token2'], store2: ['token1', 'token2'] }
end

Fortnox::API::Repository::Customer.new # Uses token store :default
Fortnox::API::Repository::Customer.new( token_store: :store2 ) # Uses token store :store2

I have no solution for this yet:

Fortnox::API.configure do |config|
  config.access_token = ['token1', 'token2']
end

This should set Fortnox::API.config.token_store to { default: ['token1', 'token2'] }, but I have not found any working implementation for it yet.

Update

This is implemented now.

[ehannes]

@d-Pixie ready for code review :)

[ehannes]

@d-Pixie What do you say about the methods in Fortnox::API::Repository::Base? I would argue that most of them should be private/protected since they are not meant to be used from outside.

[ehannes]

@d-Pixie Time to take another look at this :)