コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

Cookie の SameSiteと関連の設定に関してざっくりまとめる

ざっくりまとめ

SameSiteCookieと呼ばれたりするこの要素は何なのかまとめる

SameSiteとはなにか

SameSiteとは直訳すると「同じサイト」ということだが、その同じサイトであるということの概念は以下のページにまとめられている。

「same-site」と「same-origin」を理解する

上記の内容からSameSiteは「eTLD+1が同じサイト」となる。なおeTLDという言葉の意味に関してはこちらを参照のこと

対する概念としてのCrossSite

SameSiteが同じサイトを示す言葉だが、この言葉の反対の「異なるサイト」ということを表すための言葉が CrossSite となる。

Cookieが送られる条件

セットされたどのアクセスのときに送られるかは、Set-Cookie をしたときの属性が影響する。影響する属性は以下の3つ。

  • Domain属性
  • Path属性
  • SameSite属性

Domain属性

Domain属性は未指定の状態だと「Cookieを設定したホストと同じホスト」になる。

逆に値を指定すると指定したドメインを含むドメインに送信されるようになり、未指定時より条件をゆるくすることができる。

詳しくは以下の記事などを参照。

Path属性

Path属性は、設定した値のパスにのみCookieを送るための設定。

この属性が安全性に寄与するかなどの話題は今回の本筋ではないので省略するが以下の記事を参照していただきたい。

SameSite属性

SameSiteは前段で説明したとおり、SameSite以外のリクエスト対してCookieを送るかどうかを判断する。

SameSite属性に設定できる値のパターン

設定できる値は3つある。

  • None
  • Lax
  • Strict

Strict

一番強い設定で、SameSiteに該当するサイトのみCookieを送信する設定。そのためクロスサイトになるドメインには送信されない。

そのためaタグで遷移する場合もGETリクエストになるため、遷移先のドメインが異なる場合に初手はCookieが送信されない。

Lax

MDNの説明を抜粋すると以下の通り

画像やフレームを読み込むリクエストのようなクロスサイトリクエストではクッキーを送信しませんが、ユーザーが外部サイトから元のサイトに移動するとき（例えば、リンクをたどるとき）には送信されることを意味します。 - Set-Cookie - HTTP | MDN

上記の通りStrictを緩和させたもので、ページを遷移する場合のみCookieを送信する。

もともとクロスサイトスクリプティング防止の目的が強い仕様のため悪意のあるサイトからのPOSTリクエストの際にブラウザのCookieが乗らないLaxの設定であればやりたいことは満たせることになる。

この設定はメジャーブラウザ規定の設定。

None

SameSite実装前と同じ挙動になり、どのような場合でもCookieが送られる。

Domain属性とSameSite属性の違い

パッと見すると似たような話に見えるDomainとSameSiteだが2つは異なり分類としては以下のようになる。

  • メインとなるページを描画する際の情報取得に関してのドメイン設定が Domain
  • リソースの取得やformアクションなどメインとなるページ外へのCookie送信の設定が SameSite

参考サイト

サードパーティCookieはどういう仕組みでセットされるのか簡素に流れをまとめる

ざっくりまとめ

ググっても技術的な話があんまりでてこないのでまとめる。

出典

以下の2サイトの説明をミックスしました。

Cookieの仕組み

Cookieはページのレスポンスとして Set-Cookieで送信され、その情報を受け取るとブラウザは記憶して、送信してきたドメインへのアクセスに対しては情報を送信する。

シンプルにそのページを構成する情報がすべて同一のドメインであればそのドメインで話は完結する。しかしながらimgなどで指し示すURLが別のドメインの場合があるのでその場合にも Set-Cookie される。このようにページの主体となっているドメインと異なるドメインからのレスポンスでセットされたCookieが俗に言うサードパーティCookieにあたる

わかりやすい例

例えば https://watashi.example.com/ のページ内に画像を表示するimgタグ <img src = “https://hoka.example.jp/cat.png”> があるとします。

このとき、hoka.example.jp は画像を返却するレスポンスに画像のidをCookieとしてセットするようにしており、そうなると https://watashi.example.com/ の表示処理の中で hoka.example.jp のCookieがセットされることになる。例としては以下のイメージ。

hoka.example.jpは違うURLだけどCookieを登録することができる

