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＆サーブレットアプリケーションを構築する場合、複数のページ間で情報の保持が必要になるケースは少なくありません。例えば、認証を必要とするアプリケーションを想定してみてください。トッ
TextDrive Weblog: On Rails sessions
On Rails sessions Like everything else in Rails, sessions are pretty easy to use. Unfortunately, the default session configuration isn’t particular well suited for a shared host. You see, by default CGI::Session::PStore (the default session store in Rails) will use the operating system’s temp dir, which on nix-like systems means /tmp. Which is fine, the /tmp dir well suited for small, temporary fi
リファレンスを使って仮想的多次元配列
1.リスト 複数のスカラ変数を並べた構造を『リスト』といいます。リストはスカラと同じように数値、文字列を区別なく扱います。リストの書き方はとても簡単で、値をカンマで区切り、その全体をカッコで囲むだけです。1、2、3の 3 つの値のリストは、以下のように表します。 (1, 2, 3) リストの代入 リストの要素に代入する場合は、下記のような方法があります。 ($a, $b, $c) = (1, 2, 3); リストの中にリストがある場合には、自動的に展開されます。 (@list1, @list2, &function) 上記のようなリストは @list1 のすべての要素の後に @list2 のすべての要素を追加し、その後にfunction というサブルーティンが返すすべての要素を追加します。 リストの要素数と変数の数が違う場合 リストの要素数よりも、用意した変数のほうが多い場合には、あまった
@IT: 「ぼくはまちちゃん」 ――知られざるCSRF攻撃
ある日、大手SNS（Social Networking Site）のmixiの日記にこのような書き込みがあった。それも1人だけでなく、同日に数多くのユーザーの日記に同じ文面が掲載されていた。 これは、単にこのような文章がはやり、ユーザー自身が意図して掲載したのではなく、ある仕掛けによってユーザー自身が気付かないうちに引き起こされた現象なのである。その仕掛けとは、CSRF（Cross-Site Request Forgeries）と呼ばれる攻撃手法の一種だ。 編集部注： 現在、「はまちちゃん」トラップは、mixi運営者により対策されています。上記のサンプルは、mixi風に再構成したものです。 本稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。また、本稿を利用した行為による問題に関しましては、筆者およびアイティメディア株式会社は一切責任を負いかねます。ご了承ください
[ThinkIT] 第2回：セッション管理 (1/4)
Webアプリケーションを実装するにあたり、複数の画面を遷移してひとつの取引（トランザクション）を行うケースは非常に多く見られます。ECサイト上での取引を例に取ると、図1のような流れが一般的ではないでしょうか。 ここで言われる取引（トランザクション）は、ECサイトというサイトの特性におけるビジネスロジック上のトランザクションであって、HTTPというプロトコル上ではひとつの画面を遷移する毎に最低一回のトランザクションが発生します。 画面遷移毎に利用者から送りつけられる要求が複数回におよぶということは、HTTPトランザクションが複数回発生するということです。この場合、Webアプリケーション側では、一番最初に「商品をカートに入れる」ところから始まり「取引完了」までの間、リクエストを送ってくる"主"を何としてでも特定しなければ、他人がカートに放り込んだ商品が自分の手元に送付されてしまうような状況を招
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
