管理職サラリーマン。

様々な職種を経験してきた中途半端な管理職サラリーマンが贈るブログ

【超入門者向け】データベース(DB)のトランザクションを張るとは?

データベース(DB)は、IT業界にいると必ず言葉にしますよね。

この業界にいると、「DB(デービー)」と言ったりします。

また、この記事ではデータベースと書くと長いのでDBと略します。

IT業界で、しかもエンジニア職に着任したらDBから避ける方が難しいくらい、DBについては触れる機会が出てくるはずです。

私もそうでしたが、新卒の頃に「トランザクション」とか「ロールバック」とか「コミット」とかよく分からない用語がDBの話をする時に登場してきて、横文字やめてくれ!となってました。。

特に新卒時代は、DBを直接触る際に、必ず「トランザクション張ってからやれ!」とか言われました。

今回は、DBを触る上でも絶対に通る道「トランザクションを張る」ことの目的が、DBの超入門者に分かって頂ければと思って書いてみました!

1. そもそも「トランザクション」とは

トランザクションとは、「1つ以上の処理(更新、削除など)の単位」となります。

つまり、1つの処理でもトランザクション、10の処理でもトランザクション、1000の処理でもトランザクションとなります。

ただし、DB側はどの処理単位がひとまとまり(トランザクション)なのかは分かりません。

つまり、人間側でトランザクションの開始と終了を定義することで初めてトランザクションになります。
※実際にはDBの種類や設定によってもトランザクション開始と終了のしようは異なります

START TRANSACTION;

UPDATE TR_TABLE
SET NAME = 'TEST'
WHERE ID = 1;

UPDATE TR_TABLE
SET NAME = 'TEST2'
WHERE ID = 2;

COMMIT;

上記の例では、
トランザクション開始の合図: 「START TRANSACTION;」
トランザクション終了の合図: 「COMMIT;」
となります。

これがトランザクションになります。 ちなみに、コマンドは利用するDBによっても異なりますので、あくまでも一例として捉えてください。

「コミット(COMMIT)」がここで出てきましたね。

2. コミットとは

コミット(COMMIT)とは、トランザクションを終了させる処理を指します。

つまり、このデータ操作でおしまい!ってなったら、コミット(COMMIT)しましょう。

コミット処理が終了した段階で、DB側はデータ更新されます。

つまりコミットするまではDB側のデータは更新されません。

ここがポイントなんです!!

データ操作した後にselect(検索)してみて、「あっ、やばい。対象レコード以外も更新しちゃった!」なんてことが発生しても、コミットしなければデータ更新されてないので焦らなくて大丈夫。

3. ロールバックとは

前章の最後に書いた、
データ操作した後にselect(検索)してみて、「あっ、やばい。対象レコード以外も更新しちゃった!」なんてことが発生した時には、ロールバック(rollback)の出番です!

ロールバック(rollback)することで、コミット(COMMIT)時点までデータ操作を取り消すことができます!

コミット(COMMIT)しなければ、実際にはデータ更新されてないので、ロールバック(rollback)しちゃえばオッケーです。

4. トランザクションを張るのはなぜか

4.1 ACID特性でデータを正しく守る

トランザクションを張らないとデータの不整合が起こる場合があります。

Aさんの預金残高10万円で、Bさんの預金残高5万円の例を考えてみましょう。

  1. AさんがBさんに1万円を振り込み
  2. Aさんの預金残高を9万円(10万円-1万円)に更新
  3. Bさんの預金残高を6万円(5万円+1万円)に更新

2の処理は終了していて、3の処理中で障害発生したらどうでしょうか?

Aさんの残高が減っただけで、Bさんの残高は変わりません。これは大問題ですよね?

一連の処理セットが全て行われていない事象が発生します。

これを防止するのがACID特性と言われるもので、トランザクションを張る目的となります。

ACID特性とは、Atomicity(原子性)、Consistency(一貫性)、Isolation(分離性)、Durability(永続性)の頭文字を取って名付けられています。

  • AさんからBさんへの振り込みが一連の処理として行われる:「原子性」
  • Aさんから引かれた金額とBさんに振り込まれた金額が一致する:「一貫性」
  • Aさんから引かれる処理が他の処理により侵されない:「分離性」
  • トランザクションが終了した後の状態は、障害などがおきたとしても、その状態に変化はない:「永続性」

