Server Sent Events(SSE)の使いどころと使い方 | GREE Engineering
Flameの箱を捨ててしまったためどうやって送り返すか困っています。@kyo_agoです。 今日は2014年6月にβ公開したGREEチャットで通信に使用しているSSEを紹介したいと思います。 SSEとは SSEとはServer-Sent Eventsの略でW3Cで提案されているhtml5関連APIの一種です。 これはサーバとの通信やJavaScript APIを中心としたもので、サーバからPush通信を行うための仕様です。 サーバからPush通信に関してはこれまでもCometやWebSocketが存在しましたが、SSEは互換性や効率などの点でそれ以外の技術に対する特徴があります。 ここからは具体的な仕様や、実際に使用した場合の感想などを紹介したいと思います。 通信方式 SSEはHTTP/1.1を使用し、Content-Type: text/event-streamで通信を行います。 基本的
お疲れさまXMLHttpRequest、こんにちはfetch - Qiita
Service Workersでプッシュ通知を受信できるようになったわけですが([1]: GCM)([2]: Web Push)、Chromeではバージョン48まではGCMで通知だけができるようになっただけで、メッセージ本体は通知を受けてからService Workerでサーバから改めて受け取るような実装をする必要があったりします。 ここで、Service Workersでは、XMLHttpRequestが使えません。その代わり、XMLHttpRequest (以下、XHR)に代わるWHATWGの仕様としてFetch APIがあり、Service WorkersではこのFetch APIを使うことになっていますので、その使い方を簡単に紹介します。 Fetch API自体は、Service Workers専用のものではなく、メインスレッドでもXHRの代わりに使うことが可能です。現時点で実装し
CORSまとめ - Qiita
今更ですが、**CORS (Cross-Origin Resource Sharing)**を色々試していたら、思っていた以上に色々パターンがあることに気づいたので、改めてその扱い方についてまとめてみました。 そもそも 現在のWebブラウザでは、あるWebサイトが持つ情報が別の悪意あるWebサイトに悪用されるのを防ぐために、Same-Origin Policy(日本語では同一生成元ポリシー)が適用されます。 例えば、あるWebサイト https://guiltysite.com をブラウザで表示している時に、このWebページからXMLHttpRequest(以下、XHR)やFetch APIで別のWebサイト https://innocentsite.net からHTTP(S)でデータを読み込もうとすると、エラーになる、というわけです。 しかし、アクセス元が悪意あるWebサイトならともかく
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
第44回HTML5とか勉強会「HTML5とセキュリティ」アウトラインメモ
第44回HTML5とか勉強会「HTML5とセキュリティ」 に参加してきたのでメモ。 2014/01/29(#html5j)第44回HTML5とか勉強会（HTML5とセキュリティ – Togetterまとめ 第44回 HTML5とか勉強会 – YouTube 今から始めるHTML5セキュリティ – 松本悦宜 一般社団法人JPCERTコーディネーションセンターの紹介 「HTML5を利用したWebアプリケーションのセキュリティ問題に関する調査報告書」 HTML5 を利用したWeb アプリケーションのセキュリティ問題に関する調査報告書 アジェンダ – 報告書の概要 JavaScript API XHR ブラウザが実装してる関連機能 HTML5は開発者にとって非常に便利 => 攻撃者にとっても便利 表現の幅が広がる 攻撃の幅も大きく広がる HTML5とセキュリティ 従来のHTMLでは影響がなかったも
HTML5とか勉強会に参加して来ました - TechTalkManiacs
テーマはHTML5とセキュリティ できることが増えてきたことで、セキュリティも大事になってきた 今から始めるHTML5セキュリティ(JPCERT 松本さん) JPCERTコンピューターセキュリティ早期警戒体制の構築運用 HTML5のセキュリティの概要 HTML5は開発者にとっても攻撃者にとっても便利 攻撃の幅も広がる ブラウザの実装によって脆弱性になってしまうケースも 今日はXMLHttpRequeestを中心に紹介 従来のXHRは同じオリジンしか通信不能 XHR2ではクロスオリジン通信ができる オリジンで制限しても通信自体は送られる 例:URLハッシュをそのまま使う ホワイトリスト推奨 アクセス制限はCookieを使うのが大事 formactionやvideoタグのonerror ローカルのチェックだけでなく、サーバーサイドのチェックも iframe snaboxはiframeを直接開け
(JavaScriptでの)バイナリデータの送信と受信 - yoya's diary
Sending and Receiving Binary Data https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Sending_and_Receiving_Binary_Data 場所変わったので↑https://developer.mozilla.org/en-US/docs/DOM/XMLHttpRequest/Sending_and_Receiving_Binary_Data 「JavaScript バイナリ」でググっても古い情報ばかり見つかるので、ついカッとなって勢いで翻訳しました。 多分精度は低いのでおかしい所は指摘を頂けると嬉しいです。すぐ直します、恥ずかしいので。 初めに追記 (2013/04/27) 本家の方に翻訳文を移しました。↓こちらの文章の方が精度が高いのでお勧めです。 バイナリデータ
uu59のメモ | Rails4でデフォルトで入るturbolinksがオープンリダイレクタと合わさると何でもできてかなり危険
Rails 4.0で入るturbolinksですが、これが有効だと無効の環境と比べてセキュリティリスクが微増するという話です。具体的にはRailsサービス内（同一ホスト内）にオープンリダイレクタがあり、CGMサイトであるとかユーザーが任意のリンクを張れる場合に、悪意あるスクリプトがそのサービスのホスト下で実行されてしまう。というのをmalaさんに指摘されました。 Railsであれば基本的にredirect_to :action => "show", :id => @model.idみたいな感じで書いてリダイレクトしてるだろうけど、redirect_to params[:hoge]みたいに書いてる場合は?hoge=http://evil.example.comとかでevilなページに飛ぶし、turbolinksと関係なくよろしくないので暇を見て直しましょう。 話を戻してturbolinksだ
オリジン間リソース共有 (CORS) - HTTP | MDN
HTTP ガイド HTTP の概要 典型的な HTTP セッション HTTP メッセージ MIME タイプ（IANA メディア種別） HTTP の圧縮 HTTP キャッシュ HTTP 認証 HTTP Cookie の使用 HTTP のリダイレクト HTTP 条件付きリクエスト HTTP 範囲リクエスト コンテンツネゴシエーション HTTP/1.x のコネクション管理 HTTP の進化 プロトコルのアップグレードの仕組み プロキシサーバーとトンネリング HTTP クライアントヒント HTTP セキュリティ サイトの安全化 HTTP Observatory Permissions Policy コンテンツセキュリティポリシー (CSP) オリジン間リソース共有 (CORS) Cross-Origin Resource Policy (CORP) Strict-Transport-Securit
XMLHttpRequestを使ったCSRF(補足編) - 葉っぱ日記
XMLHttpRequestを使ったCSRF対策 - 葉っぱ日記を書いていて思ったけど、いまいちXHRを使ったCSRF(というかクロスオリジン通信)について理解されていないような感じだったので、ちょっと書いておきます。とりあえず日本語のリソース的には、HTTP access control | MDN が詳しくて、それを読めばだいたい事足りるんで、あとはCSRFに関連しそうな話題だけ。 Q. そもそも「クロスオリジン」って何？ スキーム、ホスト、ポートの3つの組み合わせが一致している場合を同一オリジン(same-origin)、いずれか一つでもことなる場合をクロスオリジン(cross-origin)と言います。つまり、XHRでドメインを超えて通信している場合は典型的なクロスオリジン通信となります。 Q. え？ XMLHttpReuest って他のドメインにリクエストを発行できないんじゃ い
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
文字列からHTMLを組み立てる話 Shibuya.XSS techtalk #5
https://utf-8.jp/public/20140129/html5j.pptx