ユーザに改変されると困るパラメータの更新における、セキュリティ担保の方法について

Question

ある処理の状態を変える方法のベストプラクティスを教えてください。

例）
申請書類の状態を３つのステータス（{ 1:未確認, 2:確認待ち, 3:確認済み}）で管理しているとします。
それぞれ【申請テーブル】【ステータステーブル】を持ち、申請テーブルはステータスIDを外部キーとしてステータステーブルとアソシエーションしている状態です。

ルールとして、未確認→確認済みにはできず、必ず（未確認⇄確認待ち⇄確認済み）というフローで切り替えが行われます。

これらステータスを切り替える時は、申請#editでhiddenでステータスIDを送ることを考えたのですが、これだとソース上で書き換えられてしまう（1 → 3にされて未確認→確認済み等）可能性があるため、セキュリティ上よくないと思い、他の方法を考えていたのですが、なかなか思いつかず...
※editで、変更できるのはステータスIDだけです。

調べたところ、

・modelでフィルターに引っ掛けてupdate_culumなどを使い書き換える
・controllerでparamの値を加工する

などが載っていました。
他にもあるのであれば、知っておきたいので教えていただければと思います。
よろしくお願いします。

そもそも、editに

<%= form_for(@hoge, url: huga_path) do |f| %>
　<%= f.hidden_field :status_id, :value => 2 %>
　<%= f.submit "状態を変更する" %>
<% end %>

のように、「ステータス」を変えるだけの極小のformをおくこと自体ナンセンスなのでしょうか...？

ちなみに、申請の作成（create）時は、modelでafter_saveでself.ステータスIDに値がなければ、”1”を入れる。というような処理にしています。

Comments

[hoshi-takanori]

業務フローについて質問です。ステータスを変更できるユーザー（特に確認済み）の制約とかはないのでしょうか？

[Nicole_]

ご覧いただきありがとうございます！
ユーザ自体も一般ユーザと管理者とわかれており、確認待ち⇄確認済みは管理者のみ管理画面で行えるようになっています。
管理画面へのアクセス制限はできているので、一般ユーザが入ることはできません。

Answer 1

modelレベルではこちらで制御するのがデファクトスタンダードです。
https://github.com/aasm/aasm

Comments

[Nicole_]

回答ありがとうございます！
こんな便利なgemがあったとは...（他にもステート管理系のgemはあるみたいなので、機会があれば使ってみます）
今回はこちらで実装したので、ベストアンサーとさせていただきます。

追加で質問というか、なんで？ってなった部分として、追記しておきますので、よかったらこちらも確認していただけると助かります。

Answer 2

この前作った(そして、やっと先週末から稼働できるようになった)メール配信プログラムで似たような事をしました。メールについて、利用者が「新規作成」後に「申請」し、管理者が「承認」するとメールが配信されるという仕組みで、状態も「下書き」->「保留中」->「配信待ち」(ジョブに入っていて、配信されると「配信済み」になる)という感じで遷移するというものです。他にも状態(「配信失敗」とか)があって、それぞれ権限や移れる状態が異なるため、結構複雑な処理が必要でした。

そこで、アクセス管理にpunditを採用し、アクションを制限することで許可なき遷移が行われないようにしました。punditはポリシーベースのアクセス管理で、ユーザーとレコードの状態を組み合わせて、アクションに対する制限が掛けられます。状態を変更する処理はそれぞれ別アクションにしました。「申請」ボタンを押すと「申請」のアクションが呼び出され、状態が「下書き」から「保留中」に変わるという感じです。そして「承認」自体ができるかどうかをpunditでユーザー(メールの作成者かどうか)とメールの状態(「下書き」かどうか)から可否を判定するというものです。画面側でも、この可否を使って、ボタンを表示する・しないをわけています。

Hogeモデルに対して「未確認(unverified)」から「確認待ち(pending_verification)」にする「申請(apply)」を設定するのであれば、次のような感じになるでしょう。(実際に下のコードを試したわけではありませんので、詳しい使い方は各マニュアルを参考にしてください。)

config/routes.rb

Rails.application.routes.draw do
  resources :hoge do
    member do
      put'apply'
    end
  end
end

app/policies/hoge_policy.rb

class HogePolicy < ApplicationPolicy
  def apply?
    record.status.name == 'unverified'
  end
end

app/controllers/hoges_controller.rb

class HogesController < ApplicationController
  before_action :set_hoge, only: [:show, :edit, :update, :destroy, :apply, ...]

  def apply
    @hoge.update(status: Status.find_by_name('pending_verification'))
    # その他必要な処理をしていく…
  end 

  def set_hoge
    @hoge = Hoge.find(params[:id])
    authorize @hoge
  end
end

app/views/hoges/show.html.erb

<% if policy(@hoge).apply? %>
  <%= form_for(@hoge, url: apply_hoge_path(@hoge), method: :put) do |f| %>
    ...
    <%= f.submit '申請' %>
  <% end %>
<% end %>

なお、アクションを介さなかった場合、つまり、コンソールで直接モデルを操作した場合等は制限されません。punditによる制限の範囲外だからです。イレギュラーな事態が発生したとき、DB直接ではなくコンソールからモデルを操作できるようにするため、そのような制限は設けませんでした。

これがベストプラクティスなのかと言われると私にはわかりません。最初はアクションをわけない方法を考えていたのですが、punditでポリシー管理するならわけた方が書きやすいと言うことに気付いて、このようになりました。まだ、稼働して一週間ぐらいで、4月の本運用に向けて試験運用中のものですのですし、もしかしたら、大きな問題があるかも知れません。作ったものは組織内で使うWebアプリであるため、売り物として耐えられる設計なのかは不明です。

Comments

[Nicole_]

回答いただきありがとうございます！
ポリシーで管理するという方法もまたいいかなと思いましたが、
今回の解決したいことは、アカウントごとのアクション管理より、ステータス管理の方が適していると思い他の方の方法を採用させていただきました。

raccyさんがあげていただいた方法は、また別の機会に実装してみたいと思います。
ありがとうございました。