サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
おみそ汁
hirapi.hatenablog.jp
(スライドもし公開されたら貼らせていただきます) ※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容はスライドか、もしくはYouTubeで公開される(?)公式動画をご覧ください。 開発現場で役立たせるための設計原則とパターン by Shinpeim 『WEB+DB vol.91』データ構造特集がおすすめ テーマ このケースで何が最適か、どうやって判断するの? 「適材適所」「ケースバイケース」は何ら回答になっていない テイクホームメッセージ 複数の選択肢を用意する → 問題の「変わりやすいところ」を考慮して設計原則からレビュー を繰り返す 設計原則 単一責任原則 開放閉鎖原則 凝集度・結合度 内容めも 設計・パターンは抽象的な話が多く、空中戦になりがち 「抽象化」って人による 「責務」って考え方による 「システム全体に責務を持つからSystemManagerクラス作ろう」← 反
つまり XMLHttpRequestでクロスドメインのリクエストを送って、リクエスト先でCookie付けたりリクエスト元に値を返したりするときは、XMLHttpRequest・レスポンスヘッダに↓をつけること。 XMLHttpRequest withCredentials: true レスポンスヘッダ Access-Control-Allow-Origin: (リクエスト元ドメイン) Access-Control-Allow-Credentials: true (リクエスト元ドメイン)のところに * を使うと、もうひとつの Access-Control-Allow-Credentials がきかずエラーになり、Cookieが付与できない。 サーバー側のプログラムでリファラを取得して動的に指定してあげると通る。 ただしセキュリティ的にそれでいいのか感はある。 くわしく やりたいこと XMLH
このページを最初にブックマークしてみませんか?
『hirapi.hatenablog.jp』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く