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

気に入った記事をブックマーク

気に入った記事を保存できます
保存した記事の一覧は、はてなブックマークで確認・編集ができます
記事を読んだ感想やメモを書き残せます
非公開でブックマークすることもできます

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

テクノロジーカテゴリーの変更を依頼記事元:

joker1007.hatenablog.com

適切な情報に変更

エントリーの編集

エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。

このページのオーナーなので以下のアクションを実行できます

タイトル、本文などの情報を
再取得することができます

コメントを非表示にできますコメント表示の設定

ブックマークしました

ここにツイート内容が記載されますhttps://b.hatena.ne.jp/URLはspanで囲んでください

Twitterで共有

次回からTwitterへ自動リダイレクト

ONにすると、次回以降このダイアログを飛ばしてTwitterに遷移します

672usersがブックマークコメント

コメントするにはログインが必要ですブックマークを追加

ブックマークを追加

よく使うタグ

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

672 users

joker1007.hatenablog.com

よく使うタグ

はてなブックマークで
関心をシェアしよう

みんなの興味と感想が集まることで
新しい発見や、深堀りがもっと楽しく

ユーザー登録

アカウントをお持ちの方はログインページへ

記事へのコメント57件

注目コメント
新着コメント

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

rails

2020/08/17リンク

その他

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

2020/08/17リンク

その他

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

2020/08/17リンク

その他

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

2020/08/17リンク

その他

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

2020/08/17リンク

その他

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

2020/08/17リンク

その他

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

2020/08/17リンク

その他

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

2020/08/17リンク

その他

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

2020/08/17リンク

その他

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

2020/08/17リンク

その他

stosto826“ フロントサイドでも明示的に必要な情報だけをくれ、とサーバーサイドに要求することは出来ます。それにはGraphQLが使えます。GraphQLではフロント側から明示的に必要な属性値を列挙してリクエストを行うため余計な情報

2025/01/30リンク

その他

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

tech全般

2023/06/10リンク

その他

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

2022/01/17リンク

その他

rodov64683Well, 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

2021/03/10リンク

その他

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

2020/11/16リンク

その他

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

2020/08/31リンク

その他

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

2020/08/25リンク

その他

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

2020/08/18リンク

その他

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

2020/08/18リンク

その他

diveintounlimitさすが熟れている…

2020/08/18リンク

その他

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

2020/08/18リンク

その他

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

2020/08/18リンク

その他

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

2020/08/18リンク

その他

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

2020/08/18リンク

その他

JullieFantastic 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

2020/08/18リンク

その他

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

2020/08/18リンク

その他

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

2020/08/18リンク

その他

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

2020/08/17リンク

その他

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

2020/08/17リンク

その他

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

2020/08/17リンク

その他

ainame良い話だった

2020/08/17リンク

その他

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

2020/08/17リンク

その他

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

2020/08/17リンク

その他

murashitいいこと書いてある

2020/08/17リンク

その他

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

2020/08/17リンク

その他

uva

2020/08/17

その他

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

2020/08/17リンク

その他

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

2020/08/17リンク

その他

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

2020/08/17リンク

その他

kinushu「余計なお節介としてエラーになったオブジェクトの情報も付けとくか、とか思ってしまうと死ぬので気は使いましょう。」ですよね…！

あとで読む

2020/08/17リンク

その他

コメントするにはログインが必要ですログインしてコメント

注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています

リンクを埋め込む

以下のコードをコピーしてサイトに埋め込むことができます

プレビュー

はてなブックマークボタンを作成して埋め込むこともできます

規約違反を報告

いまの話題をアプリでチェック！

バナー広告なし
ミュート機能あり
ダークモード搭載

アプリをダウンロード

usersに達しました！

さんが1番目にブックマークした記事「パーフェクトRails...」が注目されています。

気持ちをシェアしよう

ツイートする

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

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