分かりやすい銀行振込みの例を出しましたが、トランザクションによって意図したデータ処理が守られているのはお分かり頂けましたでしょうか。

4.2 DB作業時のミス防止

結局は、コミット(COMMIT)しなければデータ更新されません。

そのため、いわゆる破壊系の処理をした際にちゃんとselectで確認して問題なければコミット(COMMIT)することができます。

(例)新卒の入門者レベルのDB作業ミス

  • まだコマンド打っている途中なのに誤ってEnterを押してしまった
  • 1行づつコピペでコマンドを入力していたが改行が誤って入ってしまい、確認前にデータ処理行われた
  • selectだけのつもりでトランザクションを張っていなかったがその後update処理もやってしまった

こんな感じのミスは私も見たことがあります。

いずれの場合も、意図したものとは異なるsql文を入れてしまっていなればインシデントにはなりませんが、意図したものと異なる命令文を実行した瞬間にインシデント発生という重大事故になってしまいます。

トランザクションを張って、明示的なコミット(COMMIT)をする運用であれば、ロールバック(rollback)できるのでインシデントは発生しにくい運用になると考えています。

お名前ドットコムのドメインが利用制限になった話

6月27日に「【重要】[お名前.com]ドメインの利用制限について」という件名のメールが届きました。

どういうこと?と混乱しながらも、Webサイトにアクセスしてみると、すでにアクセスできない状況でした。 そして、Google Analyticsで調べてみると、6月28日から完全にアクセスがないことが判明しました。

同じ事象が発生した方も、この流れで解消できると思いますので、ご参考にまでに。

対応時系列

6/29 なぜか本ブログにアクセスできないことが発覚!

6/29 - 7/1 時が解決してくれると楽観視して放置。

7/2 全然復旧しないじゃん!と思い、お名前.comから何か届いてないかメールを漁る。そして6/27に送られて来ていた利用制限しましたメールを発見。

7/2 Whois確認。ブラックリスト確認。ブラックリストの登録解除依頼。

7/3 ブラックリストから登録解除された。お名前.comに利用制限解除のメールを送る。

7/4-7/7 何も起こらない。

7/8 利用制限の解除完了。完全復旧。

[6月27日] お名前ドットコムから届いたメールの中身

件名: 【重要】[お名前.com]ドメインの利用制限について

突然、上記件名のメールが送られてきました。

こんな怖い内容が記載されてました。

お客様のご利用されているドメインにつきまして、ドメインの データベースを管理する上位機関(以下レジストリ)より、 ドメインの品質や安定性に影響を及ぼす恐れがある不正利用が疑わ れる該当のドメインに対し、利用制限を行う旨の連絡がございました。

Whoisを確認してくださいとのこと。

利用制限の解除には、ドメインのWhois情報の正確性、メール配信や、 ホームページ、ブログなどドメイン利用状況における登録者の正当な 意図が確認できる情報の提出が必要となります。 つきましては、Whois情報をご確認いただき、正当な意図が確認でき る情報のご提出をお願いいたします。

そして、ブラックリストに登録されていれば、解除してくださいとのこと。

なお、対象ドメイン名が以下の各サイト上にてブラックリストとして 登録されている場合、まずは各サイト上でのブラックリストから除外後、 制限解除依頼をお送りください。 Spamhaus: https://www.spamhaus.org/lookup/ VirusTotal: https://www.virustotal.com/en/ Google Safebrowsing: https://www.google.com/transparencyreport/safebrowsing/diagnostic/ SURBL: http://www.surbl.org/surbl-analysis URIBL: https://admin.uribl.com/

最後に、以下の情報をお名前.comに送って利用制限の解除申請をしてくださいとのこと。

