質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
Cookie

HTTPにおけるCookieとは、クライアントのウェブブラウザ上に保存された一時的なデータを指します。クライアント側のJavaScriptでも、サーバー側のHTTPヘッダーでもクッキーの読み書き・修正・削除が可能です。

PHP

PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

Q&A

4回答

30325閲覧

PHPでCookieが保存されない

tsunet111

総合スコア59

Cookie

HTTPにおけるCookieとは、クライアントのウェブブラウザ上に保存された一時的なデータを指します。クライアント側のJavaScriptでも、サーバー側のHTTPヘッダーでもクッキーの読み書き・修正・削除が可能です。

PHP

PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

0グッド

2クリップ

投稿2015/02/28 16:35

編集2015/03/01 02:45

###概要
あるタイミングで突然、Cookieが保存できなくなりました。
原因と思われること、解決策など思い当たる方は教えていただければ幸いです

###状況
・あるサイトの会員管理システムをPHPで組んでいる
・半年以上、問題なく稼働していたシステムである
・PHP Version 5.4.23
・あるタイミングで「ログインできない」現象が多発。
・このタイミングで、コードの変更はしていない。
・このタイミングで、サーバー業者が Apacheのバージョンを1.3から2.2に切り替えていた
・このタイミングで、PHPのバージョンは変わっていない

###問題発生後、調査した結果
・問題がおきているのは、複数の環境 Mac+Firefox、Win+IE、Win+Chromeなど様々
・すべての人がログインできないわけではない。使えている人も多数いる。
・もろもろ問題の切り分けと検証をした結論としては、Cookieの書き込みができていない=ログインできないという状況だった。
・具体的に現象の起きているマシンでは、cookie値がすでにセットされているところに、たった1行以下のコードを書いただけでも、Cookie値が書き換わらない状況だった。

lang

1<?php 2setcookie('logindata', '', time()-3600, '/', $_SERVER["SERVER_NAME"]); 3?>

・なお、サーバーのタイムスタンプが正確であること、$_SERVER["SERVER_NAME"] が正常に取得できていることは確認済。
・ブラウザの設定でCookieを使用する設定になっているのも確認済。

###対応
・ひとまず、Chromeユーザーは、ブラウザの設定からCookieを完全クリアしてもらうことで問題解決した。
・他ブラウザも同様に対応していく予定。

###質問
以下、みなさまご教授ください。
・今回の現象のトリガーとしては、状況証拠からすると、Apacheのバージョンアップで間違いないと思われますが、サーバー側の変更でブラウザのCookieの挙動に影響を与えるものでしょうか?
・そもそも、何か特定の条件によって、Cookieの書き込みできなくなるということがありうるものでしょうか?

よろしくお願いいたします。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答4

0

実際に出力されたCookieはどのようになっていますか?
以下のように実際にブラウザへ出力された、HTTPヘッダーの内容を教えてください。

Set-Cookie: name=value; Tue, 31-Dec-2030 23:59:59;

投稿2015/03/01 07:12

munyaX

総合スコア783

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

tsunet111

2015/03/02 01:49

Chrome の chrome://net-internals/#events から確認して、以下の情報であっていますでしょうか? ``` t=223009 [st= 11] +HTTP_TRANSACTION_SEND_REQUEST [dt=0] t=223009 [st= 11] HTTP_TRANSACTION_SEND_REQUEST_HEADERS --> GET /member/index.php HTTP/1.1 Host: www.hogehoge.jp Connection: keep-alive Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36 Referer: http://www.hogehoge.jp/member/index.html Accept-Encoding: gzip, deflate, sdch Accept-Language: ja,en-US;q=0.8,en;q=0.6 Cookie: [190 bytes were stripped] t=223009 [st= 11] -HTTP_TRANSACTION_SEND_REQUEST t=223009 [st= 11] +HTTP_TRANSACTION_READ_HEADERS [dt=701] t=223009 [st= 11] HTTP_STREAM_PARSER_READ_HEADERS [dt=701] t=223710 [st= 712] HTTP_TRANSACTION_READ_RESPONSE_HEADERS --> HTTP/1.1 200 OK Date: Mon, 02 Mar 2015 01:29:42 GMT Server: Apache X-Powered-By: PHP/5.4.23 Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Set-Cookie: [50 bytes were stripped] Set-Cookie: [92 bytes were stripped] Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html ``` ドメイン名だけダミーです。 これは正常動作している環境ですが、これのうまく動作していない環境をみればよろしいでしょうか?
munyaX

2015/03/02 01:53

あ、説明が足りず申し訳ないです。 Chromeでしたら、開発者ツールの「Network」でリクエストヘッダやレスポンスヘッダを確認できます。 そこにあるCookieの部分を、正常時と異常時で比較して違いがあれば、Cookieが原因であると断定できるのかなと思ったものでして。
tsunet111

2015/03/02 02:31

