Desired Behavior
Use the rails credentials mechanism (https://web-crunch.com/posts/the-complete-guide-to-ruby-on-rails-encrypted-credentials) to load credentials by default (maybe secondary to env variables), and encourage configuration via rails credentials:edit [--environment=ENV].
Something like:
paypal:
client_id: XX
client_secret: YYYY
This also eases putting in separate credentials for development and production.
(Optional) Current Behavior
As a developer inexperienced in Ruby on Rails, I did not know how to securly store my credentials, so they ended up in the commit history.
This case can quickly happen when following the current README instructions.
Workaround
This is what I do now, after arduously pruning my commit history and having learned the proper way:
'paypal_commerce_platform_credentials', {
test_mode: !Rails.env.production?,
client_id: ENV['PAYPAL_CLIENT_ID'] || Rails.application.credentials.dig(:paypal, :client_id),
client_secret: ENV['PAYPAL_CLIENT_SECRET'] || Rails.application.credentials.dig(:paypal, :client_secret),
Desired Behavior
Use the rails credentials mechanism (https://web-crunch.com/posts/the-complete-guide-to-ruby-on-rails-encrypted-credentials) to load credentials by default (maybe secondary to env variables), and encourage configuration via
rails credentials:edit [--environment=ENV].Something like:
This also eases putting in separate credentials for development and production.
(Optional) Current Behavior
As a developer inexperienced in Ruby on Rails, I did not know how to securly store my credentials, so they ended up in the commit history.
This case can quickly happen when following the current README instructions.
Workaround
This is what I do now, after arduously pruning my commit history and having learned the proper way: