管理者画面とコントローラーの関係

Question

閲覧ありがとうございます。
一度もwebを作ったり、運用したことがない新参者ですが、よろしくお願いいたします。

一般ユーザーは閲覧のみで、管理者だけがデータの新規作成、編集、削除出来る場合、destroyやnewといったコントローラーの作成は不要なのですか？

疑問点

以前は、CRUDに必要なすべてのアクションをコントローラーに記載し、かつ管理者だけが登録、編集、削除出来るようにbefore_actionでフィルターかけてアクセスを制限させればいいのかな？と思っていたのですが、管理者画面がどういうものか分からなかったので、rails_adminというgemを触ってみました。

管理者画面からデータを登録することが出来るのですが、直接SQLを発行しているみたいで、コントローラー無しでもDBにデーターを入れることが出来ます。

そのためコントローラーには、閲覧のアクションだけでいいのでは？という疑問が生じ質問させていただきました。

また、管理者のアクションは、管理者画面から出来るので、コントローラーは一般ユーザーの取扱にのみ集中出来るといったメリットがあるような気がするのですが。

セキュリティの観点から、相応しく無いのですか？

よろしくお願いいたします！

Answer 1

コントローラー無しでもDBにデーターを入れることが出来ます。

コントローラーが無いのではなく，rails_admin のコントローラーによってデータの編集がされるのでしょう（rails_admin は私は実は知りませんが）

destroyやnewといったコントローラーの作成は不要なのですか？

正確には

destroyやnewといったアクションの作成は不要なのですか？

でしょうね。
つまり，PartyKids さんがおつくりになっているコントローラーに destroy や new といったアクションが必要か，ということですが，不要です。

コントローラーに既にそういうメソッドが書いてあるなら，削除します。
そして，ルーティング定義からも除きます。

例えば，Item というモデルについて，一般ユーザーは index と show だけが許されるとすると，ItemsController には，アクションに対応したメソッドとしては index メソッドと show メソッドだけを置きます。
そして，routes.rb では，

resources :items, only: %i[index show]

とします。

Comments

[PartyKids]

回答ありがとうございます！

指摘して頂きありがとうございます！
コントローラーではなく、アクションですね。

>アクションが必要か，ということですが，不要です。
つまり管理画面を使うならば、コントローラーは一般ユーザーのアクションだけを意識して書けば良いということですか？
そのコントローラーの中で、ログインしている人とログインしていない人のアクションの違いに注目してコードを書けばよいという事ですか？

>ルーティング定義からも除きます。
アクションを削除することは思いついたのですが、ルーティングの制限までは思いつかなかったです。ありがとうございます！

[scivola]

> つまり管理画面を使うならば、コントローラーは一般ユーザーのアクションだけを意識して書けば良いということですか？
> そのコントローラーの中で、ログインしている人とログインしていない人のアクションの違いに注目してコードを書けばよいという事ですか？

そういう理解でいいと思います。
その「コントローラー」というのは PartyKids さんがあらわに書くコントローラーを指しているのですよね？

[PartyKids]

回答ありがとうございます！

>あらわに書くコントローラーを指しているのですよね？
そうです！
そういう事だったんですね。
管理者画面を使えば、CUDアクションをコントローラーに書かなくても出来、さらに管理者専用のアクセスフィルターも管理者ページにだけおけば良いと言う事になるんですね！

回答、本当にありがとうございました！