Skip to content

phase-6-1.md

Latest commit

 

History

History
461 lines (270 loc) · 9.95 KB

phase-6-1.md

File metadata and controls

461 lines (270 loc) · 9.95 KB
Raw

Phase 6.1: 統合 — 自作コンポーネントでWebアプリケーションを構築する

← 前へ: Phase 5.9 | 目次 | 次へ: 最終成果物課題 →

概要

実行前に共通セットアップと各Phaseの確認手順を確認してください。演習コードはwork/で前のPhaseから引き継ぎます。

このフェーズでは、これまでのすべてのフェーズで構築してきた要素を統合し、

自分自身のWebアプリケーションスタックを完成させる

ことを目的とします。

ここまであなたは以下を個別に実装してきました：

  • HTTPサーバ（またはRack対応サーバ）
  • ルーティング
  • Controller / Action
  • View / Template
  • Middleware的な仕組み
  • ORM（Model / BaseModel）
  • バリデーション
  • Consoleモード

このフェーズでは、それらをすべて組み合わせて、

実際に動くCRUDアプリケーションを完成させます

このフェーズの目的

以下を説明できる状態になること：

  • 各レイヤーがどのように連携しているか
  • リクエストがどのように流れるか
  • 自分の実装がどの責務を担っているか
  • Railsとの構造的な違い

到達目標

  • 自作スタックで動くWebアプリを構築できる
  • CRUD機能を実装できる
  • 各レイヤーの責務を説明できる
  • 自分の設計のトレードオフを語れる

前提

  • Phase 1〜5 完了
  • すべてのコンポーネントが動作している

重要ルール

1. 既存実装をそのまま繋ぐのではなく、責務を意識して統合する

2. 問題が出たら設計に立ち返る

3. 動くだけでなく「説明できる」状態を目指す

演習課題

Step 1: アプリケーションのテーマを決める

まずは作るアプリを決めます。

条件

  • CRUDが成立すること
  • シンプルでよい（複雑にしない）

例

  • ユーザー管理
  • タスク管理
  • メモアプリ

Step 2: データ構造を設計する

課題

  • テーブル設計を行う
  • カラムを決める

問い

  • どのデータを持つべきか？
  • どこまでがModelの責務か？

Step 3: Modelを準備する

やること

  • BaseModelを継承したModelを作る
  • バリデーションを定義する

確認

  • save / find / where が使えること

Step 4: ルーティングを定義する

必須ルート

  • 一覧（index）
  • 詳細（show）
  • 新規作成（create）
  • 更新（update）
  • 削除（destroy）

問い

  • URL設計はどうするか？
  • RESTっぽくするか？

Step 5: Controllerを実装する

やること

  • 各アクションを実装

注意

  • SQLを書かない
  • Model経由で操作する

問い

  • Controllerの責務は何か？

Step 6: Viewを実装する

やること

  • 一覧画面
  • 詳細画面
  • フォーム

必須: フォームのXSS・CSRF対策

Phase 4.5の出力エスケープをフォームとDBからの再表示にも適用します。フォームの値は引用符付き属性としてエスケープし、保存した文字列をHTMLとして実行させないでください。

CSRFは、別サイトから利用者のブラウザに意図しない状態変更リクエストを送らせる攻撃です。Cookie認証ではCookieが自動送信される点が問題になります。認証のないローカルアプリも、別サイトからのリクエストでデータが変わる危険があります。ループバック待受やHTTPS、POSTに変えることだけでは防げません。

この演習では、状態変更を行うフォームにCSRFトークンを導入します。サーバ側で管理する利用者のセッションに、暗号学的に推測困難なトークンを結び付けて発行し、フォームのhiddenフィールドに埋め込みます。受信時はセッションに対応するトークンをDB更新前に検証し、欠落・不一致なら403などで拒否します。全利用者で共通の固定値を使ったり、トークンをURLやログへ出したりしないでください。セッションの識別子も推測困難なものにし、Cookieからサーバ側のセッションを参照します。

  • GETでは作成・更新・削除が起きない
  • 正しいセッションとトークンの組み合わせで作成・更新・削除できる
  • トークンなし・改ざん済み・別セッションのトークンでは、すべての状態変更ルートで拒否され、DBが変わらない
  • ブラウザのフォームから保存した<script>などの入力も、一覧・詳細・編集画面で文字列として表示される