■ドメイン利用状況 ドメイン名: お名前ID: □ホームページ、ブログなどをご利用の場合 公開目的: 公開内容: 該当URL : □メールをご利用の場合 送信目的: 送信内容: 1日あたりのメール送信数: 受信者が許可していない配信がされていないか: 不特定多数に送信されていないか: 配信停止手続きは正常になされているか: □ドメイン登録のみの場合 今後の利用目的: 今後の利用内容:

やったこと① Whois情報の正確性の確認

これは、初回登録時にWhois情報は氏名や住所などを正確に登録している記憶がきちんとありました。

念のため、お名前ドットコムの管理画面にログインし、Whois情報を再確認し、問題ないことを確認しました。

実際にやったこと 1. 手順の確認(https://www.onamae.com/guide/p/28 2. お名前ドットコムの管理画面にログイン 3. Whois情報の内容を確認 4. 問題なし!!

ちなみに、Whois情報公開代行サービスを設定したままです。 これを設定しないと、Whois情報に登録した情報が、そのまま公開されてしまい、氏名や住所などがバレてしまいますからね。

ただし、メールの中身にこんな記載がありました。

Whois情報公開代行サービスを設定されている場合、 レジストリより不正利用とみなされやすいため、解除いただく ことをお薦めしております。 ■Whois情報公開代行サービス解除方法 http://www.onamae.com/guide/details.php?g=22

ただ、解除するデメリットが大きいので、焦って解除せずに他のトラブルシュートを全てやった結果、ダメだったら解除するという流れの方がよいです。

やったこと② 各種ブラックリストに掲載されていないか確認

色々と調べてみると、何もしていないのに、普通のブログなのに、突然ブラックリストに載ってしまうことがあるという記事を散見しました。

もしかすると、本ブログもブラックリストに掲載されてしまっているのか!?との懸念が。。

実際にやったことをご紹介します。

各サイトで、自身のドメインを入力し、ブラックリストに載っているか調査。

Spamhaus: https://www.spamhaus.org/lookup/ VirusTotal: https://www.virustotal.com/en/ Google Safebrowsing: https://www.google.com/transparencyreport/safebrowsing/diagnostic/ SURBL: http://www.surbl.org/surbl-analysis URIBL: https://admin.uribl.com/

Spamhausの例) 赤枠に、自身のドメインを入力し、lookupをクリックします。

下記キャプチャはOKパターンですが、この赤枠で囲まれているところが、

赤字<ドメイン名> is listed in the DBL

となっているとアウトです!!

なんとブラックリストに載ってしまっていることが判明!!

上記の手順で確認したところ、pdm.tokyo is listed in the DBL となっていて、完全にアウト!ということを悟りました。。

Spamhaus以外は白、Spamhausにだけブラックリストに載ってました

これが原因だったかと思い、複雑な気持ちでしたが、原因が分かってスッキリしました!

[7月2日] やったこと③ Spamhaus に登録解除依頼

Webから解除申請をした翌日には解除されました! すごいスピーディな展開にビックリしました!!

ちなみに、Spamhaus からは6/20から登録されてたよ!という内容が来てました。 そのため、ブラックリストに登録されてから、1週間ほどでアクセス不可になるということが分かりました。

  1. [7月2日] Webから必要情報を入力し、解除依頼を申請
  2. [7月2日]メールで結果が来る
  3. [7月3日]解除完了

[7月3日] やったこと④ お名前ドットコムに利用制限の解除依頼

  1. [7月3日] メールで必要情報を入力し、解除依頼を申請
  2. [7月5日]メールで結果が来る
  3. [7月7日]全然解除されないので、痺れを切らして、再度問い合わせ
  4. [7月8日]メールで回答が来る
  5. [7月8日]解除完了

さいごに

突如として、本ブログにアクセスできない状況となりましたが、手順に従って各種申請をすることで、2週間はかかりましたが、無事に復旧することができました。

お困りの方の参考になれば幸いです!

【サルでも分かる】PHPでクッキー(Cookie)を実装してみる

クッキー(Cookie)について2回に渡り、取り上げてきました。

前回の記事は、こちら

前々回の記事は、こちら

ただ、実際に実装してみないと具体的なことは分からないものですよね。
ということで、今回はPHPを使ってクッキーの簡単な実装について触れます。

