2

独自の認証システム (優れたRailscastなど) を導入するか、Devise を使用するかを検討しています。

私の質問は、Devise を使用せず、Railscast のようなものを使用する場合の潜在的な落とし穴は何ですか? 私が考える必要がある彼らのセキュリティ問題は、キャストでまだカバーされていませんか? 他に考えられる落とし穴はありますか？

編集: Devise を使用しないことを考えているのはなぜですか? 私が Devise を敬遠している理由の 1 つは、Devise の失敗したログイン保護に熱心ではないからです。Devise のやり方は、メールアドレスさえ知っていれば、誰でも他人のアカウントをロックできることを意味します。そしてバランスを考えると、これらの変更を行うために Devise を完全に理解するよりも、特に自分のやり方で他のことを行う必要がある場合は、自分で開発するほうがよいと思われます。 （これは可能性が高いようです）。

4

2 に答える 2

3

基本認証 (つまり、ユーザー名とパスワードのみを使用することを意味します) の場合、独自の認証を展開しても重大な落とし穴はありません。

さて、もしあなたが望むなら：

  • ログインしたユーザーを記憶するための Cookie
  • リセット手順を記載したメールを送信して、忘れたパスワードを回復する
  • サインアップ時に電子メールの確認を要求する
  • 一定時間アクティビティのないユーザー セッションをタイムアウトにする

現在、これらを実装するのはかなり難しいでしょう。

したがって、基本的な認証システムだけが必要な場合は、独自の認証システムを喜んで使用できます. しかし、アプリの将来が心配な場合は、Devise を使用することをお勧めします。理解するのはそれほど難しいことではありません。大量の機能を提供し、後で実際に Devise を使用することを決定したときにデータを移行する必要はありません。

編集：だから、私が言ったことを繰り返します。これがペット プロジェクトであり、特定のユーザーに特定のページの閲覧のみを許可する基本的な認証システムと承認システムが必要な場合は、独自のシステムを自由に実装して、学習しながら学習してください。

ただし、これがより深刻な問題である場合、Devise を使用しない理由はないと思います。bcrypt のような強力で安全なものを使用できる (そして使用する必要がある) ときに、独自のハッシュおよび暗号化スキームを作成する人々を思い出します。

于 2013-01-05T04:00:04.017 に答える
2

少し前に同じ質問をしていました。認証に真剣に取り組み、時間を費やしたい場合は、独自のものを作成してください。しかし、アプリの機能に集中できるように、かなり標準的なものをすばやく取得したい場合は、devise をお勧めします。

ロック可能モジュールがデフォルトでオンになっているようには見えませんが、どちらの方法でも簡単に実行できます.

class User < ActiveRecord::Base
    # Include default devise modules. Others available are:
    # :token_authenticatable, :confirmable,
    # :lockable, :timeoutable and :omniauthable
    devise :database_authenticatable, :registerable,
           :recoverable, :rememberable, :trackable, :validatable
    ...
end

また、Lockable モジュールを使用した場合、ロックは認証試行の失敗回数に基づいているため、ロックをトリガーする前の最大試行回数を変更できます。config/initializers/devise.rb

Devise.setup do |config|
    ...
    # Number of authentication tries before locking an account if lock_strategy
    # is failed attempts.
    config.maximum_attempts = 20
    ...
end

https://github.com/plataformatec/devise#deviseをざっと読んでください。

于 2013-01-06T11:22:52.267 に答える