技術評論社
なぜ、あなたはWebシステムを開発できないのか
Webアプリ関連の仕事ではないが、タイトルに惹かれてちょっと読んでみました。Webアプリケーションの仕組みを知るための入門書。6章までは技術入門といっても技術の歴史や概要についてがほとんど。6章以降でWebアプリ開発関連の技術が出てくる。
【amazonで購入】
【楽天ブックスで購入】
【DMM.comで購入】
目次
- はじめに
- プロローグ
- 市民権を得た「Webアプリケーション」
- 「Webアプリケーション」開発の難しさ
- 「Webアプリケーション」の開発技術はどこで学べる？
- なぜ、あなたはWebアプリケーション開発技術を学べないのか
- 本書の対象読者
- 本書を読む上での想定知識
- 最も効率良く「技術」を学ぶ方法
- 「Webアプリケーション」とは何か
- デスクトップアプリケーション
- Webアプリケーション
- まとめ
- Webはどのように発展したか
- WWWの誕生と普及
- 世界中のコンピュータを結ぶインターネット
- インターネット普及の立役者・World-Wide WebとMosaic
- WWWの誕生
- 現代Webブラウザの祖先・NCSA Mosaic
- Webを支える技術の発明
- WebサーヴァとWebクライアント
- なぜ、クライアントとサーバに分けるのか
- コラム「クライアント」と「サーバ」偉いのはどっち？
- 「そのリソースはどこにある」- URL
- HTTP
- コラム インターネットに公開された技術仕様 - RFC
- CGIの誕生
- 動的なコンテンツへの要求
- CGIの誕生
- Webの爆発的な普及
- サーブレットの登場
- CGIにまつわる問題点
- Java/サーブレットの誕生
- Javaでアプリケーションを開発することの利点
- コラム 早すぎた技術、Javaアプレット
- JSPの誕生
- サーブレットの問題点
- 発想の逆転！JSPの誕生
- Webアプリケーションフレームワークの時代
- サーブレットやJSPの問題点
- Webアプリケーションフレームワークの誕生
- まとめ
- HTTPを知る
- HTTPの知識はなぜ必要か
- コラム ハードウェアさえも信じられない事態！？
- WebブラウザとWebサーバの通信をのぞいてみよう
- 横取り丸とInetSpyのインストール
- HTTP通信をのぞいてみよう
- HTTPリクエストを除く
- コラム URLとURIは何が違うのか？
- HTTPレスポンスをのぞく
- HTTPでは1回で1つのリソースを取得
- ファイル名を省略した場合のリクエスト
- 情報はどうやってインターネットの大海原を越えるのか
- インターネット上の住所・IPアドレス
- IPアドレスを頼りに情報を届けるTCP/IP
- IPアドレスは誰が決めるのか
- グローバルIPアドレスとプライベートIPアドレス
- コラム IPアドレスと個人情報
- ホスト名をIPアドレスに変換するDNS
- DNSはどのようにして実現されるのか
- ホスト内の宛先を決定するポート番号
- Webサーバへの要求をどのように伝えるか
- GETメソッドによるパラメータ渡し
- アプリケーション側でのパラメータの受け取り
- POSTメソッドによるパラメータ渡し
- GETとPOSTどちらを使えばよい？
- 日本語はどのようにして渡せばよいか
- まとめ
- CGIからWebアプリケーションへ
- 宅配ピザ注文サイトを作ろう
- 画面構成を考える
- コラム 実際のWebシステム開発の流れ
- 画面モックを作ろう
- ログイン認証機能を作成する
- PHPで認証機能を作ろう
- 認証機能の動作を確認しよう
- リダイレクト動作のHTTP通信を確認しよう
- コラム PHPはどのように実行されるのか～CGIとモジュールの違い～
- ログイン状態をどのようにして記憶するのか
- ステートフルなプロトコルとステートレスなプロトコル
- ステートレスなHTTP上で状態をどのように表現するか
- Cookieを利用して状態を保存する
- Cookie利用の実際を確認する
- 安全に状態を保存するための技術 -セッション-
- Cookieにまつわる問題点
- コラム Cookieはどこに保存されている？
- 銀行の窓口業務でセッションを理解しよう
- 口座開設業務の進行状況をどのように管理するか
- セッションで処理の進行状況を管理する
- セッションの状態をどこで保持するか
- HTTPにおけるセッションIDの受け渡し方法
- セッションID利用の実際を確認する
- セッションIDによるユーザの識別
- ピザ・ペントミノの完成
- コラム Webサーバによる認証機能～Basic認証～
- まとめ
- Webアプリケーションの構成要素
- なぜWebアプリケーションの構成を理解しなければならないのか
- コラム コンピュータとは「節」？
- WebサーバとWebクライアントの時代
- WWWの黎明期
- CGIの時代
- コラム ソフトウェア？プログラム？アプリケーション？サーバ？
- データベースサーバの登場
- 大量の情報をどのようにして管理するのか
- データベース管理システムの登場
- コラム DB？DBMS？RDBMS？
- データベースに対する操作
- データベースによる情報の管理
- コラム データベース設計はITシステムの要
- データベースから情報を抽出する
- 必要な情報をSQLでデータベースへ伝える
- コラム データベースに対するCRUD操作とSQL文の関係
- データベースとクライアントの関係
- データベースサーバの分離
- Webアプリケーションとデータベースの通信
- コラム 代表的なデータベース製品
- アプリケーションサーバの登場
- ServletやJSPはどこで動いているのか
- Servlet/JSPを動かすためのアプリケーションサーバ
- Webサーバとアプリケーションサーバの連携
- Webサーバとアプリケーションサーバの分担
- Webサーバとアプリケーションサーバ連携のメリット
- 複数のTomcatへの転送
- Webサーバの機能を持ったアプリケーションサーバ
- コラム アプリケーションサーバの提供する機能
- Webシステムの三層構成
- 最小構成のWebシステム
- 一般的な構成
- Webシステムの三層構成
- コラム 現代のWebシステムを支えるオープンソース
- まとめ
- Webアプリケーションを効率よく開発するための仕組み
- サーブレット/JSPだけではいけないのか
- Webアプリケーション開発のスタンダード・Java
- サーブレットとJSPの連携
- サーブレット/JSPで「ピザ・ペントミノ」のログイン処理を実現する
- JSPによるログイン画面の表示
- サーブレットの呼び出し
- ログインサーブレットの処理
- フォワードとリダイレクトの違い
- リクエストスコープにおける情報の受け渡し
- JSPにおけるリクエストスコープからの情報の取り出し
- なぜリクエストスコープが必要なのか
- セッションスコープとリクエストスコープの違い
- コラム さまざまなセッションの実現方法
- Webアプリケーションのアーキテクチャ
- ロジックとデザインの分離
- ソフトウェアの建築様式
- コラム カスタムタグとJSTL
- 「ピザ・ペントミノ」の構造を俯瞰しよう
- MVCモデルによるWebアプリケーションのアーキテクチャ
- MVCモデルによる処理の流れ
- フレームワークによるアーキテクチャの実現
- フレームワークとは何か
- StrutsによるMVCモデルの実現
- Strutsによる「ピザ・ペントミノ」のログイン処理
- JSPからのログイン処理アクションの呼び出し
- コラム Javaを部品化するための仕組み -Java Beans-
- ログイン処理アクションでログインチェック処理
- 商品一覧画面への遷移
- レイヤパターンによるデータアクセス層の分離
- モデルをどのように実現するか
- JDBCによるデータベースからの情報の取得
- レイヤパターンによるデータアクセス層の分離
- DAOパターンによるデータアクセス層の実現
- O/Rマッピングフレームワークによるデータアクセス層の実現
- O/Rマッピングフレームワークの必要性
- RDBとオブジェクトのインピーダンス・ミスマッチ
- iBATISによるO/Rマッピングの実際
- Data MapperとSQLマップファイルによるO/Rマッピング処理
- Dao Frameworkを利用したDAOの作成
- フレームワーク利用におけるメリットとデメリット
- フレームワーク利用のメリット
- フレームワーク利用のデメリット
- まとめ
- セキュリティを確保するための仕組み
- なぜセキュリティを確保しなければならないのか
- Webアプリケーションが守るべきセキュリティ
- 代表的なWebアプリケーションの攻撃手法とその対策
- SQLインジェクション
- クロスサイトスクリプティング(XSS)
- セッションハイジャック
- コラム SSLによる通信路の暗号化
- クロスサイトリクエストフォージェリ
- コラム セキュリティの陰の立役者・ハッシュ関数
- 強制ブラウズ
- ディレクトリトラバーサル
- コラム より安全な認証方式～Digest認証～
- 設計・実装ミスに起因する誤動作やセキュリティ問題を防ぐための対策
- 「戻る」ボタン対策
- ダブルサブミット対策
- hiddenタグに重要な情報をもたせない
- デバッグ情報を出力させない
- グローバル変数に情報を持たせない
- まとめ
- おわりに
- 謝辞
- 付録
- 参考書籍・サイト
- 索引
- モデル
- ロジック
- ビュー
- デザイン
- コントロール
- アダプタ
- プレゼンテーション層
- ユーザーインターフェース
- ビジネス層
- ロジック
- データアクセス層
- 永続化
読み込み時にランダム値を発行しておき、この値を保存しておく。送信時に利用されたらそのランダム値を使用済みとする。こうすることで、様々な災を避けることができる。問題は定期的に保存したワンタイムトークンを削除しなければならず、どのタイミングで削除するかだ。発行日時とワンタイムトークンを一緒に保存してデータ読み込み時に一定期間が経過したワンタイムトークンはハッシュから削除するようにする。
onsubmit formタグのonsubmitイベントはfalseが返ると送信されない？ これを利用してグローバル変数のフラグを送信時に倒せば良い。が、これは掲示板などでは連続投稿ができない。質問者は良いが、回答者は連続で回答することが多いがこれでは困る。
ヘッダー情報を操作してキャッシュをno-cacheなどにする ヘッダー情報でLocationを利用するとリダイレクトが利用できる
0 件のコメント:
コメントを投稿