サーバーでVarnishを再起動すると、ユーザーのセッションが失われます。
これは、私の顧客がショッピングカートを紛失する順番です。
これはVarnishの正常な動作ですか、それとも私のVCLのせいですか？それはそうではないようです
詳細情報。
詳しい調査の結果、この問題はGitHubの問題＃725に関連しているようです。
私のMagentoインストールはバージョン1.9.1.0です。フロントエンド全体がhttpsで実行されていることにも注意してください。SSLを終了するためにVarnishの前でPoundを使用しています。
このバージョンのデフォルトのMagentoの動作は、通常は「frontend_cid」と呼ばれるセカンダリフロントエンドCookieを作成するようです。これは、MITM攻撃に対してテストする試みです。
Turpentineによって生成されたVCLファイルがこのCookieを渡していないため、無効なセッションが発生しているようです。
Magentoがクライアントに送信するCookieをVCLファイルがどのように渡すかを誰かが説明できますか？
これを必要なCookieを生成しないVarnishに絞り込みました。
Magento 1.9.1.0以降、MITM攻撃をブロックするために「frontend_cid」Cookieが導入されました。
これはMage_Core_Model_Session_Abstract_Varienクラスの135行目にあります
if (Mage::app()->getFrontController()->getRequest()->isSecure() && empty($cookieParams['secure'])) {
// secure cookie check to prevent MITM attack
$secureCookieName = $sessionName . '_cid';
if (isset($_SESSION[self::SECURE_COOKIE_CHECK_KEY])
&& $_SESSION[self::SECURE_COOKIE_CHECK_KEY] !== md5($cookie->get($secureCookieName))
) {
session_regenerate_id(false);
$sessionHosts = $this->getSessionHosts();
$currentCookieDomain = $cookie->getDomain();
foreach (array_keys($sessionHosts) as $host) {
// Delete cookies with the same name for parent domains
if (strpos($currentCookieDomain, $host) > 0) {
$cookie->delete($this->getSessionName(), null, $host);
}
}
$_SESSION = array();
}
if (!isset($_SESSION[self::SECURE_COOKIE_CHECK_KEY])) {
$checkId = Mage::helper('core')->getRandomString(16);
$cookie->set($secureCookieName, $checkId, null, null, null, true);
$_SESSION[self::SECURE_COOKIE_CHECK_KEY] = md5($checkId);
}
}クライアントに安全な接続を提供するために、Varnishは「フロントエンド」Cookieを生成する必要があります。これは、Magentoが後で特定の顧客を識別するために使用します。これまでのところ、これでうまくいくようです。ただし、Magento 1.9.1.0以降では、「frontend_cid」Cookieも生成する必要があります。
Varnishはこれを行う必要があります。これは、応答をキャッシュすることで、「フロントエンド」Cookieを含む応答ヘッダーもキャッシュするためです。
したがって、デフォルトでは、Varnishは、「ルックアップ」または「パス」条件の処理時にバックエンドが応答するすべてのCookieを爆破します。これは、キャッシュされた同じフロントエンドCookieで複数のユーザーが発行されるのを防ぐために行われます（これにより、人々のセッションが危険にさらされます）。
ワニスが「パイプ」でリクエストを処理するときはいつでも、Magentoは必要なCookieを作成してユーザーのブラウザーに添付できます。この結果、システムは初期検証に失敗しますが、ユーザーに新しいセッションを提供します。この症状は、カートの損失またはショッピングカートに商品を追加できないこととして現れます。
Turpentine VCLは、vcl_recv関数の次のコードに示されているように、メソッドタイプがGETまたはHEADでないリクエストを「パイプ」します。
// We only deal with GET and HEAD by default
// we test this here instead of inside the url base regex section
// so we can disable caching for the entire site if needed
if (!true || req.http.Authorization ||
req.request !~ "^(GET|HEAD)$" ||
req.http.Cookie ~ "varnish_bypass=1") {
return (pipe);
}そのため、ユーザーがカートにアイテムを追加しようとしたとき、または初めてチェックアウトしようとしたときに、この症状が最も顕著になります。
直し方？
この問題の解決策は、Turpentine VCLで着信ビジター用の「frontend_cid」Cookieも作成し、Turpentineモジュールで現在のセッションにそのCookieを「frontend」Cookieと同じように追加することであると思います。
それで...これをどのように実装しますか？
警告：私は間違っているかもしれません、私はワニスに非常に新しいですが、私はこれに多くの時間を費やしました、そしてこれは私が見ているものです、今の誰のサポートも大歓迎です
最終更新と私の選択した修正-2015 10 30
cookieがサーバー上でMagentoによってランダムに作成され、顧客セッションでMD5ハッシュとして保存されるため、ワニスで「frontend_cid」Cookieを作成することはできません。これにより、顧客セッションの外部で外部から作成することができなくなります。
この問題について私が思いついた最善の解決策は、Magentoが顧客セッションを処理する方法を上書きすることです。
現在、Magentoは無効なセッションを次のように処理しています。
IF
The requested session by the customer is flagged as invalid
THEN
Stop processing request
Redirect to the appropriate page私の新しいロジックは次のようになります：
IF
The requested session by the customer is flagged as invalid
THEN
Create a new session
Complete the requested task
Redirect to the appropriate page私の新しいアプローチでは、ワニスが最初の訪問でも顧客の応答を処理できます。これは、テレビン油の最新の実装が機能する方法ではありません。
私の問題、問題＃829-GitHubの/ nexcess / magento-turpentine / issues / 829。私のVCLのコピーはここにあります。
GitHubでの私の問題は、ここで見つかったはるかに古い問題の複製であるため、クローズされました。