SetCookieされない件

headers以下でwithCredential: trueをセットしないとつかない

export const signIn = (email: string, uid: string, token: string) => {
  return axios.post(
    `${API_URL}/login`,
    { email: email, uid: uid },
    {
      withCredentials: true,
      headers: { Authorization: `Bearer ${token}` },
    }
  );
};

一方、セットすると当然リクエストヘッダーで飛んでいるし、次のリクエストでもヘッダーを送信している。

export const signIn = (email: string, uid: string, token: string) => {
  return axios.post(
    `${API_URL}/login`,
    { email: email, uid: uid },
    {
      withCredentials: true,
      headers: { Authorization: `Bearer ${token}`, withCredentials: true },
    }
  );
};

↓ログインリクエスト

↓ログイン後のリクエスト

酒井駿

一方、withCredentials: trueオプションを外してリクエストしてみる。

export const signIn = (email: string, uid: string, token: string) => {
  return axios.post(
    `${API_URL}/login`,
    { email: email, uid: uid },
    {
      // withCredentials: true,
      headers: { Authorization: `Bearer ${token}`, withCredentials: true },
    }
  );
};

ヘッダーにはwithcredentails: trueはついている。

↓その後のリクエスト

export const getSubscriptions = () => {
  return axios.get(`${API_URL}/subscriptions`, {
    withCredentials: true,
  });
};

セットできていない(前のクッキーがついている)

クレデンシャルを必要とする場合はこのヘッダがないとブラウザはレスポンスを捨ててしまう
検証する

酒井駿

逆にヘッダーのwithcredentials: trueをつけなくてもCookieはセットされる。
ヘッダーのwithcredentials: trueはAjax通信の際につけるものである。

fetch APIとは明確に区別される。

Fetch API は (ネットワーク越しの通信を含む) リソース取得のためのインターフェイスを提供しています。 XMLHttpRequest と似たものではありますが、より強力で柔軟な操作が可能です。

またMDNによると、Cookieに関する記述として以下のようにある。

fetch() は資格情報の初期化オプションを (include に) 設定しない限り、オリジンをまたいだ Cookie を送信しません。

以下のようにすることで、オリジンをまたいだCookie送信ができるようになる。
axiosではwithCredentials = trueオプションをtrueにすることで以下の設定がなされる。(予想)

request.credentials = "include"

酒井駿

また、MDNに明記がされていないが、AxiosでwithCredentials = trueオプションをつけないとレスポンスでsetCookieとaccess-control-allow-credentials: trueのヘッダーがついているにも関わらず、次のリクエストでクッキーが送信されなかった。

ちなみにaccess-control-allow-credentials: trueがついていないと、クッキーはブラウザに無視される。

10 行目に https://bar.other 向けのクッキーが含まれていますが、bar.other が Access-Control-Allow-Credentials: true (17 行目) をレスポンスに含めなければ、レスポンスは無視されウェブコンテンツで使用できません。

酒井駿

2020年2月4日にGoogle Chrome 80がリリースされ、それにより以下の変更点があった。

SameSiteが未指定の場合、Laxになる。
SameSite属性にNoneを指定する場合はSecure属性が必須になる。

Cookieを送るためには、SameSiteを指定する必要がある。また、Secure属性も必要になる。
→ つまり、ローカルであってもhttps通信をする必要がある。
こちらの記事を参考に対応した。

ブラウザからSSL証明書が有効かどうか確かめれないので警告がでるので設定忘れに注意

なおChrome 80以降でSecure属性を付けずSameSite=Noneを指定した場合、set-cookie自体が無効になる。
これが、setCookieヘッダーが返ってきていたのに、クッキーが送られなかった理由だった

SameSite属性とは

CookieのSameSite属性はStrict Lax Noneの3つの値を取る。
その値により、クロスサイトでの通信でCookieの送信を制御する。

NoneはAサイトに対し、Bサイトからどのようなリクエストがあっても、発行したサイトでCookieヘッダーに含める (Cookieを使用する)という指定になる。

この記事が鬼分かりやすい↓