「ウェブリブログ」は 2023年1月31日 をもちましてサービス提供を終了いたしました。 2004年3月のサービス開始より19年近くもの間、沢山の皆さまにご愛用いただきましたことを心よりお礼申し上げます。今後とも、BIGLOBEをご愛顧賜りますよう、よろしくお願い申し上げます。 ※引っ越し先ブログへのリダイレクトサービスは2024年1月31日で終了いたしました。 BIGLOBEのサービス一覧
「ウェブリブログ」は 2023年1月31日 をもちましてサービス提供を終了いたしました。 2004年3月のサービス開始より19年近くもの間、沢山の皆さまにご愛用いただきましたことを心よりお礼申し上げます。今後とも、BIGLOBEをご愛顧賜りますよう、よろしくお願い申し上げます。 ※引っ越し先ブログへのリダイレクトサービスは2024年1月31日で終了いたしました。 BIGLOBEのサービス一覧
前回、「auのSSLでのCookieの挙動がおかしい - maru.cc@はてな」というエントリを書いたところ @suzukiさんから次のような発言をいただきました。 http://twitter.com/suzuki/statuses/809076312 @maru_cc https+Cookieでのセッション管理にはsecure属性付けようよ説が基本とのこと http://www.ipa.go.jp/security/ciadr/20030808cookie-secure.html http://www.ipa.go.jp/security/ciadr/20030808cookie-secure.html (一部抜粋) SSL/TLS でクッキーを使うときはsecure 属性を付けるのを基本とする ・方法 A: すべてのページを https://...にしてセッション管理用のクッキーに
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が設定さ
私はAUのW44Tというクッキー対応携帯を持っているのですが、 これはクッキーが半分しか対応していません。 httpsのサイトに接続すると、クッキーを受け付けてくれません。 httpだと問題なく動作するのに。。。 そういうわけで、httpsでAUの場合はクッキーがないものとして 扱わなければなりません。まさかそんなことがあるとは 全然思わず、本番環境でようやく気づくという始末でした。 AUはそもそもssl証明書をverisign以外はまともに取り合ってくれません。 そのためテスト環境が作れず気づくのが遅れました。 そういうわけで、jpmobileのパッチです。 --- vendor/plugins/jpmobile/lib/jpmobile/trans_sid.rb +++ vendor/plugins/jpmobile/lib/jpmobile/trans_sid.rb @@ -50,6
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く