問題タブ [attr-accessible]

テーブルに含まれる一部のデータを更新しようとすると、移行に関する問題が発生します。

基本モデルは次のようになります。

ユーザー

• ユーザー名
• パスワード
• …</li>

モデルに列を追加し、既存の行を更新する最初の移行を作成しました。

2 番目の移行では、last_name 列を作成し、username 列の名前を first_name に変更することになっています。

2 回目の移行は最初の移行の数日後に作成されたため、開発では問題なく機能しました (そのため、全員が 2 回目の移行のかなり前に最初の移行を適用する十分な時間を確保できました)。

私たちが抱えている問題は、これらの移行をステージング/本番環境で次のモデルにデプロイしようとするときです。

first_name と last_name は attr_accessible に存在しますが、まだ存在しないため、最初の移行は保存時に失敗します。

検証をバイパスしようとしても、問題は解決しません。

この種の問題が発生したことがありますか? SQL を記述せずに完全な Ruby コードに固執したいので、それを回避するのを手伝ってもらえませんか?

私はRuby on Rails v3.2.2を使用しています。シンボルの配列を処理して、その値をattr_accessibleメソッドに渡し、作成する必要があります。つまり、私は持っています：

私が使用する場合：

私は以下を取得します：

ただし、取得したい：

それが作られるべきであると同様に。

どうすればそれを作ることができますか？

今日の朝、モデルで定義されていない属性のレコードをmongoidが作成していたという奇妙な問題で目覚めました。

これを克服するために、Mongoid仕様でも言及されているattr_accessibleを実装することにしました

「フィールドのリストをアクセス可能として提供することは、単にそれらを保護することの逆です。アクセス可能として定義されていないものはすべてエラーを引き起こします。」--Mongoid仕様

すべてがうまくいくと思います私はダミーのレコードを作成しますそしてまた私の驚きはその上のステートメントに反対して挿入されました

「アクセス可能として定義されていないものはすべてエラーの原因になります

ここに私のモデル構造

ここに、コンソールから作成したレコードがあります

なぜこれがそうなのか、何か考えはありますか？

ありがとう

私はRailsの初心者で、現在MichaelHartlのRails3チュートリアルを読んでいて、本当に興味がある質問があり
ます。「フェイカー」を介して管理者ユーザーと他の99人の通常のユーザーを作成するという文脈で、Hartlはなぜそうなるのかを説明します。ユーザーモデルのattr_accessibleに「：admin」を追加して、「faker」テストコードの初期化ハッシュに「admin：true」を追加することはお勧めできません。代わりに、「toggle！（：admin）」を使用し、アクセス可能な属性に「：admin」を追加しないようにする必要があると説明しています。そうしないと、悪意のあるユーザーが「PUT / users / 17？admin=1」のようなPUTリクエストを直接送信する可能性があります。 http://ruby.railstutorial.org/book/ruby-on-rails-tutorial#sec:revisiting_attr_accessible

したがって、Hartlのアドバイスに従って、私の管理ブール値は安全になりましたが、アクセス可能な属性として定義されている名前、電子メールなどの他のユーザー属性についてはどうでしょうか。これは、悪意のあるユーザーが上記のようなPUTリクエストを介してこれらの属性を簡単に変更できることを意味しますか？チュートリアルでは、Hartlは、このようなPUTリクエストフォームを発行できるcurlという名前のコマンドラインツールについて説明しています。サンプルアプリでこれを試してみたいとは思いません。質問は、何かを見落としているのか、それとも「put / users / 17？name='new_name'」などの悪意のあるPUTリクエストが発生する可能性があるのか​​ということです。

誰かが私の質問に答えてくれるなら、事前に感謝します！

encryption_keyが呼び出されattr_encryptedたときが:passphrase設定されていません。暗号化キーは、salt の sha1 ハッシュになります。パスフレーズとソルトの sha1 ハッシュにする必要があります。

ソルトは作成時に生成され、データベースに保存されます。

:passphrase暗号化キーで仮想属性を使用するにはどうすればよいですか?

助言がありますか？

簡潔にするために、一連のコードを省略しました。

前もって感謝します！

Rails 3.2では、すべての属性が本質的に「ブラックリストに登録」されていることを知っています。これにより、を介して各属性をホワイトリストに登録する必要がありますattr_accessible。

ただし、テーブルのすべての列を作成すると、attr_accessible大量割り当て攻撃に対して脆弱になりませんか？

そうでない場合は、なぜですか？

もしそうなら、ホワイトリストに登録することのポイントは何ですか？

これは本当の質問です。私の本番アプリの1つは、Deviseを機能させるためだけに、このようなものを使用する必要があるためです。

考え？

クリアランスレベルを決定するために保護されているユーザーモデルのフィールドがあります。したがって、保護されたままにして、一括割り当てできないようにする必要があります。したがって、3.2では属性がデフォルトで保護されていますが、それが実際に私が望む動作です。

ただし、1つのコントローラーメソッドでは、たとえばユーザーの作成やユーザーの更新時に、マネージャーがこのフィールドを割り当てることができるようにしたいと思います。

特定のコントローラーアクションにその属性を割り当てるにはどうすればよいですか？

たとえば、私は自分のコントローラーを持っています：

今、私がすることはclearanceから除外することですがparams[:user]、その行に到達する前でも、フィルターで除外されて発生し、例外が発生するようです（その行のdebugger直前に配置してコメントアウトしようとしましたが、それでも例外が発生しました）。

呼び出し時に保護されていない場合、保護された属性はどこでキャッチされますUser#newか？

私はゲームを作っており、Game モデルと User モデルを持っています。

Game モデルは次のようになります。

ここで、ゲームのコントローラーで Game.new を呼び出します。ロギングで確認したので、current_user と challenge_user で呼び出されていることは確かです。

残念ながら、次のエラーが表示されます。

attr_accessor ではなく attr_accessible を使用したため、これを理解していないため、割り当て可能にする必要があります。Rails、私は別の方法で何をすべきですか?

私は PragProg の (明らかに古い - 私は Rails 3.2.3 を使用しています) Rails for PHP Developersを通じて Rails を独学しています。この本では触れられていないこの種の rb ファイルを発見しました。私は多くのものに対して適切なシードエントリを構築しようとしましたが、can't mass-assign protected attributes.

一連の検索の後、私の唯一のオプションは、これらのものを開くattr_accessibleか、一括割り当てをブロックするデフォルトの機能をオフにすることです。しかし、その設定が意味するセキュリティはすべて維持したいと考えています。これらのエントリがシードされた後は編集されたくありません。これらを最初にデータベースに入れるだけです。

ここには何が表示されていませんか? 保護をオフにせずにこれらのデータをシードするにはどうすればよいですか? シードは特別なケースである必要があり、他の方法では許可されていない大量割り当てを許可するようです。

フォーラムソフトウェアを作成しています。管理者と改造者が特定のトピックを閉じることができるようにしたいと思います。

コードは、関連情報のみを表示するようにサニタイズされます。

モデル

ユーザーのスキーマ：admin列とmod列は、adminとmodを決定します。

トピックのスキーマ：閉じた列は、トピックの閉じたステータスを決定します。

悪意のあるPUT要求に対して脆弱であるため、私はトピックモデルのユーザーに消極的ですattr_accessible :closed（私が間違っている場合は私を訂正してください）。

closedRailsアプリがを使用せずにTOPICの列の値にアクセスして変更できるようにして、modattr_accessibleと管理者だけが編集できるようにする方法はありますか？