PHPでクッキーを実装してみる

サンプルコード name.php

<?php
setcookie(‘username’,’hatena’,time()+60*5);
echo $_COOKIE[‘username’];
?>

各行の説明をしていきます

  • setcookie(‘username’,’hatena’,time()+60*5);
    • usernameという箱に、hatena という名前を格納
    • timeに関しては、60(s)×5(m)ということで、クッキーの有効期限を5分と設定
    • timeに関しては、設定しなければ、ブラウザを閉じるまで保持
    • 仮にクッキーの有効期限を1週間にしたい場合には606024*7といった具合に変更が必要
  • echo $_COOKIE[‘username’];
    • クッキーに格納した情報を分かりやすくブラウザに表示させているだけです

ブラウザから実際にアクセスしてみる

初回アクセス前のブラウザ(FireFox)のクッキー確認画面

f:id:virtual-coin:20171121164034p:plain

初回アクセス後のブラウザ画面

初回アクセス時にはクッキーはない状態でアクセスするので何も表示されません

f:id:virtual-coin:20171121165126p:plain

初回アクセス後のブラウザ(FireFox)のクッキー確認画面

f:id:virtual-coin:20171121164951p:plain

初回アクセス後のPC内のFireFoxクッキーファイル

下記のようなsqliteファイル内にクッキー情報として1レコード追加されています。
ちなみに、"1511241089"という文字列の箇所は時間(unix時間)を示しています。
これを変換すると、クッキーの有効期限である
"2017年11月21日 14:12:09"となります

sqlite> select * from moz_cookies;
1|<ホスト名 or IPアドレス>||username|hatena|<ホスト名 or IPアドレス>|/|1511241089|1511240830368877|1511240790472542|0|0|0

2回目のアクセス時のブラウザ画面

クッキーに格納したusernameである’hatena’が表示されるのが確認できます

f:id:virtual-coin:20171121172808p:plain

クッキーを削除してみる

サンプルコード delete.php

<?php
setcookie(‘username’,’hatena’,time()-1);
echo $_COOKIE[‘username’];
?>
  • setcookie(‘username’,’hatena’,time()-1);
    • usernameという箱に、hatena という名前を格納
    • timeに関しては、『-1』とすることで、クッキーを削除することが可能
    • ちなみに、『-1』とは過去の時間を示しているため、即時削除となる
  • echo $_COOKIE[‘username’];
    • クッキーに格納した情報を、分かりやすくするために、ブラウザに表示

ブラウザから実際にアクセスしてみる

初回アクセス後のブラウザ画面

初回アクセス時にはクッキーはない状態でアクセスするので何も表示されません

f:id:virtual-coin:20171121165126p:plain

初回アクセス後のブラウザ(FireFox)のクッキー確認画面

f:id:virtual-coin:20171121173414p:plain

初回アクセス後のPC内のFireFoxクッキーファイル

下記のようなsqliteファイル内にクッキー情報として1レコード追加されています。
ちなみに、"1511241129"という文字列の箇所は時間(unix時間)を示しています。
これを変換すると、クッキーの有効期限である
"2017年11月21日 14:12:09"となります

sqlite> select * from moz_cookies;
1|<ホスト名 or IPアドレス>||username|hatena|<ホスト名 or IPアドレス>|/|1511241129|1511241129823435|1511241129561390|0|0|0

2回目アクセスとして "delete.php" にアクセス

delete.phpにアクセスした際のブラウザ画面

初回アクセス時に保有していたクッキーを提示しているので
この時にはブラウザにクッキー情報が表示されます

f:id:virtual-coin:20171121173814p:plain

delete.phpにアクセスした後のブラウザ(FireFox)のクッキー確認画面

削除されているので何も表示されません

f:id:virtual-coin:20171121173914p:plain

delete.phpにアクセスした後のPC内のFireFoxクッキーファイル

何も表示されていない=sqliteファイルからも削除された
ということが分かります

sqlite> select * from moz_cookies;
sqlite>

如何でしたでしょうか? 今回のクッキーに関する実装の触りはここまでです。 また、機会があったら、いつか、、、記事にしたいと思います!