まず一時DBとテスト用セッションで失敗テストを書き、Step 8の共通処理などに検証をまとめてください。CookieのSameSite属性やOrigin検証は追加の防御として学び、属性の設定だけで完了としません。ここで導入する最小のセッション管理・トークン検証も、本番用途の認証・認可を満たすものではありません。参照: OWASPのCSRF対策。

問い

  • Viewはどこまでロジックを持つべきか？

Step 7: リクエストの流れを確認する

課題

1つのリクエストを追跡してください：


HTTPリクエスト
→ Router
→ Controller
→ Model
→ DB
→ View
→ HTTPレスポンス

問い

  • どこで何が行われているか？

Step 8: Middleware / before_actionを活用する

やること

  • 共通処理を導入する

例：

  • ログ出力
  • 簡易認証

Step 9: エラーケースを扱う

課題

  • バリデーションエラー
  • 存在しないID
  • 不正リクエスト

問い

  • どの層で処理するべきか？

Step 10: 動作確認

以下を確認：

  • 一覧表示
  • 作成
  • 更新
  • 削除
  • エラー処理

安全上の完了条件

  • 待受先をソケット一覧で確認し、ループバックだけで動作している
  • 外部公開せず、ダミーデータだけでデモする
  • 秘密鍵がGitの追跡対象・コミット予定・配信対象に含まれていない
  • XSS・CSRF・SQLインジェクションの必須テストが統合後も通る
  • ファイル配信／一覧を実装した場合は、パストラバーサル対策のテストも通る
  • READMEに列挙した防御について、未実装の項目と影響を説明できる

これらは学習の完了条件です。本番利用・外部公開は引き続き禁止です。

Step 11: 設計を振り返る（最重要）

以下を説明できるようにしてください：

1. 各レイヤーの責務

  • Router
  • Controller
  • Model
  • View

2. データの流れ

  • 入力 → 処理 → 出力

3. 自分の設計の特徴

  • 良い点
  • 問題点

Step 12: Railsと比較する

問い

  • Railsでは何が自動化されているか？
  • 自分の実装と何が違うか？
  • なぜその違いがあるのか？

最終課題

自作Webアプリケーションのデモと解説

以下を準備してください：

1. デモ

  • CRUD操作を実演
  • 実際に動くことを確認
  • ループバックだけで起動し、画面共有または録画で見せる（公開URLは作らない）

2. 技術解説（スライド）

必ず含めること：

アーキテクチャ図


HTTP → Router → Controller → Model → DB
↓
View

各レイヤーの説明

  • 何をしているか
  • なぜ必要か

Railsとの比較

  • 同じ点
  • 違う点

学んだこと

  • 一番重要な理解
  • 意外だったこと

今後の課題

  • 足りない機能
  • 改善したい点

提出物

1. ソースコード

  • Webアプリ全体

2. スライド資料

  • 技術説明

3. 設計メモ

以下を説明：

  • システム全体の構造
  • 責務分離
  • トレードオフ

レビュー観点

  • 全体が統合されているか
  • レイヤーが分離されているか
  • 説明できるか
  • 設計に一貫性があるか
  • Railsとの比較ができているか

よくある失敗

❌ とりあえず動かす

→ 理解が浅い

❌ レイヤーが混ざる

→ 設計崩壊

❌ Controllerにロジックを書く

→ Model責務違反

❌ SQLを書く

→ ORMの意味がない

❌ Viewにロジックを書く

→ 責務違反

このフェーズの本質

このフェーズで得るべき理解は：

Webアプリケーションとは、
複数の責務が分離されたコンポーネントの協調動作である

カリキュラムの最終到達点

あなたはここまでで：

  • HTTPを理解し
  • サーバを実装し
  • フレームワークを構築し
  • ORMを作り
  • それらを統合した

これはつまり：

「Webアプリケーションをゼロから説明できる」

状態です。

最後に

この研修のゴールは「作れること」ではありません。

「なぜその構造になっているのかを説明できること」

です。

ここまで来たあなたは、

  • AIのコードを鵜呑みにしない
  • フレームワークを盲信しない
  • 自分で判断できる

エンジニアになっています。

この状態を、実務で活かしてください。

← 前へ: Phase 5.9 | 目次 | 次へ: 最終成果物課題 →