ありがとうございます。 わかりました。 Set-Cookie:keeplogin=6d1d76ed89139b1bd50890d12f9d42e3; expires=Wed, 01-Apr-2015 02:28:27 GMT; path=/; domain=hogehoge.jp これですね。 正常動作している環境では上記のようになっていました。 動作していないPCは手元にないため、確認してみます。
munyaX

2015/03/02 02:37

これです、これです。 比較したいですね。 あと怪しいのはP3PヘッダをApache側で出していなかったとか、何らかのフィルタリングやキャッシュを仕掛けていなかったかあたりですかね。ようはサーバ側の設定が変わっていたのでは?というのも匂います。
tsunet111

2015/03/02 04:56

質問文に書いた setcookie('logindata', '', time()-3600, '/', $_SERVER["SERVER_NAME"]); がかかれいているページを不具合環境でみたところ、 Set-Cookie: keeplogin=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=hogehoge.jp でした。 このあと、結果としては、keeplogin の値が消えていません。
munyaX

2015/03/02 05:00

検証お疲れ様です。 Cookieの有効期限が過去の日付になってますね。これだとセッションCookieになり、ブラウザを終了すると同時に削除されてしまます。  ※expires=Thu, 01-Jan-1970 00:00:01 GMTの部分 time()-3600の箇所が正常に動いているか確認してみてください。 システム自体の時刻、php.iniのtimezoneの設定とか、時刻周りもひと通り見られると良いかと思います。
munyaX

2015/03/02 05:03

ん、あれ違うな。 以下の2つは用途が異なるCookieですか? Set-Cookie:keeplogin=6d1d76ed89139b1bd50890d12f9d42e3; expires=Wed, 01-Apr-2015 02:28:27 GMT; path=/; domain=hogehoge.jp Set-Cookie: keeplogin=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=hogehoge.jp
tsunet111

2015/03/02 05:14

すみません違うページのものを送っていたかもしれません。 基本用途は同じで、書き込むべき時は書き込む、不要だったら、消すということをやっています。あとで、全く同じページを見た結果を贈らせていただきます。
tsunet111

2015/03/02 07:57

正常に動作している環境(Mac+Firefox) Set-Cookie: keeplogin=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=hogehoge.jp 異常動作環境(Mac+Firefox 別マシン) Set-Cookie: keeplogin=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=hogehoge.jp あえてCookieを消そうとしている動作をしているのですが、time()-3600 がうまくいっていないのでしょうか。time() の値は正常でしたが、ここが、1970になるのは変なのでしょうか。
tsunet111

2015/03/02 07:59

上記、結論としては、正常動作マシン:Cookie値は削除されている、異常動作環境:Cookie値は消えないで残っている、という状況です。
munyaX

2015/03/02 08:11

すみません、寝ぼけて変なこと書いてますね。 先に訂正を。 > Cookieの有効期限が過去の日付になってますね。これだとセッションCookieになり、ブラウザを終了すると同時に削除されてしまます。  →削除される動作で正しいです。   セッションCookieは有効期限が未指定時の時の挙動でした。 > time()-3600 がうまくいっていないのでしょうか。time() の値は正常でしたが、ここが、1970になるのは変なのでしょうか。  →これも失礼しました。   どうもPHPの仕様で、過去時間を指定すると、強制的に1970年の日付になるようですね。3600秒引いただけでは1970年になるわけないので、どこかしら日付がおかしいのでは?と推測しました。 (つづく)
munyaX

2015/03/02 08:22

で、もう少し詳しく調べてみると、 setcookie('logindata', '', time()-1000, '/', $_SERVER["SERVER_NAME"]);  → 1970/1/1 setcookie('logindata', '', time()+1000, '/', $_SERVER["SERVER_NAME"]);  → 1970/1/1 setcookie('logindata', 'aaa', time()-1000, '/', $_SERVER["SERVER_NAME"]);  → 2015年の日付 setcookie('logindata', 'aaa', time()+1000, '/', $_SERVER["SERVER_NAME"]);  → 2015年の日付 Cookieの値を指定するかどうかで有効期限を自動的に設定するようです。 (値が存在しない場合、指定した有効期限は無視される) これは自分も知りませんでした。
munyaX

2015/03/02 08:25

混乱させてしまって申し訳ありません。 ここまでの結論としては、問題となっているのは発行された単体のCookie自体でも、時間関係でもないようですね。 これはもう少し環境情報や、実際にコードを読まないとわからないレベルかもしれません。
tsunet111

2015/03/02 08:43

いろいろありがとうございます。勉強になります。 まだ解消されないお客様がいるようで、どうにかせねばなのですが・・・ サーバーログ等をみれるアカウントも入手したのでみてみます。 何かこの情報などあったら分かるかも、などあればまたご教授ください。
guest

0