【徹底解説】セッションクッキー(Session Cookie)と永続的クッキー(Parmanent Cookie)

今回は、クッキー(Cookie)をより詳細に取り上げていきます。

↓前回の記事はこちら↓ www.pdm.tokyo

前回は、アフィリエイトで使われるクッキーについて、ドメイン観点での種類について簡単な説明をしました。 ファーストパーティクッキーとサードパーティクッキーについてですね。

実はファーストパーティクッキーには、セッションクッキーを利用する場合があったり、セッションクッキーを利用せず永続的クッキーを利用してするケースがあります。 また、サードパーティクッキーも同様で、どのようなクッキーを利用するかは様々です。

今回は、そんなセッションクッキーと永続的クッキーについて、解説していきます。

1. 改めてクッキーについて

クッキー(Cookie)は、Webサービスの利用ユーザーにとっては分かりにくいものですよね。

理由としては、HTTPヘッダーというヘッダーに格納される情報で、意図的に確認しない限り、ユーザには見えないからです。

さらに、クッキーがくせ者な理由は、同じことを指すのにもかかわらず、サーバー側/ブラウザ側で利用される言葉が異なる点です。 サーバーではセッションID、同じ情報をブラウザではクッキーやセッションクッキーと呼んでいます。

さらにさらに、前回のブログでも取り上げた通り、技術的には同じ仕組みのクッキーでも、ファーストパーティクッキーと呼んだり、サードパーティクッキーと呼ぶケースもあります。

これでは、分からないというのは当然ですよね。。。

2. セッションクッキー

セッションクッキーとは?

Webブラウザで、あるショッピングサイトを訪問したとします。

このときは、Webブラウザはクッキー情報はない状態でアクセスします。

ショッピングサイトのサーバは、初めて訪問をしたユーザに対して、そのユーザのログインIDとパスワード情報を紐づけたセッションIDというのを発行します。

サーバ側では、そのセッションIDをデータベースに保存しておきます。

↓データベース内の情報↓

ユーザ パスワード 有効期限 セッションID
hatena pass 60分 1234567890abc

これで、セッションIDを見るだけで、どのユーザか判別することができます。

基本的には、サーバー側はあくまでもこのセッションIDを保持するだけです。

ここまでの説明では、まだクッキーというキーワードは出てきてませんね。

続いて、サーバーはセッションIDを付与したHTTPヘッダーをWebブラウザ(ユーザ)に返答します。

Webブラウザは、そのセッションIDをセッションクッキーとして保存しておきます。

ここで、初めてクッキーというワードが出てきました。

セッションクッキーは1234567890abcというランダムな値となります。 もちろん、サーバ側で保存されているセッションIDと同一のものとなります。

ショッピングサイトに滞在している間は、WebブラウザはずっとセッションクッキーをHTTPヘッダに付与してアクセスし続けます。

なぜ、セッションクッキーが必要なのか?

一見すると、ショッピングサイトのサーバ側がずっとそのユーザのログイン状態を保持していれば問題はありませんよね?

ところが、Webサイトで利用されるHTTPというのはそのような仕組みのプロトコルではありません。

HTTPはセッションレスという状態を持たないプロトコルです。 TCPはセッションを持ちますが、その上位のHTTPは持ちません。

そのため、仮にセッションクッキーを持たずにWebアクセスをしたとすると、Webサーバ目線では同一のユーザからのアクセスが全て一見さん(異なるユーザ)に見えてしまいます。

これをショッピングサイトの例で説明しますね!

ユーザが「購入ボタン」を押して商品購入を進めようとしても 次のページに遷移した際に、サーバ側はユーザ(セッションクッキー)の過去の行動を覚えていないため ショッピングカートは空っぽの状態になってしまいます。

こんなショッピングサイトなんか、絶対に利用したくないですよね? 何度やっても購入までいかないなんて。。

ということで、実際の使われ方は色々ありますが、セッションクッキーは今のWebサービスにおいては非常に重要な役割となっています。

セッションクッキーの有効期限(サーバ側)

セッションクッキーは、セッションIDという名前でサーバ側に保存されると説明しました。

