産業技術総合研究所（産総研）とヤフーは2008年4月22日，パスワードを用いてWebブラウザ/サーバー間の相互認証を実現する認証プロトコル「HTTP Mutualアクセス認証」の実装をオープンソースとして公開した。同プロトコルを使うと，HTMLフォームではなくブラウザに設けた専用の入力域を用いてパスワードを暗号送信するため，フィッシング詐欺対策となる。サーバー側にはApacheのモジュール「mod_auth_mutual」として実装し，クライアント側としてFirefoxの機能を拡張したブラウザ「MutualTestFox」を開発した。 HTTP Mutualアクセス認証は，パスワードを用いてクライアントとサーバーが相互に相手を認証するプロトコルである。産総研とヤフーが2007年3月に発表した。同プロトコルの特徴は，ブラウザ上に設けた専用の入力域にパスワードを入力すると，暗号化処理を施した後
2007年08月20日10:06 by 山崎泰宏 iframeで同じドメインのコンテンツを複数埋め込んだ場合のセッション カテゴリネタ Tweet sparklegate Comment(3)Trackback(0) 当然の話だけど、セッションの話は認証の技術に関連するのでメモ。 ※08/20: ご指摘をいただきましたので、一部誤字を修正しました。×「帰る」→○「返る」 ここでは、ブラウザを立ち上げた直後のように、当該ドメインへのセッションCookieが存在しない状態からリクエストが始まることを前提にする。 iframeで同一ドメインに複数アクセスするとセッションCookieが捨てられる。あるドメインAに存在する１ページに複数iframeタグが埋め込まれており、これらが全て同じドメインBのコンテンツだとする。 初めてドメインAにあるこのページに訪れたブラウザは、ドメインBに対して同時に複数
最速インターフェース研究会 :: 最近IE6でWikipedia日本語版の表示が異常に遅いのはKeepAliveのせい 2月初めぐらいからか、キャッシュが空の状態で日本語版のWikipediaを表示すると、IE6が1分間ほど固まる、という不具合があるそうだ。 で、Proxomitronでレスポンスとか調べてみてたりしたのだけれど、プロキシ経由だと問題なく表示される。 これ、私が普段仕事で使っているIE6でも再現していたので、HTTP Debugging Proxy - Fiddlerを使ってブラウザのHTTP通信をキャプチャして調べてみました。 （※2007/02/13追記：upload.wikimedia.orgで対策され、既に本現象は解消されています） どうやら画像ファイルhttp://upload.wikimedia.org/wikipedia/ja/b/bc/Wiki.pngの読み
■ 空白ページが出てしまう不具合を解消 日記をここに移転した際にFirefoxでの閲覧で生じていた以下の不具合をいまごろ解消した。 html_anchor.rbプラグインを有効にしてみたところ、IEでは普通に動作するが、Firefoxでアクセスすると、どういうわけか、2回に1回必ず、応答がなく空白のページになってしまうという異常が発生する。私の環境だけなのかがよくわからない。 html_anchor.rbを使うにあたって、Apacheでmod_rewriteを使うのが推奨とされているが、ここのサーバには残念ながらインストールされていないので、「Actionを利用する」で説明されている方法でやっているが、これが原因なのだろうか。 2004年11月14日の日記 レスポンスヘッダにETagフィールドを出力するようにindex.rbを改造したところ、この現象は起きなくなった。 ■ カウンタの無視U
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
本業の Web サーバの構成について以前書いた記憶もあるのですが、Lighttpd や Apache2 の mod_proxy が流行る前に構築したこともあって、ちょっとだけ Pound が流行った？時によくある構成で組んでます。ザックリ図にしてみると な感じになっています。で、前から薄々気がついてはいたのですが、この構成、致命的な欠陥があるんです。 その欠陥とは、pound の HTTP リクエストのヘッダ処理の実装にあります。pound のソースは適当にしか読んでいないので、間違ってる可能性もありますが、図にするとヘッダーのサイズ最大値の処理がこんな感じになっています。 ヘッダーの中でサイズが大きいと言えば、Cookie しかないですね。その Cookie に関しては RFC 2109 （set-cookieについて）と RFC 2965 （set-cookie2について）で定められて
コンピューター系のblogになる予定です (blog名のまま)。が、もう更新を停止しました。コメントもトラックバックもできません。すいません。。。 お知らせ： 2014/07現在、2015/09/30 で kinshachi.ddo.jp のドメインが使えなくなってしまうかもしれないので、ddo.jp と dip.jp で並行運用します。(居ないとは思いますが ^^;) ブックマークをしてる人が居たら ddo.jp から dip.jp へ変更お願いします。 ■ LiveHTTPHeaders ・mozdev.org - livehttpheaders: index http://livehttpheaders.mozdev.org/ LiveHTTPHeadersは、リクエスト/レスポンスを閲覧できるMozilla/Firebirdの拡張機能。 一度送信したリクエストを編集して再送すること
これらの手動検査の補助ツールとして、フリーで入手できるアプリケーションには以下のようなものがある。 Achilles Paros Odysseus 筆者が手動検査を行う際にはAchillesをよく使う。Achillesは設定が簡単で、通信内容を簡単に編集することができるからだ。 手動による検査のポイント では、具体的にどのような観点で検査を行えばよいのだろうか？データを書き換えると簡単に書いたが、Webアプリケーションの規模が大きい場合、すべてのページのすべてのパラメータに対して、全部の検査パターンを試すのには膨大な時間がかかる。その上、実際には対象となるページの機能によって、試す意味がないパターンも多い。 そこで、あらかじめページ巡回しておいて全体を把握する。どこでどういった処理がなされているかに注目しておき、検査パターンと対象個所を絞っておく。例えば、 データベース（DB）にアクセスし
ネットワークプログラミングの基礎知識 ここでは IP アドレスやポート番号、クライアントとサーバの役割などを説明し、 perl・C言語・Java などでソケット (Socket) を使った HTTP クライアントや POP3 クライアント、簡単なサーバを作成してみます。 要はネットワークプログラミングをやってみよう、ということです。 このページのサンプルプログラムは、RFC などの規格に準拠した「正しい」プログラムではありません。 また、全体的にエラー処理が不十分です (今後改善する予定です)。 あくまでも概要を理解するためのサンプルととらえてください。 もし本気でしっかりとしたクライアントやサーバを書きたいなら、このページを読んだ上で、 さらに RFC を熟読し、そして wget・Apache・ftp コマンドなどのソースを参考にしてください。 このページに間違いを見付けたら、掲示板 で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
