2

レールのsimple_form宝石で：

フォームを= f.input :password, :required => true送信するたびにエラーが含まれていると、ページのリロード時にパスワードの入力が失われます。私が= f.input :password, :required => true, :as => :textそれを使用すると、すべてが期待どおりに機能するため、明らかにパスワード フィールドの処理が異なります。

パスワードフィールドの値を覚えるには?

編集: 一部の人々は、以前に入力された値で同じフォームを再表示することについて話していることを理解していないようです. この質問はデータベースとは関係ありません。実際、そのシナリオではデータベースに何も保存されません。PHP の人にとっては、これは<input name="pass" type="password" value="<?= $_POST['pass']; ?>">

4

3 に答える 3

6

質問について、答えは使用することですinput_html: { value: @user_password }

このような：

<%= f.input :password, :required => true, input_html: { value: @user_password } %>
<%= f.input :password_confirmation, :required => true, input_html: { value: @user_password } %>

パスワード値の復元に関する 2 番目のトピックについては、調査の結果、実際にはセキュリティ バンプのようなものであることがわかりました。本当のセキュリティは、HTTPS を使用するか、クライアント側で javascript を使用してパスワード ハッシュを実行し、サーバーがパスワードを認識しないようにすることによって行われます。

たとえば、https://github.com/joinのような大きな Web サイトでさえ、私のやり方と同じように動作しているようです (パスワードを入力しますが、無効な電子メールを入力すると、パスワードがプレーンな HTMLvalue要素として入力されます)。

対応するルートとコントローラーは次のようになります。

routes.rb :

devise_for :users, :controllers => {registrations: 'users/registrations' }

registrations_controller.rb :

class Users::RegistrationsController < Devise::RegistrationsController
  # build_resource is called inside the new and create methods
  def build_resource(*args)
    if params[:user]
      # So that the password isn't blanked out when the other validations fail. User shouldn't have to retype the password.
      @user_password = params[:user][:password]
    end
    super
  end
end
于 2013-11-04T12:31:55.827 に答える
2

Railsがこれをどのように処理するか正確にはわかりませんが、これをPHPなどで手動で記述した場合、入力されたフォームデータをフォームに戻すには、検証エラーの後にデータをレンダリングして各入力に戻す必要があります値属性。

パスワード入力でそれを行うことを技術的に妨げるものは何もありませんが、それは、プレーンテキストで自分のパスワードを彼らに返さなければならないことを意味します. これは、パスワードが傍受される別の機会を提供するため、契約を破るものだと思います.

この件について読んだ後、多くの人が、これは明らかに悪いプレーンテキストでパスワードを「保存」する形式でもあると考えているようです。ただし、サーバーがプレーンテキストのパスワードをどこにも保存する必要がないことは明らかであるため、パスワードを「保存」すると見なされる理由はまったく明確ではありません。最初の場所。ただし、パスワードが HTTP 応答に格納されていることを意味している可能性があります。これは、基本的に、上記で提起したのと同じ懸念事項です。

私が見たもう 1 つの理由は、パスワード入力にパスワードを挿入するには、value 属性を使用する必要があることです。これにより、レンダリングされた入力でパスワードがわかりにくくなりますが、Firebug などを使用してソースを検査すると、パスワードが表示されます。私にとって、これは問題ではありません。なぜなら、入力のタイプをパスワードからテキストに変えて、とにかくパスワードを明らかにするか、単に JS を使用するのは簡単だからです。パスワード フィールドが、パスワードを視覚的に不明瞭にするだけでなく、多くの組み込みセキュリティを提供すると考えるのは、まったく正しくありません。

あなたができることは次のとおりです。

  1. パスワードをハッシュし（それ自体が検証に合格すると仮定）、残りのデータが検証に失敗した場合でもそれを保存します
  2. 返されたフォームのパスワード フィールドを無効にするか、送信したパスワードは受け入れられたが、残りのフォーム データを修正する必要があることをユーザーに示します。
  3. オプションで、ユーザーが別のパスワードが必要であると判断した場合に、パスワード フィールドを再アクティブ化する方法を提供します。
  4. ユーザーがなんらかの理由でサインアップを続行せずにフォームを送信してエラーが発生した場合に、孤立したパスワード エントリをデータベースから定期的に削除する cron タスクを実行します。

それがどのようにセキュリティを危険にさらすか、すぐにはわかりません。

もう 1 つの方法は、複数ステップのフォームを用意し、最後のステップでパスワードとパスワード確認の入力を独自に行うことです。そうすれば、ユーザーがパスワード段階に到達するまでに残りのデータが有効であることを確認でき、パスワードにエラーがある場合 (たとえば、パスワードとパスワードの確認が一致しない場合) は、それが有効であると主張できます。ユーザーはパスワードが隠されていると問題を簡単に修正できないため、両方のフィールドを空白にするのが妥当です。

于 2013-10-28T10:44:19.063 に答える