つまり、サーバ側(Webアプリケーション)で、このクッキーの保存期間を自由に定めることができます。

保存期間を無限にすることもできます。

また、サーバ側でクッキーの有効期限が10分と設定されていても、先にブラウザ側でセッションクッキーを削除することも可能です。 この場合には、ブラウザはクッキーなしでサーバにアクセスするので、一見さん扱いでのアクセスになります。

そのため、有効期限については、サーバ側とブラウザ側の双方の設定によるということが実際のところです。

セッションクッキーの有効期限(ブラウザ)

セッションクッキーは、ブラウザ側のメモリに一時的に保存されます。

ここがキーポイントとなります。

セッションクッキーは、メモリへの保存なので、ブラウザを閉じるとセッションクッキーが消えます。 ※ブラウザのタブを閉じてもセッションクッキーは残ります。

つまり、セッションクッキーを削除したいということであれば、ブラウザを閉じれば完了となります。

ただし、ブラウザごとに動きが違ったりするので設定画面よりクッキーは制御するのがより確実です。

Chromeの場合には Chromeの設定で「起動時」に「中断した箇所から続ける」を選択している場合には 一時ファイルとして保存されているのか ブラウザを閉じてもセッションクッキーは保持されますので注意が必要です。

その場合には Chromeの設定で、[ブラウザを終了するまでローカル データを保存する] にチェックすると、中断した箇所から続けてもセッションクッキーを消すことができます。

セッションクッキーについて、イメージを掴むことはできましたでしょうか?

3. 永続的クッキー

永続的クッキーとは?

永続的を英語でいうとParmanent(パーマネント)ということから パーマネントクッキーと称されることもあります。 セッションクッキーは、ブラウザを閉じると削除されますが、 永続的クッキーは、ブラウザを閉じても削除することはできません。

さらに、PCやスマホをシャットダウンさせて、その後ブラウザを立ち上げても、Cookieを使うことができます。

このようなことから、永続的クッキーと呼ばれています。

永続的Cookieの保存方法

セッションクッキーは、クッキー情報(セッションID)をブラウザのメモリに保存されます。

メモリというのは、基本的には作業を終了させるとデータがなくなりスッキリします。 ブラウザのメモリだけではなく、PCのメモリについても同様です。

では、ブラウザを閉じても永続的クッキーが消えないというのは、メモリ以外のどこかに保存してあるということになります。

さぁ、どこでしょうか??

答えは、テキストファイルやその他形式のファイルとして保管されます。

そのため、実体ファイルがあるので、ユーザ側もその中身をテキストのように閲覧できたり、編集したり、削除できてしまうものとなります。

例えば、デスクトップ上にメモ書きしたテキストファイルは、PCを落としても勝手に削除されたりはしないですよね。 それと同じで、削除されないですし、編集も可能です。

永続的クッキーの保存場所は?

場所としては、OS、ブラウザ、それらのバージョンごとに異なります。

またファイルの種類も単なるテキストファイルであったり、Sqliteと呼ばれるタイプだったりします。

エクスプローラで下記のパスを検索してみてください。 バージョンによっては保存場所は異なるのでご了承ください。

  • Windows+FireFoxの例
%APPDATA%\Mozilla\Firefox\Profiles\xxxxxxxx.default\cookies.sqlite
  • Windows+Chromeの例
%UserProfile%\AppData\Local\Google\Chrome\User Data\Default
  • Windows+IE 11の例
\AppData\Local\Microsoft\Windows\INetCookie

sqlieteファイルの閲覧方法

そのままテキストエディタで開くと見にくいものです。 sqliteはデータベースの名前で、そのデータベース用のファイル形式です。 SQLite Expert Personalなどのフリーソフトにて閲覧することができます。

クッキー情報は他のブラウザとの共有するのか?

Cookieの保存場所をご紹介した通り、ブラウザごとに形式や保存場所が異なります。

そのため、クッキーはブラウザ間で共有することはできません。

つまり、クッキーはOSではなく、ブラウザのものということになります。

サーバから送られる永続的クッキーの正体

