パーフェクトRails著者が解説するdeviseの現代的なユーザー認証のモデル構成について - joker1007’s diary

最近、パーフェクトRuby on Railsの増補改訂版をリリースさせていただいた身なので、久しぶりにRailsについて書いてみようと思う。 まあ、書籍の宣伝みたいなものです。 数日前に、noteというサービスでWebフロント側に投稿者のIPアドレスが露出するという漏洩事故が起きました。これがどれぐらい問題かは一旦置いておいて、何故こういうことになるのか、そしてRailsでよく使われるdeviseという認証機構作成ライブラリのより良い使い方について話をしていきます。 (noteがRailsを使っているか、ここで話をするdeviseを採用しているかは定かではないので、ここから先の話はその事故とは直接関係ありません。Railsだったとしても恐らく使ってないか変な使い方してると思うんですが、理由は後述) 何故こんなことが起きるのか そもそも、フロント側に何故IPアドレスを送ってんだ、という話です

[t-wada]

暗黙のJSON変換を使わず明示的なシリアライザを使う（JSONもViewなので当然）。テーブルを分け、リソースも分ける。安易に簡単さに流されず、それでも手数はそこまで増やさない達人のアプローチ

[koyancya]

やりたくなるこれｗ->“固定でエラーメッセージを返すエラーハンドラとかなら問題無いと思いますが、余計なお節介としてエラーになったオブジェクトの情報も付けとくか、とか思ってしまうと死ぬので気は使いましょう

[takahashim]

“Railsは良くも悪くもRDBと密結合したフレームワークなので、まずテーブル構成からしっかりやっておけば、それなりに安全性が上がります”

[yojik]

自分はサーバで全てHTMLにレンダリングしてる時代はDTO(的なもの)に懐疑的だったが、WebAPIで何か返すときは出力用モデルへの変換は必須だと考えます。暗黙的に秘匿情報自動フィルタリングに至っては逆に危険な気がする

[june29]

「モデルを分けましょう」は大賛成。サンプルコードが添えてあってさすがパーフェクト先輩です。

[HolyGrail]

deviseを利用するしないに関わらずめちゃくちゃためになるエントリだった

[takc923]

deviseの防衛策が入る前のバージョン使ってIPアドレスがアレした可能性あるんじゃないかと思って見てみたけどcommitされたの2012年だしnoteのサービス始まったの2014年だったから関係ないわ

[stealthinu]

ユーザ認証のテーブル自体を認証方式ごとに作ってUserテーブル直にそのサービスごとの情報を持つべきではないという設計方針。なるほど。

[iga_k]

コードが添えてあるのでさすがjokerさん

[tmtms]

“Railsがどういうフレームワークとして成り立ってきたかということと現代的なWebアプリケーションの実装におけるモデル構造とが乖離してきており、現代的なモデル構成が取れていないという点に問題の根幹がある”

[ryosuke-fujii]

「Userというとにかく肥大化しがちで絶対に失ってはいけないレコードに、一時的な要求でしか使わない情報を持たせるのはほとんどの場合で悪手でしょう。」

[Nilfs]

ユーザー認証のモデル構成を開設している。用途別にそれぞれ分解していくのは良いかもしれない

[priyasrm964]

I am Sohana Verma. I stay in Dehradun. I love to play and I am very energetic with an amazing personality. I never rush and like to enjoy with hot men who are full of lust and need a wild and horny companion for an erotic experience. https://dehradunescortservice.in/

[rodov64683]

Well, this got me thinking what other workouts are good for those of us. https://www.shwetachopra.com/ https://www.alinachopra.com/delhi-escorts-whatsapp-photo.html

[YassLab]

“サーバーサイドという自分達の環境に情報を閉じ込めておけないので、サーバーサイドでデータを取り扱うのに比べて、何を持つべきで何を持つべきでないのかを遥かにセンシティブに考える必要があります。”

[griefworker]

Userモデルを分割するアプローチ。

[juve534]

認証周りは最初に作るし、心理的にリファクタリングしづらい

[hiromichinomata]

Railsエンジニアはそういうものと諦めてるけどDjangoやASP.NETは組み込みのユーザー認証あるしフレームワークがちゃんとユーザーモデルサポートしてもいいと思う

[ota42y]

この認証ごとにbelongs_toするやつ、私も最近実践してるけどめっちゃおすすめ⊂(・8・)⊃ (超わかりやすく説明していてさすが)

[diveintounlimit]

さすが熟れている…

[rryu]

このクレデンシャルなどの非公開情報を別テーブルにする方式はRails3の頃から出ていた気がするのだが、一般的になっていないのは非公開情報だと把握できていればそこまでする必要はないということなのかもしれない。

[daira4000]

モデルの分け方参考になる

[luccafort]

Deviseは責務てんこ盛りなのでちゃんと綺麗に責務を分割するだけでこうなるんだよ！というお手本のようなコードで勉強になった。

[nilab]

パーフェクトRails著者が解説するdeviseの現代的なユーザー認証のモデル構成について - joker1007’s diary

[Jullie]

Fantastic post however I was wondering if you could write a little more on this topic? I’d be very grateful if you could elaborate a little bit further. Many thanks! http://bit.ly/39bkvC0 https://www.dehradunescortsservices.com

[tkmkg8m]

センシティブな情報と常に必要というわけじゃない情報はテーブルからわけといたほうが安全よね。あと暗黙的な処理はやっぱりバグや脆弱性の温床なのでなるべくなくしたいところ。

[ravelll]

“Railsは良くも悪くもRDBと密結合したフレームワークなので、まずテーブル構成からしっかりやっておけば、それなりに安全性が上がります。”

[fashi]

「登録途中という状態をUserモデルに持たせない」「これらのレコードは用事が終わった時点で完全に削除することができます」「テーブルごと作り直しても致命的な問題になり辛くなります」

[irasally]

肥大化を防ぐのにテーブルを分ける、なるほど。devise便利なんだけど扱いきれない時があるのでとてもためになる。

[ritou]

Qiitaを見てると初学者はUserテーブルにどんどん追加していき、null許可されてなくてランダムな値で茶を濁したりするのでもっと言語やフレームワークを越えたレイヤーで知見を集める必要がある。

[ainame]

良い話だった

[katsyoshi]

べんり〜

[sho]

DBを分けろというのは良いプラクティス

[efcl]

DBから取得したモデルデータをそのままJSONとしし返してしまう問題の対策について。許可リスト方式によるレスポンスの定義、取得側のクエリでの最小限の取得について。 DBテーブルで分けておく工夫について、Userテーブ

[murashit]

いいこと書いてある

[Magicant]

この説得力 > Userというとにかく肥大化しがちで絶対に失ってはいけないレコードに、一時的な要求でしか使わない情報を持たせるのはほとんどの場合で悪手でしょう

[tohokuaiki]

結構なAPIで「JSONドバー」でやばい情報入っちゃってるのあると思ってる。見つからないだけで。

[y_hirano]

Railsを仕事で触り始めたけど、なんとなく前時代だなーという感じはしていた。なるほど、この辺がそう思わせる理由だったのか…。かといって、他のフレームワークならマシ、ってこともなさそうなのよね。

[tettekete37564]

認証部分なの？単にポストされた投稿データを受け取ったときのログ情報じゃね？フロントに投げてしまってもフロントが何か処理しないと埋め込まれない(覗き見はできるが)と思うのだがダンプでもしてたのけ？