11

attr_accessor私は、いくつかの異なる場所で、attr_accessibleおよび強力なパラメーターについて少し読んでいます。

attr_accessor と attr_accessible の違い
Rails 4 で attr_accessible はどのように使用されますか? http://edgeapi.rubyonrails.org/classes/ActionController/StrongParameters.html

そして、私は大量の割り当てを見ています:

http://code.tutsplus.com/tutorials/mass-assignment-rails-and-you--net-31695

attr_accessibleと strong のパラメータの違いがよくわかりません。私は上記の主題を完全に理解しているわけではないので、簡単なことを見落としているかもしれませんが、それらが同様の仕事をしていることは知っています.

attr_accessibleしかし、強力なパラメータとの違いは何ですか? 同じものの名前が違うだけですか？なぜ私たちは一方から他方に移動したのですか？

どんな情報でも大歓迎です。

4

2 に答える 2

19

Rails 4 では attr_accessible が非推奨になり、強力なパラメーターが採用されました。

どちらも質量割り当て問題に対する異なるアプローチですが、強力なパラメーターはより柔軟です。

たとえば、属性とを持つUserモデルがあります。ユーザーがフィールドではなくフォームから電子メールを変更できるようにしたいと考えています。email:stringis_admin:booleanis_admin

Rails 3 では、次のことを行う必要があります。

attr_accesible :email

このアプローチではis_admin、その属性が保護されているため、ユーザーが変更することはできません。

強力なパラメーターの良い点の 1 つは、コントローラーで次のことができることです。

def user_params
  if current_user.admin?
    params.require(:user).permit(:email, :is_admin)
  else
    params.require(:user).permit(:email)
  end
end

このようにして、1 人の管理者ユーザーは変更できますがis_admin、通常のユーザーは変更できません。

これは一例に過ぎず、ユーザーに管理権限を付与する最良の方法ではありませんが、非常にわかりやすい例です。

強力なパラメーターの主な利点は、それらがコントローラーで定義され、実行時に動的に割り当てられることです。attr_accessible は、属性をホワイトリストに登録するためのより静的でモノリシックな方法でした。

一方、 attr_accessor は完全に異なるものであり、Rails 4でも使用できます。たとえば、モデルに永続化またはデータベースへの書き込みが不要であるがフォームで必要な属性が1つ必要な場合などです。について考える：

attr_accessor :has_accepted_legal_terms

これは、データベースに関連しないモデルの属性、クラスまたは PORO (プレーン オールド ルビー オブジェクト) の属性を宣言するために使用できる Ruby メソッドです。

于 2015-06-11T17:08:20.313 に答える
9

強力なパラメーターとattr_accessibleは、Rails の「大量割り当て」機能にセキュリティ保護を追加する 2 つの異なる方法です。強力なパラメーターは、R​​ails の現在のバージョンで規定されている方法です。

「一括代入」は Rails の便利な省略形で、1 つのステートメントでモデルの多くのプロパティを設定できます。

たとえば@user、フォーム送信からのデータで更新したい があるとします。一括代入がなければ、次のような面倒なコードを書かなければなりません:

@user.first_name = params[:user][:first_name]
@user.last_name = params[:user][:last_name]
@user.phone_number = params[:user][:phone_number]
...
@user.save

そして、すべてのフォームフィールドで何度も。

一括代入を使用すると、そのコードはすべて 1 行になります。

@user.update(params[:user])

しかし、これにはセキュリティホールがいっぱいです。ブラウザによって送信されたデータが含まれているためparams、悪意のあるユーザーが予期しないデータをその送信に追加する可能性があります。たとえばis_admin=1、パラメータに追加できます。データベース列がある場合is_admin、一括割り当てでは、ユーザーが管理者にアップグレードされるだけです。うわぁ！

ここでストロング パラメータの出番です。ストロング パラメータを使用するActiveModel::ForbiddenAttributesErrorと、ナイーブを実行しようとするとRails が a を発生させますupdate(params[:user])。代わりに、強力なパラメーターが提供するrequireおよびヘルパーを使用して、ブラウザーの送信から期待するパラメーターを明示する必要があります。permitこのような：

def user_params
  # Note that :is_admin is not permitted!
  params.require(:user).permit(:first_name, :last_name, :phone_number)
end

...
@user.update(user_params)

Rails のメンテナーを代弁することはできませんが、Strong Parameters は柔軟なので気に入っています。ユーザー コントローラーに異なるパラメーターを必要とする複数のアクションがある場合、permit許可する必要があるパラメーターを使用して簡単に記述できます。

または、さまざまな属性を更新できるさまざまなユーザー ロールがある場合、それらの権限を簡単にモデル化できます。@CV-Gate が述べたように、実行時にこれらのアクセス許可を変更することもできます。これは強力です。

要するに、Strong Parameters の柔軟性は、そのuser_paramsメソッドをどこでも好きなように定義できるという事実によるものです。Ruby と OO の概念を最大限に活用して、思いどおりに機能させることができます。

どうattr_accessibleですか？

あまり詳細には触れませんが (この機能は Rails でサポートされなくなったため)、permitメソッドを使用する代わりattr_accessibleに、モデル自体でマクロを使用して、次のように同様のことを行います。

class User < ActiveRecord::Base
  attr_accessible :first_name, :last_name, :phone_number
  ...
end

したがって、単純なケースでは、Strong Parameters と非常によく似た動作をします。別の場所で属性のリストを定義するだけです。

ただし、attr_accessibleモデル クラスの定義と強く結びついているため、多くの柔軟性が失われます。User同じモデルに対して一括割り当てを行う必要がある 2 つの異なるコントローラー アクションがある場合はどうなるでしょうか? 今、あなたは立ち往生しています。

attr_accessor

attr_accessorマクロは Ruby に組み込まれており、Rails、一括代入、​​またはセキュリティとは何の関係もありません。たまたま名前が似ているだけです。:)

于 2015-06-11T19:28:21.990 に答える