ブラウザがWebサイトに訪問したら、そのWebサイトのサーバからのHTTPレスポンス内に以下のような情報が付与されます。

Set-Cookie: クッキー名=クッキー値; expires=有効期限; domain=ドメイン名(サーバ名); path=パス; secure

これが、クッキーの正体です。

各項目は、下記のようになっています。

  • クッキー名 = クッキー値 ブラウザーに保存したい変数名(クッキー名)とその値(クッキー値)をセットします。スペース、カンマ、セミコロンは含まれてはいけません。そのため URL エンコードをする必要があります。(後述) クッキーをセットする際には、この項目のみが必須です。

  • expires(有効期限) クッキーの有効期限をセットします。有効期限は GMT で指定します。フォーマットは以下のとおりです。

Wdy, DD-Mon-YYYY HH:MM:SS GMT

有効期限が省略されると、テンポラリークッキーとして扱われます。つまり、ブラウザーを閉じた時点で、そのクッキーは無効となります(つまり、セッションクッキーと同様の扱いがなされます)

  • domain(ドメイン) セットしたクッキーが送信されるドメインを指定します。サーバ名で指定すれば、指定サーバへのアクセスの時だけセットしたクッキーを送信します。ドメインが省略されると、そのときアクセスしたサーバ名がセットされます。

  • path(パス) セットしたクッキーが送信されるパスを指定します。パスが省略されると、アクセスしたリソース(HTML、CGI)のパスがセットされます。

  • secure (secure属性) この項目が指定されていると、アクセス先が SSL などのような安全なサイトの場合のみにクッキーを送信するようになります。ドメイン、パスが一致したとしても、アクセス先が安全とみなされないと、クッキーを送信しません。

永続的クッキーのセキュリティ問題

一般に、永続的クッキーは以下のようなセキュリティ課題を抱えているとされています。

セキュリティリスク
  • クッキーは、ファイルとして保存されるので改ざんされる恐れがある
  • ファイルが盗まれると、セッションハイジャックされる恐れがある
  • クラスサイトリクエストフォージェリ攻撃をされる可能性がある
  • クッキーに個人情報を付与してくるWebサイトもあり、その場合に中間者攻撃されると情報が抜かれている恐れがある
  • 端末紛失時に永続的クッキーファイルをコピーされ、他の端末で使用される恐れがある(端末が見つかったとしても悪用され続ける可能があります)
サーバ側でできる対策
  • secure属性を使い、平文ではクッキーを送れないようにする。そうすることで中間者攻撃されても容易には解読できない。
  • クッキー自体に個人情報(ユーザ名など、パスワードは絶対NG)を載せず、十分大きな乱数によるセッションIDを用いる。
ブラウザ側(利用者側)でできる対応
  • ブラウザにて、定期的にクッキーを削除する。(代償として便利さを失いますので、現実的ではないかも)
  • 全ては難しいので、オンラインバンキングなど金銭に絡む利用サイトや、ログインする必要のあるWebサイト(つまり個人情報をすでに渡している)に関しては、クッキー利用法についてポリシーを読んでおくことをお勧めします。(読んだところで理解するのが難しいので、これも現実的ではないかも。信頼できる企業のWebサイトかどうかというのが分かりやすい指標かなと考えてます)
  • 上記のようなWebサイトにおいてはHTTPのみのサイトは利用しないようにする。

長文となりましたが、以上となります。 セッションクッキーと永続的クッキーについての解説でした!

Cookie(クッキー)を理解 - アフィリエイトでも使用されているクッキーの基本解説

アマゾンや楽天アフィリエイトではCookie (クッキー)というのを利用したアフィリエイトの仕組みを使っています。

今回は、アフィリエイトでも使われているクッキーの基本解説をしていきます。

クッキーを理解するには ファーストパーティクッキー(first-party Cookie)とサードパーティクッキー(third-party Cookie)というのを理解する必要があります。

サードパーティという用語は、ITの世界ではよく登場するワードですよね。 第三者という意味です。

両者の違いは、とてもシンプルでクッキーの発行元がどこのドメインなのかで決定します。

では、実際にそれぞれのクッキーについてみていきます。

