paw-app - 以前のバージョンの Paw からの Cookie 認証を使用するルートは、新しいバージョンでは機能しなくなりました

Question

別のルートによって設定された認証 Cookie を使用するルートがあります。私は次のように作成しました：

この方法は、新しいバージョンでは機能しなくなりました。Paw は、認証要求からの応答に set-cookie ヘッダーがないことを訴えます。

これは、Paw が Cookie を取得し、他のヘッダーとは異なる方法で処理するようになったためと思われます。この種の認証が簡単になるはずなので、私はこのアプローチを気に入っていますが、残念ながら、期待どおりに機能していません。

新しいリクエストを構成した方法は次のとおりです。

Response Cookiesそのため、以前に設定した Cookieを渡す必要があると思われる動的な値にCookie ヘッダーを設定しました。ドロップダウンから認証リクエストを選択する必要があると思います（実際にCookieを設定するのはこのリクエストからの応答であるためですが、そうするとCookie値が消えます。代わりに、リクエスト値をそのままにしましCurrent Requestた正しい値。

Automatically send cookiesまた、簡単な解決策と思われる設定にも気付きました。リクエストから手動のCookieヘッダーを削除し、これをチェックインしたままにして、リクエストとともにCookie jarからCookieを自動的に送信することを期待していますが、それも機能していないようです。何を試しても、認証が原因で要求が目的の結果を生成できません。

これらのリクエストを構成して、引き続き Paw を使用してセッション認証ルートをテストできるようにする方法を理解するのを手伝ってもらえますか?

Answer 1

Paw (バージョン 2.1 以降) で Cookie がどのように機能するかを理解するのに役立ついくつかのことを次に示します。

1. Cookie は Jar に保存されます

ユーザーが複数の同期セッションを維持できるようにするために、Cookie は jar に保存されるため、セッション (jar) を簡単に切り替えることができます。

jar に保存された Cookieは、要求 (ホスト名、パス、安全性など)に一致する場合にのみ送信されます。

Cookie2.ヘッダーが上書きされない限り、jar からの Cookie はデフォルトで送信されます

ヘッダーを手動で設定するとCookie、jar に保存された Cookie は送信されません。そして明らかに、自動的に Cookie を送信するが無効になっていない限り。

3. 「応答ヘッダー」の以前の使用法はハッキーでした。レスポンス Cookieを使用します。

実際、Set-Cookie(応答の場合) とCookie(要求の場合) の構文は異なります。したがって、元の値を送り返すことはできませんSet-Cookie(ほとんどの場合は機能しているように見えますが)。

あなたが言及した新しいResponse Cookies動的値には、特定のリクエストによって設定された Cookie を送り返すという目的があります。

さて、あなたの場合、私は常にResponse Cookies動的値を使用します。auth / cookie の設定を行うリクエストは 1 つしかないため、処理が最も簡単な場合があります。また、ドメイン、パス、安全、日付を無視して、ホスト (またはその他のもの) を切り替えても Cookie が常に送信されるようにすることもできます。