ฝัง
- เผยแพร่เมื่อ 20 ส.ค. 2024
- #Next.js #React #セキュリティ #プログラミング
Next.jsを本格的に使い始めてはや数年…。知らないと危険なコードを書いてしまうポイントについて3つ紹介しています。Next.jsのv13から提供されているApp RouterやReact Server Componentを中心に気をつけたい内容が詰まっているのでぜひ見てください。
🛎️ 宣伝 : 本を書きました！
「コードが動かないので帰れません!」
新人プログラマーのためのエラーが怖くなくなる本です。エラーログの読み方やデバッグの考え方、デバッガを使ったブレイクポイントの活用法を解説しています。
📖 www.amazon.co....
ぜひ購入をお願いします！！！！！！！！！！！
🧵 Zennで技術ブログも書いています、見てね！
zenn.dev/p/moo...
🦜 Twitter フォローお願いします！
むー / moobugs
zaru / zaru
👨💻 ムーザルについて
ムーザルは、むーとzaru（ざる）の現役プログラマな二人のコンビです。
技術や物作りが好きで、楽しんで開発ができるような動画を投稿しています。
チャンネル登録やグッドボタンで応援してくれると嬉しいです。
「この技術の解説動画が見たい！」などのリクエストコメントもお待ちしております！
![อยู่คนเดียวกับเขา - ส้ม มารี (Zom Marie) [Official MV]](http://i.ytimg.com/vi/gq1cWAIQDLg/mqdefault.jpg)
いつも楽しく動画を拝見しています🥰
素人なのですが教えていただけないでしょうか。いろいろと気を付けないとNextの
セキュリティは難しいということがわかりました。どうもありがとうございます😍
セキュリティを楽にできるように考えるとバックエンドを
railsやLaravelでおこなって必要なデータだけフロントに出すようにしたらなど
考えてしまったのですが、お二人はバックエンドもNextでやる
メリットや理由というのをお伺いしたいです。
コメントありがとうございます！
まず、そもそもフロントエンドとバックエンドの距離がある事自体に不満がありました。従来のRailsだけ、Laravelだけで作る形式は良かったですが、そこからReactやVueが入ってきた時に２つのアプリを作っているかのような手間を感じてしまいました。そこにフロントとバックの境界線をなくしたように感じるNext.jsは個人的にはすごく良いです。
セキュリティに関してはNext.jsが弱いという事はなく、どのフレームワークを使っていても同じような問題は起こり得ます。
なので、あとは開発体験として自分にとってしっくりくるものを選んでもいいかなと思います。
@@moozaru すぐに返信をいただいてどうもありがとうございます☺
私はLaravlerだったのですが、今までは全部Laravelでやっていました。しかしフロントを柔軟に作りたいと思い、今バックエンドはLaravelそしてフロントはReactでやっているところです。
はい。おっしゃる通り、２つのアプリを作っている感じがありますね。Authなど、認可のCROSで手間取ってしまったりしてこれが、Next.jsで全部すればこういう苦労もないのかなと動画を拝見しながら考えました。
また、２つの開発サーバーを立ち上げながら、あそこを修正しないと、ああ、こっちのVSCODEじゃなかった、という感じも煩わしいなとも思いました。
Next.jsはDBを使わないちょっとしたものしか作ったものはないのですが、今後は丸ごと全部、Next.jsでやってみようと思います。どうもありがとうございました🥰
勘違いだったらすいません…
propsから情報漏洩する対策がDTOというところ、「Server->Client間の転送層としてのDTO」という独自の設計前提でお話しされてる気がしました。
主にバックエンドの世界におけるDTOはサーバー内処理において不変なデータ転送であることを示すこと使うので、最初「あー、React Taint APIでDTOを転送禁止にする話かな？」と思ったんですが、どうもそうではなさそうでかつClientへの流出をDTOなら防げるような言い回しが、本来のDTOの意味に沿ってない気がして気になってしまいました。
ちょっとわかりにくい話しですいません。
話したかった意図は、ServerComponent内部で、DBから取得したデータをpropsなどで伝搬する際にDTOの考え方を適用したいということでした。Prismaで取得したオブジェクトをそのまま渡さず、DTOで明示的にフィールドを渡す。ServerからClientという意味では仰るとおりReact Taintが有効になりそうですね。
これは言われないと気づかなそう。
私は普段Rails(+フロント構成のSPA)しか書いてないので、ここで話された地雷は意識しないと踏みそうだなと思いました。
Nextはちゃんと触ったことないのですが、こんな面倒なんですね。非常に面白い視点での会話でした。
開発規模にもよると思いますが、そこまでのリスクを背負って利用するメリットはあるんでしょうかね。。。優秀なエンジニアさんであれば生産性は上がって良いんでしょうが。
初心者です！
Server Actions 内でセッション情報確認しなければならないということですが、それは middleware にてチェックできるのでしょうか？？
いや、厳しそうですね...
例えば Auth.js を使っている場合は、server actions 内で getServerSession とかでチェックしないといけないですよね。
そうですね物理的にはできなくもないですが、Server ActionsのEndpointを特定するのが非現実的なので関数内部でチェックする必要があります。
どんな技術も使う人の力次第。面倒になったと思う人は技術力が未熟なわけだし、便利になったという人はうまく道具を使える人ってだけ。 さもNext.jsが悪いみたいに評価しているって人は、自分の力をまず評価してみては？
髭剃ったほうがよさそう、、、
生やすならおしゃれな感じで生やしてみては
ありがとうございます。
苦手領域なのですが、がんばらないと、、