このCookieがセットされると2回目以降のアクセスはCookieがhoka.example.jp に送られるようになる、以下の画像のイメージ。

2回目以降はCookieが送られる

このCookieはhoka.example.jpのリクエストの際にはすべて送られるので、別のサイト https://othersite.example.uk/ でimgタグ <img src = “https://hoka.example.jp/cat.png”> が配置されていても送られる。以下のようなイメージ。

othersite.example.uk でも imgタグの先のアドレスは同じなのでCookieが送られる

このため、どこか他のページでhoka.example.jpにGETリクエストを一回でも送っていれば、他のサイトでもその見た人を特定することができる。

参考サイト

ソフトウェアテストの考え方をざっと振り返りたいときに読みたいスライド『テストコードを書き始める前に考えるべきテストの話（2021年版）』

テスト/QA スライド・記事回顧録

スライド回顧録です

対象のスライド

speakerdeck.com

みどころ

ソフトウェアテストというものが人によっては「やらなければいけないもの」のようなイメージで書き始めるケースが多いため、そういう人はソフトウェアテストの本質をあまり理解しないでテストをやっていることもあり得ると思っています。そういう人に「テストってなんでやるんだっけ」というところから実際の手法の考え方、アジャイルテスティングの考え方まで一気通貫で説明することができる資料となっていると思います。

また、テストの本質を理解しつつある人でもちゃんとしたQAの知識をベースにこの資料は説明されているので、自分自身のアンラーニング的なきっかけとしても活用できるので、折を見て読み返す意味でもとても良い資料かと思います。

関連リンク

出力引数というフレーズに関して2022年時点の意味をざっくり調べ、解釈を整理した

ざっくりまとめ

人によって解釈が違うので改めて調べてみた

出典

良いコード／悪いコードで学ぶ設計入門にて紹介されているフレーズ、出典元の書籍を引用させてもらうと以下の通り

出力として用いる引数を出力引数と呼びます。 - 良いコード／悪いコードで学ぶ設計入門69ページより　

良いコード／悪いコードで学ぶ設計入門―保守しやすい　成長し続けるコードの書き方

良いコード／悪いコードで学ぶ設計入門―保守しやすい　成長し続けるコードの書き方

Amazon

出力引数の源流を調べる

出力引数というフレーズが多く見られるのはC#の記述。C#ではいわゆる参照渡しの一つのパターンとして out 修飾子を使って参照渡しを実現する方法を「出力引数」と呼ばれるケースがある。

C#では参照渡しの方法がいくつかあり、 ref修飾子を使うもの「参照引数」、in修飾子を使うものを「入力参照引数」と呼ばれるケースがあるため、参照渡しというフレーズだけだとどのパターンがあるかわからないので細分化されているものと思われる。

ただこの「出力引数」はインターネット上だと未確認飛行Cさんでの説明がベースになっているようで、Microsoftの和訳ドキュメントなどには登場しない。

出力引数とはどういうものなのか

C#における出力引数配下のようなもの（マイクロソフトのドキュメントより）

int initializeInMethod;
OutArgExample(out initializeInMethod);
Console.WriteLine(initializeInMethod);     // value is now 44

void OutArgExample(out int number)
{
    number = 44;
}

上記のように OutArgExampleのメソッドのなかで変数代入されたないようが、メソッドにセットした引数に影響を及ぼすことができる仕組み。

広義の出力引数を考える

C#においける出力引数とはout修飾子を利用した参照渡しのことであるが、他の言語には ref out inに相当する使い分けはないため「呼び出し元に干渉させる目的の関数の引数」と解釈すると他言語の場合もすんなり理解できると思われる。

関連リンク

Rubyの引数の情報の渡り方(共有渡し)をざっくりまとめる

Ruby ざっくりまとめ

いまいちちゃんと理解していなかったので改めてまとめる

大前提としての値渡し、参照渡し

プログラミング言語の引数の渡り方の話で出てくるフレーズなので説明としては簡素に記述するが

  • 値渡しは呼び出し元の実数値(実引数の値)を呼び出した関数の引数(仮引数)に渡す方式
  • 参照渡しは呼び出し元の引数の保存されている領域の情報元の実数値(実引数の参照情報)を呼び出した関数の引数(仮引数)に渡す方法

Rubyでは参照の値渡し（≒共有渡し）

るびまに以下のような記事がある。

