Use Solidus' preference store for API keys

[tvdeyen]

To ensure "compliance" in this gem with OWASP we could use ActiveRecord's encrypted column feature.

Ideally we would use Solidus build in preference store mechanisms that allows to omit the database completely and store the secrets in the ENV. And in order to still support the feature to add the credentials in the admin we could use the encrypted_string preference value type.

/cc @fthobe @kennyadsl

Originally posted by @tvdeyen in #127 (comment)

[fthobe]

@tvdeyen we spoke with kenny and we going to do this with urgency.

@tvdeyen I would like to have an outcome that is configurable from admin.

Can we agree to do this:

https://guides.solidus.io/advanced-solidus/model-preferences/#preferable-models

With a secure string and not return it once saved on admin?
Thomas mentioned that he doesn't see scenarios in which API keys are changed by admins.
I'd like to find a middle ground on this.

Can you propose something?

[fthobe]

@JustShah

Following was discussed with Thomas (@tvdeyen correct me if forgot something or got it wrong).

The api key is currently not conserved as a secure string.
The bare minimum is to convert the API key into a secure string,

https://guides.solidus.io/advanced-solidus/model-preferences/#preferable-models

# frozen_string_literal: true
require 'spree/preferences/persistable'
module AmazingStore
  class Greeter
    include Spree::Preferences::Persistable
+   preference :name, :string, default: "John"
  end
end

using encrypted_string instead of string.

In addition, if time allows, Thomas asked to provide to be able to provide the API key if present from the env file.

@tvdeyen this does not scale well, we can do that but let's open up a separate issue. Currently the system also considers multitenancy by allowing different api keys for different stores (as different brands might be shown on the 3rd party login page).

[tvdeyen]

@JustShah @fthobe the Payment Method admin uses so called Preference Sources. This is how it looks in the Admin

It is implemented in solidus_braintree extension

1. Config Class https://github.com/solidusio/solidus_braintree/blob/main/app/models/solidus_braintree/configuration.rb
2. Admin Form is implemented in Solidus's Payment Methods https://github.com/solidusio/solidus/blob/main/backend/app/views/spree/admin/payment_methods/_form.html.erb

[tvdeyen]

this does not scale well, we can do that but let's open up a separate issue. Currently the system also considers multitenancy by allowing different api keys for different stores (as different brands might be shown on the 3rd party login page).

Note: You can, but you must not use Preference Sources in your Store. If you like, you can still allow to enter credentials via Admin, but this gives other stores the way to still use credentials from ENV. Solidus will detect which you are using. If you do not set static preference sources it will not be available and users must enter it via Admin. The second part needs to be implemented

Example of static preferences configured in a store

# config/initializers/spree.rb
config.static_model_preferences.add(
  "SolidusBraintree::ApplePayPayment",
  "braintree_credentials",
  braintree_credentials
)

where credentials are just a Hash

braintree_credentials = {
  environment: Rails.env.production? ? "production" : "sandbox",
  merchant_id: ENV.fetch("BRAINTREE_MERCHANT_ID"),
  public_key: ENV.fetch("BRAINTREE_PUBLIC_KEY"),
  private_key: ENV.fetch("BRAINTREE_PRIVATE_KEY")
}

Configured like this it will give the Admin a select of preferences to choose from (as shown above in the screenshot)

But, as you can see in https://github.com/solidusio/solidus/blob/63d01f1c33d074e51ed71e8a35420ebe8f00a2a5/backend/app/views/spree/admin/payment_methods/_form.html.erb#L21 it will render the preference fields if there are no static preferences provided.

Best of both worlds 🎉

[kennyadsl]

@tvdeyen I think the issue @fthobe raised is that they have multiple stores on the same solidus instance, and each store needs different credentials for their login. This was the trigger for saving to the database.

[fthobe]

Yes

[tvdeyen]

They can still do that, no?

[tvdeyen]

To clarify I am not opposed to the database option, I am just saying we want to still be able to not be forced to use the database. With that proposed approach we both can achieve our goals.

[kennyadsl]

Yes, it should be doable if those credentials are tied to a store.

[fthobe]

@kennyadsl @tvdeyen given that we are all ok with DB and the amount of work to migrate 1-5 api keys, can we push this into the DB. The work of transition seems easy.

[fthobe]

Yes, it should be doable if those credentials are tied to a store.

@tvdeyen bringing this back to an env is a step back from consequent consideration of multistore environments. Is there a scenario in which you can live with asking customers to store this in DB?

I understand that stripe did it, but i have the impression we are oscillating in between embracing multistore and ignoring it. We try to always consider them, but Id like a strong vote here on what's the plan to have it ready to be promoted from contrib to core maintained in a way everybody is happy.

[tvdeyen]

I am repeating myself , but ok. Again!

The proposed usage of preferences sources serves both use cases. It does NOT force any use case to anyone (contrary to the current state of this extension).

Using preference sources allows to use ENV vars OR storing the values in the database.

That is why this is the preferred solution to this problem.

Keeping DB only is a no go for most stores. So, all I am saying is to ALSO allow ENV based configuration as Solidus already does with Payment Methods.

I hope I have made this clear.