1. まずはファーストパーティクッキー

例えば、企業AのWebサイト(aaa.example.com)に訪れたとします。 企業AのWebサイトにはバナー広告が表示されており、バナー広告として楽天アフィリエイトの広告が貼ってあったとします。

よくある構成ですよね。

この時に 企業AのWebサイト(aaa.example.com)から発行されるクッキーをファーストパーティクッキーといいます。

ちなみに、発行されるといってもWebサイトを訪れているユーザー側は気づかないところで自動的に発行されています。

訪れているWebサイト自身から発行されるクッキーがファーストパーティということになります。

2. つづいてサードパーティクッキー

Webサイト(aaa.example.com)を訪れている際に、そのWebサイト以外のドメインから発行されているクッキーをサードパーティクッキーといいます。

つまり、Webサイト(aaa.example.com)に訪れた際に、そのWebサイトに貼ってあるバナー広告(bbb.example2.com)をクリックしたとします。 そのクリックの際に、発行されるクッキーは、Webサイト(aaa.example.com)が発行したクッキーではなく、バナー広告(bbb.example2.com)から発行されるクッキーとなります。 そして、このような訪れているサードパーティクッキーと呼びます。

サードパーティクッキーが発行されるには 企業AのWebサイトに訪れた際にバナー広告をクリックする必要があります。 バナー広告をクリックすると そのまま広告主のWebサイトに飛んでいるわけではなく ASP事業者のサーバに行き、そこでクッキーが発行されます。 ここで発行されるのがサーバパーティクッキーといいます。

そのクッキーの発行と同時に広告主のWebサイトにリダイレクトされるというのが一連の流れになります。

ユーザからしてみると一瞬の出来事なので、裏ではこのような動作をしているなんて知る由もないですよね。

3. ファーストパーティクッキーの特徴

Webブラウザは、クッキーをWebサイトのサーバに送るか判断する際に、発行元のドメインと一致するかどうか確認します。

aaa.example.comのクッキーを bbb.example.comに送ったりはしません。

その逆で、バナー広告をクリックした時に発行されるbbb.example.comのクッキーをaaa.example.comに送ったりはしません。

ユーザからしてみても 企業AのWebサイトを訪れている際に aaa.example.comのクッキーが送られても想定の範囲内なので 特に問題ないですよね。

そのためプライバシー上も問題ないように見えるため、Webブラウザ側もブロックするケースはほとんどありません。

※ブラウザの設定で全てのクッキーをブロックするにすると、さすがにブロックされますが、そうするとWebサイトによってはかなり不便になるので推奨しません。

4. サードパーティクッキーの特徴

標準ブラウザでは最近、初期設定でサードパーティクッキーをブロックする設定が段々と多くなってきているように感じます。

そのため、これまで解析用で使用されていましたが、今後は淘汰される運命になりつつあるのではないかと思っています。

ほとんどのASP事業者はサードパーティクッキーを利用していますが、段々とブラウザ側でブロックされることも多くなり、ファーストパーティクッキー方式に移行していていかないといけないというのが現状ではないでしょうか。

サードパーティの特徴としては 直接、bbb.example.comを訪れたわけではないのに、バナー広告をクリックしただけでクッキーが送信できることです。

また、サードパーティクッキーは永続的クッキーを使用するケースが多いです。

そのため、クッキーの有効期限が切れるまでASP事業者サーバだけではなく、ブラウザでも保持できます。

例えば、楽天のアフィリエイトの広告収入の仕組みとしては成果報酬の方式です。

ユーザがバナー広告をクリックしてから実際に購入するまでの時間がクッキーの有効期限内なら、成果報酬を受け取れます。

大分、時間が経過したり、クッキーを保持しているブラウザと異なるブラウザから、ショッピングした場合には、あの時にバナー広告をクリックしたユーザと特定できないので、成果にはなりません。

5. まとめ

ファーストパーティクッキーは訪れたWebサイトが発行するので予想通りなクッキー。

サードパーティクッキーは訪れていないサーバが発行するので知らないうちに発行するので予想外なクッキー。

ということで覚えておきましょう!