auのSSLでのCookieの挙動がおかしい - maru.cc@はてな
auはCookieを使うことが出来る。キャリアの公式情報としても公開されている。 「404 Not Found」 EZweb対応端末においてCookieは、EZサーバに保管されます。 ただし、WAP2.0ブラウザ搭載端末ではEnd to EndのSSL通信時は端末に保管されます。 なお、EZサーバに保管されたCookieはKDDI設備のメンテナンスなどによりリセットされる場合があります。 つまり httpの非SSL領域では、ゲートウェイ（EZサーバ）がCookieを保管する httpsのEnt to EndのSSL領域では、端末がCookieを保管する ということだ。 これが結構曲者である。 さらに、公式な資料はないけど、端末の挙動から想像するに以下のような挙動をする。 http領域では、GWと端末の両方のCookieを送ってくる http領域で、GWと端末に同じ名前でCookieが設定さ
DoCoMo iモードブラウザ2.0でCookie - maru.cc@はてな
DoCoMoのこの夏モデルから、iモードブラウザ2.0というより高機能なiモードブラウザが搭載されるようになりました。 CookieやCSS,JSなど、大きな違いがありますので、実際に実機で確認をしてみます。 端末は、N-06A を使用します。なんか、発売停止なんてなってますが。。 Cookie まずは、Cookieについて。 以前、以下のような調査をしたことがあったので、同じ調査をしてみました。 auのSSLでのCookieの挙動がおかしい - maru.cc@はてな au,SoftBankでSSLでCookieセッションを使用する場合の問題点 - maru.cc@はてな 結果は、問題なく使えます。http<->httpsでの動作、secure属性の挙動も問題ありません。 これを使えば、Cookieセッションでセキュアなサイトがちゃんと作れそうです。 setcookie()の httpo
PHPのSession Adoptionは重大な脅威ではない - ockeghem's blog
なぜPHPアプリにセキュリティホールが多いのか?：第25回 PHPのアキレス腱にて、大垣靖男氏がPHPのSession Adoption問題について取り上げている。大垣氏は度々この問題を取り上げているが、今のところ氏の主張に同調する人を見かけない。それもそのはずで、大垣氏の主張は間違っていると私は思う。 以下、大垣氏の主張を実際に試してみる形で、順に説明しよう。 大垣氏の主張 大垣氏の主張は、PHPにはSession Adoption脆弱性があるために、標準的なSession Fixation対策であるsession_regenerate_id()を施しても、その対策は有効ではないというものだ。 しかし，実際には現在に至るまでPHPのセッションモジュールのセッションアダプション脆弱性は修正されないままになっています。このために，本来はsession_regenerate_id関数をログイン
i-mode端末にクッキー - Kimura.Memo
COOKIEを送らないことで有名なi-mode端末の最新機種がCOOKIEを送っていることがわかった。 現時点でCOOKIEを送ってくることを確認している端末は以下の通り。 いずれもIPアドレス帯域は、210.153.84.**で、iモードセンタのIPアドレス帯域内のもの。 DoCoMo/2.0 P07A(c500;TB;W24H15) ※ちなみに送られてきたHTTP環境変数は以下の通り。 HTTP_COOKIE HTTP_HOST HTTP_REFERER HTTP_USER_AGENT HTTP_X_DCMGUID 【関連記事】 i-mode端末にリファラ（2009-04-28） 【2009/05/20 追記】 ドコモ公式発表 - ｉモードブラウザ2.0
ウノウラボ Unoh Labs: 携帯とCookieドメイン
こんばんわ五十川です。 しばらく前になりますが、ソーシャルスクラップブックclippのモバイル版をリリースしました。cippモバイルではドコモ以外は、セッション管理にCookie（のみ）を利用することにしたのですが、そのときCookieドメインではまりました、というお話。 PC向けclippのドメイン名は、トップページなどのユーザ共通ページは「clipp.in」、ユーザ個別のページは「{username}.clipp.in」（例えばclipp-info.clipp.in）となっています。ケータイサイトをマルチなサブドメインにする例はあまり多くないと思いますが、clippモバイルでは、ルーティング直すのめんどくさいという怠け者な理由で、PC版のドメイン名がそのまま使えればいいなと思って取り掛かりました。しかし、その目論見はあっさりと破綻することになるのでした。 以下の内容は手元の数多くない端
blog.8-p.info: NSURL なんとかで cookie を共有
hibomaのはてなダイアリー - 「Automatorで良いのは、cookieとかのsessionがそのまま利用できるとこ」とのこと 裏を返すと、悪意のあるAutomatorアプリ(もしくはAppleScript)を走らせるとSafariのCookieが透過的に利用されてしまいセッションハイジャックされる危険性がある と。 Automator や AppleScript を使わなくとも、Cocoa の NSURL なんとか系列の API を使う限り、cookie は共有されている感じがします。 require 'osx/cocoa' url = OSX::NSURL.URLWithString('http://mixi.jp/home.pl') req = OSX::NSURLRequest.requestWithURL(url) data = OSX::NSURLConnection.
「Automatorで良いのは、cookieとかのsessionがそのまま利用できるとこ」とのこと - hibomaの日記
2007年02月19日 ma_ko OSX, programming Automatorで良いのは、cookieとかのsessionがそのまま利用できるとこだと思った はてなブックマーク - hibomaのはてなダイアリー - Automatorでしょこたん画像スクレイピング はてブでこんなコメントを頂きました。 (id:ma_koさん、すんません。タイトルとしてそのまま頂きました。) なるほど。盲点でした。ということで以下のAppleScriptを試してみた。 tell application "Safari" activate open location "http://mixi.jp/home.pl" end tell Safariにmixiのホームを見に行かせます。一度自分でログインしてCookieを取得してあると、確かにちゃんとセッション処理して勝手にログインしてくれます。楽です
JavaScriptでクッキーを超簡単に使うライブラリ「Cookie Manager」:phpspot開発日誌
PHPから使えるprototype.jsとscript.aculo.usのラッパークラス「Projax」 次の記事 ≫：WEBマスター/WEB開発者、御用達のサイトリンク集 Cookie Manager | Javascript Code | All Things Webby Initialisation of a CookieManager object: JavaScriptでクッキーを超簡単に使うライブラリ「Cookie Manager」。 JavaScriptでクッキーを扱うのって、いちいちクッキーをパースして面倒だ、と思っていた人は多いのではないでしょうか？ CookieManager.jsを使えば、phpでcookieを使うときみたいに簡単にcookieが使えます。 prototype.jsをベースとしていて、サンプルのコードは次のような感じになります。 サンプルはクッキーを使
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ライブドアブログ｜無料で豊富な機能が充実