値渡しと参照渡しの違いを理解する

こちらより引用すると

・Ruby (や多くのプログラミング言語) は値渡しである。
・変数が参照 (= メモリ番地) を保持している場合は、それが引数にコピーされる。
・そのため、変数 (実引数) と引数 (仮引数) とが同じオブジェクトを共有することになるので、引数が指すオブジェクトを変更すると、もとの変数のオブジェクトも変更される。
・「変数を変更する」ことと「変数が指すオブジェクトを変更する」ことは別である。

というように値渡しが基本ではあるが、変数に入っている実態数値がセットされているわけではなく、「参照の情報が値渡しされている」という表現になっている

具体的にはどういうことか

純粋な値渡しの例

例えば下記のような処理を書く

def irekae(a,b)
  temp_a = a
  temp_b = b
  a = temp_b
  b = temp_a
end

下記を実行してもaとbの値は入れ替われない。

a = 200
b = 100
irekae(a,b)
pp a
pp b

上記の実行結果は以下となる

200
100

参照の値渡しの例

参照をしている情報を渡しているだけなので、参照先のオブジェクトの中身を変更すると値が変更となる。配列の例は参考サイトにもあるのでオブジェクトの例を下記に示す。

まずは利用するクラスを定義する

class Monoire
  def initialize(value)
    @atai = value
  end

  def set_atai(value)
    @atai = value
  end

  def get_atai
    return @atai
  end
end

そして下記のように利用する

def change_monoire(target)
  target.set_atai(200)
end

temp = Monoire.new(100)
pp "before atai = #{temp.get_atai}"
change_monoire(temp)
pp "after atai = #{temp.get_atai}"

そうすると下記のような出力結果となりtempはメソッドでの処理の影響を受ける。

"before atai = 100"
"after atai = 200"

参考サイト

参照の値渡しと共有渡しに関しては呼び方にいろいろあるので参考サイトを読んで頂くとよさそう。

ランドマークツアーとは何か、ざっくりまとめる

ざっくりまとめ テスト/QA

『Agile Testing Condensed Japanese Edition』に登場したので気になり調べた

言葉の出典

初出はおそらく書籍 Exploratory Software Testing: Tips, tricks, tours and techniques to guide test design とのこと。

そちらがMSDNのサイトで抜粋として紹介されている。

Exploratory Software Testing (探索的ソフトウェア テスト) | Microsoft Learn?redirectedfrom=MSDN)

ランドマークツアーとは

探索的テストにおけるシナリオテストを都市の観光になぞらえて「ツアー」という表現で紹介しているうちのひとつ。

ランドマークツアーはランドマークとなる要素をいくつかピックアップし、そのランドマークをたどる順番をランダムに入れ替えていくつかシナリオをつくる。そしてそのシナリオを実行するテスト。

Webサイトにおけるランドマークツアー

おそらくWebサイトになぞらえた場合、ランドマークとはそのWebサイトの特徴的な機能やページを指し、それをピックアップして異なる順番で実施をすることだと思われる。

通常の型通りのシナリオテストだと開発者やテスターの都合のいい流れでしか確認しないため、ランダムな順番を有意義なかたちで生み出すのがこの手法かと思われる。

関連リンク

アジャイル開発のおけるDB設計に関して迷ったら読み返したい記事「アジャイル開発とデータベース設計 - 変化に対応するシンプルな実装のために必要なこと」

スライド・記事回顧録

アジャイルでどんどん変化するアプリケーションに、永続データをもつデータベースはどう立ち向かうべきかの一つの解法例として。

対象の記事

agilejourney.uzabase.com

みどころ

Userのような見る切り口によって内容が変わるデータに対して、どういうアプローチをするべきかという話が展開されています。多くのWebアプリケーションはリリース後に何かしらのビジネスの改善などで取り扱うデータの切り口が増えることがあるので、その変化に対してどういうテーブル構造がいいのか？という一つの答えになっているので、知識として入れておくといいと思います。

関連リンク

補足

このような単一責任になるようなテーブル設計は不要なデータが発生したときもテーブル削除で対応可能で、新しく増えたときにも対応がしやすいです。ただ、このテーブル設計の手法はテーブルとモデルを同一視するようなActiveRecordパターンなどだとちゃんと触る人の見解が一致していないと容易に意図違いになるので気をつける必要がある。