web-dev-qa-db-ja.com

SSLで移動するときにセッションCookieがドロップされる

ショートバージョン：

開発サイトでセッションCookieを設定していますが、SSLに移動しても取得されません（チェックアウトに行くとショッピングカートが空になります）。

wwwサイトで設定されている場合：

# http://dev.domain.ext
Name    devSID
Value   2e9f1b1f6ca718d0961d0257f3297c1a
Host    .domain.ext
Path    /
Secure  No
Expires At End Of Session

そしてssl側：

# https://dev.domain.ext
Name    devSID
Value   6fe74ccc91b67bce46165d005bfd157e
Host    .domain.ext
Path    /
Secure  No
Expires At End Of Session

wwwの下で作成されたセッションCookieはssl側で取得されていないようです（逆に作成されている場合は逆になりません） ssl側www側では選択されません）。

誰もが明るいアイデアを持っていますか？

ロングバージョン（私が作業中）

現在、devサブドメインに開発サイトがあります。設定されているセッションCookieは、。domain.extタイプ形式を使用してドメイン全体でアクセス可能であり、データベースの構成テーブルからパラメーターをロードするPHPオブジェクトを使用して作成されます。

同じオブジェクトがすべてのサブドメインにわたってCookieを作成するため、異なるパス値またはそのようなものを持つ重複したCookieは作成されません。

Name    devSID
Value   [alpha-numeric hash value]
Host    .domain.ext
Path    /
Secure  No
Expires At End Of Session

私のローカルマシンでは、使用されるサブドメインはwwwとsslであるため、ホスト文字列は。dev.localとして読み込まれ、クッキーはうまく読み込まれますドメイン全体で（Apacheのhttps-vhosts.confを使用してサーバー上にドメインをセットアップし、Windowsホストファイルを使用して127.0.0.1を指すようにします）...すべてがうまくいきます。

ただし、それをオンライン開発サーバーにアップロードすると（独自の設定とvhosts設定を使用）、サイトのwwwからsslサイドに移動するとcookieがドロップされ、論理的な理由はわかりません。

これは仮想ホストで行われていることです：

<VirtualHost [IP ADDRESS]:80 >
    ServerName www.dev.domain.ext
    ServerAlias www.dev.domain.ext dev.domain.ext

    ...
</VirtualHost>

<VirtualHost [IP ADDRESS]:443 >
    [SSL ENGINE BIT]

    ServerName ssl.dev.domain.ext
    ServerAlias ssl.dev.domain.ext dev.domain.ext

    ...
</VirtualHost>

技術的には（ServerNameで定義された）サブドメインはwww.devおよびssl.devですが、実際にはいずれのDNSサーバーにも登録されていません-DNSサーバーには上位のdev登録済みのサブドメイン。それをServerAliasリストに追加し、Windowsホストファイルにエントリを作成して、未登録のサブドメインがマシン上で解決されるようにしました。

[IP ADDRESS]    www.dev.domain.ext
[IP ADDRESS]    ssl.dev.domain.ext

そして、セッションCookieパラメーター：

Name    devSID
Value   [alpha-numeric hash value]
Host    .domain.ext
Path    /
Secure  No
Expires At End Of Session

理論的には、Cookieはallサブドメイン（実際にはライブサイトでもdevサブドメインに限定されていないため）でアクセスできるはずですしかし SSL側に移動するたびにCookieがドロップされます。

apachehttpscookiesession
4
CD001

OK-DaveとEmilのおかげで、解決したばかりだと思います。あなたが頭に釘を打たなかった間-あなたはdid私を正しい場所に見させます（そしてデバッグするフィドラーを思い出させました） 。

理論的には、私がやっていたことすべきではない Cookieを破壊しましたが、たまにしかありませんでした（例：自宅からオンラインdevサーバーにアクセスでき、オフィスからはうまくいきませんでした）...

基本的に、PHPのセッションCookieコントロールsession_set_cookie_params()は、ゼロ以外の有効期限を希望どおりに処理しません。セッションを15分で期限切れに設定すると、time() + 900 Cookieが設定されてから15分で期限切れになります-not有効期限を更新します。したがって、私が行っていたのは、Sessionオブジェクトのプライベートコンストラクター内（シングルトン）でした。

if($this->cookie_lifetime != 0) {
      if(is_null($bUseHTTPCookie)) { setcookie($this->getName(), $this->getID(), (time() + $this->cookie_lifetime), $this->cookie_path, $this->cookie_domain, $this->use_ssl_cookie_only); }
      else { setcookie($this->getName(), $this->getID(), (time() + $this->cookie_lifetime), $this->cookie_path, $this->cookie_domain, $this->use_ssl_cookie_only, $this->use_http_cookie_only); }
}

セッションCookieを更新して、ページが更新されるたびに時間を15分延長することになっています。ローカルで正常に動作し、自宅から開発サーバーにアクセスしていましたが、職場のマシンからが動作していませんでした（約50回に1回動作する可能性があります） 。

レイテンシーの問題だと思う。どういうわけか、私の不気味なオフィスの不気味なマシンでは、session_set_cookie_params()が実際にCookieを書き込むのにかかる時間が、スクリプトがそのCookieを更新するはずのsetcookie()をヒットするのに十分な長さだったかもしれません...悪いことが起こりました。

Fiddlerで、1ページがセッションCookieのロードに長時間かかったときにwas n'tに設定されていたことがわかりました。これは、セッションIDが設定される前にsetcookie() Cookieの値として空の文字列を設定しています...もちろん、Cookieが削除されます。

これで、setcookie()関数がオフィスから機能しているように見えるようになりました。

はい、私に言う必要はありません、私はばかです-ありがとう:)

3
CD001

これはCookieドメインに関係していると思われます。 phpinfo（）関数を呼び出してスクリプトを作成してみて、wwwとsslの両方のvhostsでsession.cookie_domain値の値を調べますか？

0
Emil Rasmussen

あなたは間違った仮定の下で見ています。 httpからhttpsに変更すると、新しいドメイン、新しいサーバー、新しいものとして扱われるため、同じサーバー、同じドメイン上にあるにもかかわらず、SSL接続と非SSL接続の間でCookieを維持できません。

この変更の解決策は、クエリ文字列リダイレクトを使用することです。例えば：

http：/www.domain.tldにあり、セッションに関連付けられたセッションCookieがありますPHPSESSID = 12

サーバーを変更するためのリンクでは、https：//secure.domain.tld/？key = 876のようなクエリ文字列を追加する必要があります-Cookie値のmd5ハッシュであると仮定します。

ユーザーがクリックしてhttps接続に到達すると、このクエリ文字列を識別し、非SSLナビゲーションで使用していた正しいセッションをロードできるはずです。

これで問題が解決するはずです。

0
Dave