Направляющие, OAuth и защита CSRF

Я соглашаюсь с несколькими из ответов: не регистрируйтесь в коде, который не скомпилирует; используйте персональное ответвление или репозиторий, если Ваше беспокойство имеет "резервное копирование" кода или его изменений; регистрация, когда логические единицы завершены.

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

Что касается регистрации после каждого исправления ошибки: если фиксация не тривиальна, абсолютно! Ничто не больше боли, чем нахождение, что одна регистрация содержавших трех фиксирует, и один из них должен откатываться. Как правило, кажется, что в той ситуации разработчик исправил три ошибки в одной области и раскручивании, какое изменение идет, к которому исправление ошибки является кошмаром.

5
задан Mirko Froehlich 4 December 2009 в 06:44
поделиться

1 ответ

Я отвечу на свой вопрос. :)

Я добавил следующий метод к нашим расширениям контроллера OAuth. Единственное, что это добавляет к реализации по умолчанию, - это проверка oauth? . Кажется, это помогает и кажется довольно чистым решением.

def verify_authenticity_token
  verified_request? || oauth? || raise(ActionController::InvalidAuthenticityToken)      
end
5
ответ дан 14 December 2019 в 19:16
поделиться
Другие вопросы по тегам:

Похожие вопросы: