Hey! Java Programming! //Cookie//
ネットサーフィンを行っているとき、よく "Cookie を受け取りますか？" と聞かれることがあります。Cookie はページとページの間で何らかのデータを受け渡すためのものです。ブラウザはあるページで Cookie データを受け取り、別のページでそれを渡しています。 Lippie 病院へ行く 「血圧が高いですね。」 小やせした無愛想な医者は、何かを書きとめながらこちらを見もせず言った。「2時から採血を行いますので、時間になったら受付まで来てください。」 そう言って、これまた無愛想に一枚の紙切れを突き出した。 「地下に食堂があります。病院内で求められたらこの紙を見せてください。」 なぜだか一瞬受け取るのを拒否しようかと思ったが、反射的に受け取ってしまった。負けたような後ろめたさを感じて、そそくさと診察室を出ていった。 今は 11時だ。医者の役所対応に腹を立てたが、待合室を見れば無理も
[ThinkIT] 第8回：Cookieとセッション情報 (1/3)
サーバ／クライアント間の通信を担当するHTTPは、ステートレス（状態を管理しない）なプロトコルです。このように表現してしまうと難しく聞こえるかもしれませんが、要するに「複数のページ間で情報を保持することができない」ということです。 例えば、ページXとページZという2つのページがあったとします。ページXを処理したあとにページZを呼び出したとしても、ページZはページXで入力された内容や処理結果、さらにページXのあとに呼び出されたということも知ることはできません。 HTTPにおいては、リクエスト／レスポンスの一往復が完結された処理と見なされるので、次に発生したリクエストはまったく別物と認識されるからです。 しかし、JSP＆サーブレットアプリケーションを構築する場合、複数のページ間で情報の保持が必要になるケースは少なくありません。例えば、認証を必要とするアプリケーションを想定してみてください。トッ
とほほのCookie入門 - とほほのWWW入門
Cookieの概要 Cookie情報が保存されるファイル Cookieの実行例 Cookieの設定 Cookieの書き込み Cookie書き込みの例 Cookieの読み込み エンコードとデコード Cookieに関するQ&A Cookieの語源は何ですか？ Cookieで複数の値を設定するには？ Cookieを削除するには？ Cookieの有効期限を無期限にするには？ path=/ とすると、そのサーバー上のすべてのファイルに対して送信されるの？ Cookieをフォルダ単位ではなく、ファイル単位に設定することはできますか？ escape()でエンコードされたUnicodeをCGIでシフトJISにデコードするには？ Cookieの概要 Cookie とは、以下のようなことを実現するための機構です。 訪問者がそのページに何回訪れたか記録して表示する。 通常モード、フレームモードなど、訪問者の好み
リファレンスを使って仮想的多次元配列
1.リスト 複数のスカラ変数を並べた構造を『リスト』といいます。リストはスカラと同じように数値、文字列を区別なく扱います。リストの書き方はとても簡単で、値をカンマで区切り、その全体をカッコで囲むだけです。1、2、3の 3 つの値のリストは、以下のように表します。 (1, 2, 3) リストの代入 リストの要素に代入する場合は、下記のような方法があります。 ($a, $b, $c) = (1, 2, 3); リストの中にリストがある場合には、自動的に展開されます。 (@list1, @list2, &function) 上記のようなリストは @list1 のすべての要素の後に @list2 のすべての要素を追加し、その後にfunction というサブルーティンが返すすべての要素を追加します。 リストの要素数と変数の数が違う場合 リストの要素数よりも、用意した変数のほうが多い場合には、あまった
HTTP Cookies
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネット(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)（「ICANNがレジストラとして認定した企業」一覧（InterNIC提供）内に「Japan」の記載があるもの）を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2024年5月時点の調査。
高木浩光＠自宅の日記 - クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法
■ クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法 「クロスサイトリクエストフォージェリ」がにわかに注目を集めている。古く から存在したこの問題がなぜ今まであまり注目されてこなかったかについて考 えているところだが、引越しやら転勤やらでいまひとつ日記を書く時間がない。 しかし、 @ITの記事などのように混乱させる解説も散見されるので、一点だけ対策 方法について書いておくとする。 クロスサイトリクエストフォージェリ――Cross-Site Request Forgeries (CSRF)を防止する簡潔で自然な解決策は以下のとおりである。 前提 ログインしていないWeb閲覧者に対するCSRF攻撃（掲示板荒らしや、ユーザ登 録を他人にさせる等、サイト運営者に対する業務妨害行為）はここでは対象と しない。 ログイン機能を持つWebアプリケーションの場合、何らかの方法でセッション 追
Cookieの使い方 ～ ウェブ・プログラムの実験場！ Web Application Programming Lab.
●Cookieの利用について これまではサーバー側に処理された情報を記録する方法を中心に扱ってきました。たいていそのような処理で問題ないのですが、利用者のパソコン（クライアント）側にデータを記録できるといいなぁ、、、と思ったことはないでしょうか？ 掲示板などで毎回入力する必要のある決まった項目（名前、メールアドレスなど）といったことから、ログインするまでもないけど利用者が設定した画面構成を再度表示したい場合まで、、、 このような場合にCookieという技術を利用することができます。このCookieの歴史について深くはここでは触れませんが、もともとNetscape社がブラウザにデータを記録するために開発した技術で、それが他のブラウザにも採用され、現在では標準的となっている技術の一つです。 ネットスケープ社のCookie公式情報（別窓） Cookieに関するスペック（別窓） とりあえずサンプル
おさかなラボ - MixiとCookieドメイン
Mixiが、一時的にCookieのドメインを“mixi.jp”から“.mixi.jp”に変更して、一部ブラウザからアクセスできなくなるという現象が起こりました。これをmixi側は「古いブラウザを使っているのが原因。新しいブラウザに変えれば直る」と一蹴しましたが、この対策が妥当だったかはともかくとして、規格上、古いブラウザと新しいブラウザのどちらに問題があったのかを検証してみます。 “.mixi.jp”への変更が妥当だったかどうかについて。 Cookieについては当初Netscape社のテキトーなドキュメントのみが仕様として成り立っていた経緯があり、実装にかなり揺れがあります。特に Cookieの大元の仕様と、RFC上のCookieの仕様の2つの内容が相反していて、Netscapeの仕様の方はDOMAINの先頭にドットを入れることに言及がない(サンプルは先頭ドットなし)。一方、RF
Cookie(クッキー)の届く範囲 (あいまいモード)
Cookieが届く範囲を再確認 別のページでCookieについて解説しましたが、 実際Cookieを利用したプログラムを作ると疑問に思えることも出てきます。 その一つとして、Cookieが届く範囲は？というものがあります。 発行されたサーバー（ホスト）に返信されるというのが基本ですが、 Cookieの仕様には「domain」や「path」というのがあったのを覚えてますでしょうか？ （なにそれ？という方は下記のW3CのRFCか前回の解説をどうぞ、、、） Cookieの仕様は下のリンクをどうぞ・・・ W3C (RFC 2109)HTTP State Management Mechanism Netscape HTTP Cookies Cookieの詳細については上のリンクで確認していただくとしても、 実際にプログラムを書く場合にどうやって使うの？という場面も多いと思います。 自分もCookie
VOXのSCRIPT対応とユーザ認証用クッキーのドメイン - bits and bytes
マッシュアップ、という言葉が現れる前からSCRIPTタグを使ってブログを飾るさまざまなブログパーツがありました。最近では、アマゾンの Amazonおまかせリンク や Google Analytics のように企業が提供するツールでもHTMLの中からSCRIPTタグで読み込んで利用することが増えています。 クッキーの問題 そういったブログパーツを利用するためには、使用しているブログサービスが、エントリの本文やブログのサイドバーなどにSCRIPTタグを入れることを許可している必要があります。しかし、ページの中に任意のスクリプトを書けるようにすると、クッキーを発行するドメインを別にする等の対策をしなければ、同じブログサービスを利用しているユーザがそのページを閲覧したときに認証用のクッキーを盗み出せるようになってしまいます。 そこでSCRIPTタグを利用できるブログサービスが、このクッキー盗難問題
Cookieがパフォーマンスに与える影響 - おぎろぐはてブロ
Yahoo!のYUI Blogで、"Performance Research, Part 3: When the Cookie Crumbles"という記事で、Cookieがレスポンスに与える影響が説明されています。 Cookieのサイズと、それによるレスポンスタイムの変化の表とか興味深い。 まとめの適当な訳。 不要なCookieを排除する cookieのサイズを可能な限り小さくする 適切なドメインレベルで発行し、不必要に他のサブドメインに影響を与えないようにする 適切な有効期限を設定する。 実サイトのCookieサイズの分析 記事の方では、トップページにアクセスしたときの各サイトで発行されるCookieのサイズの表が示されています。 でも、それってちょっと、やほーの都合のいいような条件にしてないか？ということで、普段使って、Cookieが蓄積されている状態でのCookieのサイズを調べて
cookieのサイズはパフォーマンスに影響を与えるか - bits and bytes
私は "回線が早くなった現在、データの転送よりもコネクションの確立にかかるオーバーヘッドの方が大きい" という根拠のない信念を持っています。 だから、今ではバイト数を節約するよりも、Vitamin Features » Serving JavaScript Fast のような方法でコネクションを抑えることのほうが速度的には効果があるだろう、考えていました。 そんなところに おぎろぐはてな - Cookieがパフォーマンスに与える影響 経由で Performance Research, Part 3: When the Cookie Crumbles » Yahoo! User Interface Blog に、クッキー500バイトでレスポンスを15ms改善できるという記事を見つけて、単純に500バイトを15msで割ったら300Kbps程度で日本じゃあり得ない遅さですが、小さいファイルの場
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://lanceweb.jp/javascript/jsa06.html
IBM Developer
YUI Library