Предоставление аргумента во время выполнения Rails

Question

Я ищу способ предоставить аргумент проекту ruby ​​on rails во время выполнения. По сути, наш проект использует криптографию с открытым ключом для шифрования некоторых конфиденциальных данных клиента, и мы хотим иметь возможность предоставить пароль для файла закрытого ключа во время выполнения.

Answer 1

Любой скрипт Ruby имеет доступ к локальным переменным среды через хеш ENV.

puts ENV['PATH']

Таким образом, с любой системой posix (Linux, Unix, Mac OS) вы можете просто установить ее при вызове скрипта, например:

MY_ARG=supersecret ruby script.rb

То же самое относится и к рельсам. Если вы поместите puts ENV['MY_ARG'] в ваш environment.rb и запустите свой сервер:

$ MY_ARG=supersecret mongrel_rails start
** Starting Mongrel listening at 0.0.0.0:3000
** Starting Rails with development environment...
supersecret
** Rails loaded.
** Loading any Rails specific GemPlugins
** Signals ready.  TERM => stop.  USR2 => restart.  INT => stop (no restart).
** Rails signals registered.  HUP => reload (without restart).  It might not work well.
** Mongrel 1.1.5 available at 0.0.0.0:3000
** Use CTRL-C to stop.

Переменная окружения, на мой взгляд, является самым простым решением.

Answer 2

Простой способ сделать это - создать плагин Rails, который принимает аргументы, используя «gets» в своем «init.rb». Позвольте мне быстро приготовить пример кода:

Создайте каталог: '$ railsRoot / vendor / plugins / startup_args / lib'

Создать объект для хранения данных аргумента в '$ railsRoot / vendor / plugins / startup_args / lib / startup_args.rb':

module StartupArgs
 @@argHash = {}

 def self.setArg(key, value)
  @@argHash[key.to_sym] = value
 end

 def self.getArg(key)
  return @@argHash[key.to_sym]
 end
end

Загрузите модуль StartupArgs в пространство имен проекта Rails и заполните его аргументами в '$ railsRoot / vendor / plugins / startup_args / init.rb':

require "startup_args"

promptString = "Enter arg name (type nothing to continue):"

puts promptString
while (newArg = gets.chomp) != ""
 puts "Enter value for '#{newArg}':"
 newVal = gets.chomp
 StartupArgs.setArg(newArg, newVal)

 puts promptString
end

Теперь во время запуска проекта Rails он будет пытаться получить пары ключ-значение из консоли. Эти пары будут сохранены в объекте глобального пространства имен StartupArgs для последующего доступа (через 'StartupArgs.getArg ()').

Если вы ожидаете, что ваш Rails-проект может быть развернут в сценариях, когда демон не будет иметь доступа к консоли во время запуска, вы можете читать из именованного канала вместо стандартного ввода консоли.

Если пойти еще дальше, вы можете удалить все части файла init.rb, кроме оператора require, и добавить действие, выполняющее эту настройку, в контроллер, который будет принимать соответствующие параметры в виде публикации через Интернет. Обязательно сконфигурируйте Rails, чтобы предотвратить ввод потенциально чувствительных параметров (например, паролей) в доступ к файлам журналов при регистрации или ошибках (особенно, если он может использоваться как HTTP GET с параметрами в URL).

(Вы получаете тот же эффект, что и в описанной выше системе, если вы настраиваете другие действия Rails на игнорирование запросов до тех пор, пока действие установки не сохранит соответствующие параметры для глобального объекта.)

Примечание для Мики: у меня нет репутации, чтобы комментировать непосредственно ваше сообщение, поэтому я включу свой комментарий здесь. Может быть несколько причин рассмотреть систему, которая никогда не требует, чтобы пароль был представлен в файловой системе. Например, разработчик может планировать проект Rails, который может быть развернут в различных операционных системах и в различных средах. Если разработчик решает, что могут быть сценарии, в которых администратор или пользователь root может быть скомпрометирован, ему нельзя доверять или его нельзя попросить подписать соглашения о конфиденциальности и безопасности, разработчик может решить добавить дополнительную маскировку размещения пароля в памяти только (в интересах требования немного менее безопасной системы или чуть более умной атаки для кражи пароля). Возможно, это можно рассматривать как вопрос относительных затрат: при низких затратах пароль может быть скрыт таким образом, что для его извлечения требуются более дорогие знания.

Answer 3

Что плохого в том, чтобы поместить пароль в файл, который chmod-файл доступен для чтения только пользователю веб-сервера?