サーバ側のセッション情報はどこに格納するようになっているか?
→ session.save_handler
格納先の状態は正常か?(ファイルならディスク容量とか、
ディレクトリのパーミッションとか、DBならそのハンドラとか)
あたりは、一応確認しておいた方がよいかと思います。

Apache の 1系 から 2 系で何が変わったかなぁ...

あと、動いている php のバージョンは変わっていないという
ことですが、バイナリは変わっていませんか?
(ソースビルド版からパッケージ版に変わったとかはないか?)

投稿2015/03/05 15:25

hotta

総合スコア1613

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

tsunet111

2015/03/05 15:56

ありがとうございます! まず、私のスキルとしてサーバー側の設定などはあまり詳しくないので筋違いのことを言っていたらご指摘ください。 ひとまず、phpinfo で確認した限り、session.save_handler は files となっていました。 セッション情報の格納先がCookieの挙動に影響をあたえるものなのでしょうか。 サーバーについてはレンタルの共有サーバーで、かつ変更前の環境があるわけではないので比較ができないのですが、バイナリが変わっているかはどうやって判断したらよいのでしょうか?(素人質問ですみません...)
退会済みユーザー

退会済みユーザー

2015/03/05 20:17

>セッション情報の格納先がCookieの挙動に影響をあたえるものなのでしょうか。 PHPのSESSIONをCOOKIEで扱う設定になっていて(通常そうですが) SESSIONをFILEに保存する設定になっていると(通常そうですが) SESSION情報がファイルに書き出されるわけですが、 そのファイルを書きだすディレクトリに対してApacheに書き込み権限が与えられていないと、ファイルが書きだせないため、SESSIONが保存できず、消えてしまうことになると思います。 > hayashi_kohei さん > 自分はパニックになりまくったあげく「/tmpディレクトリ」のパーミッションのせいだったことがあります。 まさしくこんな状態ですね。 > ・このタイミングで、サーバー業者が Apacheのバージョンを1.3から2.2に切り替えていた 変えていたのはApacheだけでしょうか…? ってずっと思っていたのですが…
退会済みユーザー

退会済みユーザー

2015/03/05 20:29

んですが、それはSESSIONが切れるという話ですので、 今回のご質問とは別の問題のような気がします。 (投稿分かれてしまって申し訳ありません)
tsunet111

2015/03/06 00:17

コメントありがとうございます。 そうです。問題は、ブラウザCookie側がうまく保存されないという現象なので、ふつうに考えると、サーバー側関係なくクライアント環境の問題だろう、という形なのですが… 明らかにApache変更後から現象が多発しているのと、複数の環境・ブラウザで発生しているので、WindowsUpdateなどもあまり関係ないだろうという仮説をたてています。 もともとのコードに、何か特定条件で発現するバグが含まれていた、ということも考えられるのですが、質問本文にもかいたとおり、ただ1行Cookie書き換えるコード書いて、ほかの環境ではうまく動いているのに対象環境で動作しないというのがどうしても解せない状況です。。。
guest

0

すみませんこちら間違い投稿です。消せないので残っていますが無視してください。

投稿2015/03/02 01:47

編集2015/03/02 01:50
tsunet111

総合スコア59

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

自分はパニックになりまくったあげく「/tmpディレクトリ」のパーミッションのせいだったことがあります。
まぁこれはエラーログ見れば一発でしたけどね。

投稿2015/03/01 18:00

hayashi_kohei

総合スコア47

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

tsunet111

2015/03/02 01:51

ありがとうございます。 > 「/tmpディレクトリ」のパーミッションのせい これは、サーバー側のtmpディレクトリでしょうか?
hayashi_kohei

2015/03/05 19:56

phpのセッションファイルの格納場所をそこにしていたためでした。
tsunet111

2015/03/06 00:20

ありがとうございます。 サーバー側ですよね。今回は、ブラウザのCookieがうまく書き換えられないという状況なので、関係ないような気がしています。
hayashi_kohei

2015/03/06 13:52

有効期限やキャッシュの問題等の可能性もあるかと思います。 よくあるのはログインがおかしいよ!っていうクレームに対してブラウザのキャッシュをクリアしてもらったら直る場合。 あとはPHPのgc_maxlifetime等クッキー発行時の有効期限の設定。 初期値が1440とか用途によって割と短く感じるので不具合だと関違いすることもあります。
hayashi_kohei

2015/03/06 13:54

と、おもったらキャッシュのクリアですでに対応済みでしたね。失礼いたしました。
tsunet111

2015/03/06 21:08

ありがとうございます。 だいたいキャッシュクリアで解消しつつあるのですが、IEは解消されない方がおります… ただ、どちらかというとITリテラシー低めの方が多いサイトのため、キャッシュクリアしたと思って、されていないんじゃないか、という疑惑はあります。IEは設定が分かりづらいので。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

まだベストアンサーが選ばれていません

会員登録して回答してみよう

アカウントをお持ちの方は

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問