【PHP】セッションについて語ろう！【PHP】
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
03/09/24 19:31ID:SnRvXmpIブラウザを閉じることでクッキーを消しているからなのですね。。
知らなかったよーーーーうわーーーん
0083nobodyさん
04/03/19 22:04ID:???child pid ***** exit signal Segmentation Fault
ログにはこんなもんがいくつか残ってました
OSはRedhatLinuxでapache1.3.27、PHP4.3.2です
なんか分かりますか？
008482
04/03/20 00:30ID:???php.ini のセッションの設定で、
session.save_handler
に files 以外を指定している場合は安定しないかもしれない。
でも、PHP 4.3.2 だと、
bug #24592 (NULL related crash in session extension)
bug #22154 (Possible crash when memory_limit is reached and output buffering in addition to session.use_trans_sid is used)
の可能性の方が高そう。PHP 4.3.3 で修正されているみたいなので
バージョンアップしたらセッション周りは安定するかもしれない。
今なら、PHP 4.3.4 かな。もうすぐ PHP 4.3.5 が出そうだけど。
まあ、クリティカルなシステムをバージョンアップするなら、
十分にテストしてからにした方がいいと思う。
0085nobodyさん
04/03/20 10:00ID:???どうもです
ああ、やっぱバージョンのせいなんですかね
セッション機能にはmmを利用しているんですが、
どうせ処理速度には大差がないだろうし、filesを検討します
そのうちPHP5が出てきそうですが、
焦って飛びつくのは危険そうですね
008684
04/03/20 10:55ID:???PHP 4.2.x の頃に、パフォーマンス的に有利ということだったので、
session.save_handler = mm
にしていたことがあったけど、>>81 とほぼ同じ症状になった。
原因が分からず、随分悩んだ後、files に戻したところ、安定するようになった。
PHP 4.3.0 以降では確認していなかったけど、修正はされていないのかな。
0087nobodyさん
04/03/20 12:40ID:???特に処理速度にも問題ないし、とりあえず大丈夫
まあ今後>>81の症状がでるかどうかまだ分かりませんが･･･
でもコレはPHP4.3.2の問題じゃないかもしれませんね
apacheもlogrotateの時にサービスが落ちたりしますから
今じゃ毎朝cronでapacheを再起動してます（苦笑）
008887
04/03/20 13:11ID:???apacheがちょくちょく落ちるのってかなりやばいよなあ（汗）
OSのレベルからアップグレードを考えるいい機会かもしれない
008986
04/03/20 13:35ID:???その状態だと、PHP の方が問題の可能性が高いと思う。
当時は、3日から 1週間にに一度再起動していたし、
apachectl で restart すると Apache が落ちてしまって、
apachectl start しないと起動しない状態になっていたので。
files に変更してからは、Apache が落ちることもなくなったので、
同じ問題だとすると、安定するかもしれないので、しばらく様子を
見てもいいかもしれない。
セキュリティ問題のこともあるので、簡単にバージョンアップできる
のであれば、バージョンアップした方がいいと思うけど。
0090nobodyさん
04/03/20 15:55ID:???mm ってなんですか？
当方セッション情報を MySQL に入れるハンドら作って動かそうとしているのですが、
既存のがあるんなら使っちゃおっかな～
009286
04/03/20 20:56ID:???セッションの保存用の共有メモリ。
ttp://jp.php.net/session
mm を使うと不安定になるという話をしていたのだが、PHP の最新版では
修正されている可能性もあるので使いたいのならどうぞ。
mm をインストール(既にインストールされている Linux ディストリビューションもある)して、
ttp://www.ossp.org/pkg/lib/mm/
PHP の configure で --with-mm を指定してコンパイルする。
php.ini で
session.save_handler = mm
に変更して Apache を起動。
009390
04/03/21 03:27ID:???どれどれ・・ふむふむ・・
なーんだ、mmってモジュールの名前なのね・・
こっちか・・ http://www.ossp.org/pkg/lib/mm/
UNIXで動くのね・・どれどれ
#whereis mm
mm: /usr/ports/devel/mm
をを、Portsに入ってるジャン
んでも、こいつの動作検証せなあかんのか～めんどくさっ
以上５分で却下しますた。ごめん。
0094nobodyさん
04/04/02 20:40ID:???こんなんが出てくるんですけど・・・
Warning: session_start(): Cannot send session cookie - headers already sent by
(output started at c:\program files\apache group\apache\htdocs\session\
session_test_1.php:2) in c:\program files\apache group\apache\htdocs\session\
session_test_1.php on line 3
session();の行でエラーなんだそうです。
/tmpのフォルダもＣドライブに作りますたがダメです。
なんででしょうか？
0095nobodyさん
04/04/02 20:46ID:???すんません！いきなり判明しました・・・
１行目を空白にしていたのが原因でした。
1: ←空白行にしていた
2:<?
3:session_start();
4:$_SESSION['register'] = 0;
5:
6:?>
1:<?
2:session_start();
3:$_SESSION['register'] = 0;
4:
5:?>
にしただけで治りました・・・
お騒がせしてすんません。
0096nobodyさん
04/04/04 21:49ID:zccZUASsPHPのSIDもOFFにしているのに・・・
なぜ？
・・・と書き込もうとしたら2chに書き込めないｗ
なぜ掲示板でクッキー必須なんだ？
010090
04/04/05 01:55ID:???010196
04/04/05 23:36ID:EigS3bMU<?php
echo $_SESSION["name"];
?>
とかでセッション情報をページに表示させるようにしてるから
URIパラメータもないし・・・
クッキーがコッソリ動いてるのか？とも思ったが、
2chに書き込みが出来なかったので、それも考えにくい・・・
自分のサイトだけクッキーが有効になってたのか？分からん・・・
0102nobodyさん
04/04/05 23:45ID:???IEでプライバシーポリシーうんにゃらで2chからのクッキー食べてくれないとか・・
0103nobodyさん
04/04/05 23:55ID:???010496
04/04/05 23:57ID:EigS3bMU「すべてのCookieをブロック」にしたのよ
ふつうコレでCookie機能は無効になるっしょ？
010596
04/04/05 23:58ID:EigS3bMUwww
0106nobodyさん
04/04/06 00:01ID:lpi6f7xmなんやねんな
0108nobodyさん
04/04/06 02:28ID:???んでも、Mozilla使った方が開発はしやすいぽ
0109107
04/04/06 05:26ID:???ちゃうちゃう。
最終的なユーザのことを考えた場合のチェックとしてはIEは外せないけど、
デバッグには向かないから使うなってこと。JavaScript系は特にデバッグしにくい。
但しJavaScriptの挙動はIEとMozillaは違うので、そこは留意しないと駄目。
XMLのチェックの部分では、IEの方が出来がいいと思う。
0110107
04/04/08 00:30ID:???XMLはIEの方が良い！
Mozillaのデバックコンソールってもう一声どうにかならんかなぁ
あとあと、CSSで幅の定義を１どっとずれて描画するのもどーにかならんかなぁ
はうっ！セッション関係無いし
0112nobodyさん
04/04/14 12:42ID:???セッションとは、 フラグである・・・
ようやく気が付いた。
0113nobodyさん
04/04/14 14:05ID:vcn3L4Woセッションなんて言うからよく分からないんだよな。
「ページを超えて持ち運ばれるフラグ」って言えば分かり易いね。
0114教えてください・・・
04/05/16 22:13ID:dL8RQ1Kh＜環境＞
サーバA：192.168.11.1 WinXP-Apache1.3.29＋PHP4.3.4
サーバB：192.168.11.2 同上
やりたいことは、
①サーバAのLOGIN.PHPでログイン(=>LOGINFLG=ONを$_SESSIONに設定する）
②サーバBのxxxx.php（$_SESSION[LOGINFLG」を見る）にアクセスする
->xxxx.phpが、$_SESSION[LOGINFLG」=ONを見て、PHPの参照許可を出す
という、セッション情報をサーバ間で持ち回るということをしたいんです。
条件として、
・セッションクッキーを使わない。
・Windows上(=mmが使えない）ということで、session.save_handler = filesを使う。
という状況なんですが、どうやれば、セッション情報の共有はできるんでしょうか・・
お教えください。。。
0115nobodyさん
04/05/16 22:43ID:???セッションという機能がどういう風に実現されてるか、
またはどういう風にすれば実現出来るか考えてみれ
PHPのセッション機能は複数サーバ間で持ち越しすることは想定されていない（はず）なので、
書いてるようなことを実現したいなら、自分でセッション周りを作って、
セッション管理用のサーバを一つ用意すればいい。
が、そんなややこしいことするよりも、もっとスマートな解決法があると思うぞ。
根本的なとこから見直した方がいいと思う。
0116nobodyさん
04/05/17 18:19ID:???DBは使わないの？
方法によっては簡単に出来るのに。
0117nobodyさん
04/05/17 23:43ID:???＃勘違いっぽいのでsageておこう・・
0118nobodyさん
04/05/19 00:08ID:???0119nobodyさん
04/05/21 09:38ID:???perlでもできるよね。登録パスワードをフォームに混ぜちゃえばいいわけだし。
でもリファラー吐くブラウザだと他のサーバー行ったときにパスワードが入っているとまずいのか？？
だから一時的な物を生成するの？
0120nobodyさん
04/05/21 14:11ID:???セッションはサーバーサイドでデータを保持するのが最大の特徴
「クッキーの逆のもの」と考えてもいいかも
クッキーもセッションも「ページを超えて持ち運ばれるフラグ」には違いないが、
そのデータそのものをどちらに保持するかが違う
クッキーはクライアントで保存し、データそのものを含む
だけどセッションの場合にはデータを保持するのはサーバー側で
クライアント側ではデータそのものは保持しない
（代わりにクライアントを識別するためのセッションＩＤを保持する必要はあるが)
POSTでhidden使って渡すのも、さらにGETでURI渡しするのも、
ページを超えて運ばれるフラグには違いないけど、これらも結局は
クライアント（ブラウザ）でデータを所持しているんだよね
0121nobodyさん
04/05/21 23:41ID:???何かまとまってないぞ（笑）
要するに毎回データそのものをクッキーなりHIDDENフィールドなりで
運ぶという方法と
そうではなく、識別情報だけをクライアントとサーバー間で往復させて、
サーバー側にハッシュテーブルのようなものでデータを預けて置くという方法
の２つがある。
ぶっちゃけそれだけ。
0123nobodyさん
04/06/01 22:09ID:???サーバ側で生成したサーバ側でしか利用しない値は、
わざわざhiddenで引き回したりしない。つか、してはいけない。
セキュリティホールにもなりうるし。
そういう用途のために(サーバ側の) session を利用するという理由もある。
情報の分離(隠蔽)だな。
0124nobodyさん
04/06/02 16:13ID:???$b=array(1,2,3);
$session_a[b]=$b;
として
session_start();
unset($session_a);
しても$session_a[b]が消えてなかったんだが、バグですか？
PHP Version 4.3.3です。
0125nobodyさん
04/06/03 15:13ID:???session_unregisterの注意を読むと、
unsetではフォーカス内の変数のみを消去して、
セッション内の登録は継続されるようだから、
セッションを再開した時にセッション内の登録変数を読み出し直すだけでは？
つまりそのunsetは現在の$session_aを削除するだけで、
$_SESSION['session_a']は削除しないんではないかと。
つーか、
$session_a['b']=$b;
って書くべきだし(typo?)、
session_(un)registerは非推奨
0126nobodyさん
04/08/20 09:10ID:rKFIPCr5バージョンとか微妙なところで制限事項があるのかな？
0127nobodyさん
04/08/20 15:48ID:???0128nobodyさん
04/08/22 18:42ID:TKt9TmhM変数として保持しながらページを作成していくと、javascriptの
history.back()を使用してページを戻るときに「有効期限切れ」と
なってしまいます。
フォーム入力確認で戻る必要があるのですが、どういった方法で
会員制にするのがよいのでしょうか？
0129nobodyさん
04/08/24 16:45ID:mVJd0HpMhistory.backで戻ってセッション切れちゃうのは仕方ないね。
戻り先のページが別ページなら普通にリンク貼ればOKだと思うけど。。
0130nobodyさん
04/08/24 16:52ID:???セッション(ﾟ⊿ﾟ)ｲﾗﾈ
0131nobodyさん
04/09/02 15:49ID:???それでカッコイイと思ってんのか？キモイ奴だな。
php使ってんならJS使わなくてもリファラからファイル（スクリプト）名と
必要ならクエリだけ取り出してリンクさせたらセッションも生きたままで
可変式のBACKボタンが生成できるだろ？
もっとも同一ドメイン内での話だけどな。
0132nobodyさん
04/09/03 00:37ID:???亀レスだけど、目から鱗。今日悩んでいたことが氷解した。
解説書に書いてあることが間違ってたよヽ(`Д´)ﾉ
とにかく、一言言わせてくれ。どうもありがとう。
0133nobodyさん
04/09/03 09:53ID:???セッションハイジャックの危険性は常につきまとうと思うのだが、
PCサイトならばcookieにsidを食わせて、sidの確認が必要なページのみsslで通信すれば
良いと思うが、携帯サイト等でsidをURLに引き連れまわす必要がある場合
全ページsslで通信という形にするしかないと思うのだが、どうしてる？
0134nobodyさん
04/09/03 10:05ID:???セッションに接続元のIPを記録しておいて
if ($_SESSON['ip'] != $_SERVER['REMOTE_ADDR']) {
die 'あぼーん';
}
0135nobodyさん
04/09/03 10:14ID:???携帯サイトでクライアントをIPで判断できないでしょ？
キャリア側のプロキシのIPだらけになるのでは？
PCサイトの場合でもIPでの判断だと、NATの内側のクライアントは一纏めにしちゃうの？
0136nobodyさん
04/09/03 13:24ID:???PCの場合はCookieオンリー前提で書いてました。説明不足すんません。
携帯は端末とプロキシのIPは一対一対応だと思ってたんだけど、もしかして違います？
（IPアドレス自体はセッションごとに変わりますが）
だったらこの方法は使えませんね。う～ん。
現行の3G携帯（というか、そのサーバー）はFOMAを除いてCookieに対応してますが
シェア最大のドコモがこれでは将来的にも難しいですね・・・。
個人情報など、重要なデータをセッションで使うときは最初から最後までSSLで通信して、
漏れてもあまり困らないデータは普通にセッションを使うしかないのかな。
Amazonなんかはそうなってるみたいですね。
0137nobodyさん
04/09/05 23:33ID:5TcSHTQS0138nobodyさん
04/09/06 14:10ID:???まず前提からして間違ってる。
>PCサイトならばcookieにsidを食わせて、sidの確認が必要なページのみsslで通信すれば
>良いと思うが
良くない、cookie値はglobal変数「$_REQUEST」として常にサーバへ渡っている。
したがって、cookieに設定したセッションIDを必要とする時のみSSL通信下で行っても、
それ以外のページではsidは平文でネットワークを流れる事になる。
0139nobodyさん
04/09/27 20:49:22ID:???0140nobodyさん
04/09/28 01:10:51ID:???0141nobodyさん
04/09/28 17:26:54ID:???0142nobodyさん
04/09/28 18:58:14ID:???0143nobodyさん
04/09/29 14:00:46ID:Gp3joNGAもしくはhttp用のcookieとhttps用のcookieの二つを発行しろと言ってるね。
ttp://securit.gtrc.aist.go.jp/research/paper/AIST03-J00017/csec200307-takagi-slide-sp1.pdf
ことネットワーク絡みの話に関しては、お上とその周辺が出してる情報は
とても役に立つよ。
0144nobodyさん
04/10/06 22:15:29ID:???0145nobodyさん
04/10/07 21:46:09ID:eGrZpUzk0146nobodyさん
04/10/07 22:01:55ID:???0147nobodyさん
04/10/07 22:05:54ID:???0148nobodyさん
04/10/07 22:28:49ID:???セキュリティ的にはどうなんだろう？
0149nobodyさん
04/10/07 22:40:45ID:???レン鯖でもセーフモードかCGI+suEXECでsession.save_pathを適切に設定してれば大丈夫。
ちなみにメモリやデータベースにセッションを保存するようにもできる。
ttp://jp.php.net/manual/ja/function.session-set-save-handler.php
0150nobodyさん
04/10/07 22:54:49ID:???個人情報を扱うようなときはセッションを使うドメイン全体をSSLで保護するか
$_SESSIONを使う代わりにIDの発行からデータの出し入れまで全部を独自に管理しないといけない。
0151nobodyさん
04/10/07 23:27:27ID:???0152nobodyさん
04/10/07 23:33:22ID:???0153nobodyさん
04/10/08 00:39:22ID:???>ただ、PHPはセッションIDにcookieを使う際にsecure属性をつけられないので
PHP 4.0.4 以上だったら付けられる。
php.ini で
session.cookie_secure = 1
とするか、
ttp://jp2.php.net/manual/ja/ref.session.php#ini.session.cookie-secure
session_set_cookie_params()
で設定。
ttp://jp2.php.net/session-set-cookie-params
0154nobodyさん
04/10/08 00:56:47ID:???0155nobodyさん
04/10/08 01:37:35ID:???setcookieの最後の引数で指定でもいい？
この場合setするcookieのkeyによってセキュア属性のあるなしになるのかな？
0156nobodyさん
04/10/08 11:59:28ID:???setcookie() だと最後の引数で指定すれば個別に secure フラグありとなしで
複数の Cookie を設定できる。例えば、以下のような感じで。
setcookie('secure_on', 'test1', NULL, '/', NULL, 1);
setcookie('secure_off', 'test2', NULL, '/', NULL, 0);
正しく Cookie を処理できるブラウザだったら secure_on の方の Cookie は、
https 接続の時にしか送信されない。
0157nobodyさん
04/10/08 14:14:20ID:???>もしくはhttp用のcookieとhttps用のcookieの二つを発行しろと言ってるね。
に関してはsetcookieの引数で分けるのが良さげかな。
うーん、携帯サイトでhttp://～～のショッピングサイトってかなりあるんかね。
気にしだすと怖いな。
GETのSIDをhttpとhttpsで切り替えるとか？イメージわかん…
0158nobodyさん
04/11/05 23:35:57ID:onIpwNyMMySQL使ってるんですが、
必要最小限の変数だけ session_register して
そのつどMySQLからデータひっぱってくるのと、
MySQLのデータ全て session_register しておくのでは
どっちがよかとですか？
ヒロシです
0159nobodyさん
04/11/07 18:16:49ID:???データの内容とアクセス頻度(規模)などによって一概にどっちが良いかは言えないし、
「良い」の基準が決まっていないとレスのしようもないんじゃない？
例）
・作成時に楽なら良い
・サーバー負荷を考えると良い
・セキュリティ的に安全だから良い
などなどなどなどなど・・・。
セッションの前に他のことを勉強しろよ。斬り。
0160nobodyさん
04/11/07 21:42:34ID:???きれいに返されました。
セキュリティ・負荷面を重視しています。
よろしこです。
ヒロシです
0161nobodyさん
04/11/09 18:20:01ID:aEAOTgZ10162nobodyさん
04/11/12 12:40:22ID:2kt36js1使用人数は10人です。
ＯＳは基本的にwindowsでバージョンはＸＰや98など様々です。
ページの更新などをする際に5分くらいでセッションが切れます。
ほぼ10人ともその状態です。
セッションが頻繁に切れる原因とかってありますか？
漠然とした質問で申し訳ないでつ。。
0163nobodyさん
04/11/12 13:38:08ID:???0164nobodyさん
04/11/12 14:19:13ID:???これが参考になるんじゃないかな
http://www.asahi-net.or.jp/~wv7y-kmr/memo/php_security.html#PHP_Session_GC
0165nobodyさん
04/11/16 15:55:39ID:???0166nobodyさん
04/11/16 16:34:38ID:???0167nobodyさん
04/11/17 21:13:10ID:K1rG9sHPページ移動するたびにDBにアクセスしてCookieと照合してます？
0168nobodyさん
04/11/19 11:05:17ID:???DBへ登録して使っている人って結構いる？
それともメモリー的にとか、DB容量的にとか、処理的に冗長だとかで、むしろ無駄？
0169nobodyさん
04/11/19 15:38:04ID:???返ってくるセッションクッキーをどうにかしてブラウザに食わせたいと思ってます。
firefoxのクッキーファイルに書き込むだけではだめでした。
expires付のクッキーはうまくいくのですが…
これを解決する手段はないものでしょうか？
Perlかどうかはどうでもよく、セッションクッキーの話なのでこちらに書き込みました。
もしもっと適切なスレがあれば是非教えてください。
0170nobodyさん
04/11/21 01:16:45ID:???どうも混乱しているようにしか見えないのだが…
HTTPクライアント作ってるって時点で「板違い」
セッションクッキーってのも意味わかんないし、
まずはセッションは何たるか、クッキーは何たるかを理解してから出直してね。
もしくは169の認識してる「セッションクッキー」と「クッキー」の違いを言ってみ。
0171nobodyさん
04/11/24 00:14:55ID:6VcNevlw確かに「セッションクッキー」はセッションと言うにはアレかも知れんが、
簡易なセッションを実現するものではあるし、
なにより、みんな「セッションクッキー」って呼んでるじゃん。
で、普通、「セッションクッキー」に対して、単に「クッキー」って呼ぶのは、
「パーマネントクッキー(169曰く、expires付のクッキー)」でしょ。
0172nobodyさん
04/11/24 06:52:52ID:???セッションクッキーで通じるから別にいいけど
確かに用語の使い方がいろいろ不明な点があって
日本語として文が構築されてない
0173nobodyさん
04/11/24 09:17:36ID:???セッションIDだけで管理してる？
セッションIDだけだと怖いので
ログインIDと暗号化したパスワードも
セキュアクッキーに書いて
毎回DBと比較してる。
これってやばい？
0174nobodyさん
04/11/24 14:09:50ID:???やばくはないと思うが
それじゃセッションIDを使う意味があまりなくね？
セッションIDの発行方法にもよるけど
PHPのセッション関数使ってるなら大丈夫じゃないの？
0175173
04/11/24 15:43:40ID:???レスありがとうございます
ログイン前の匿名情報（ショッピングカートのようなもの）を
セッションIDで管理、
ログイン後の情報はセッションだとちょっと怖いので
セキュアクッキーでアクセスの度に毎回ログインチェックをしてます。
セッションIDだけで
クライアントを特定するのって
会員制のようなサイトでも普通なんでしょうかね？
0176nobodyさん
04/11/25 03:52:30ID:???個人的な構築法としてはセッションIDとログイン情報を関連付けて
セッションIDきたらログイン情報みて毎回チェックするけど
規模がデカイ or サーバしょぼい 場合は毎回チェックするとレスポンス落ちるから
Yahooみたいに重要な処理のときだけログインチェックみたいな形にしてる
けど173のケースだとログイン前からの情報とも連携するみたいだし
それならセッションIDとcookie使ってても納得できる
毎回ログインチェックするのに越したことはないけど
やっぱりサーバのスペック的な問題でレスポンスが結構影響でてくるから
重要なページ（個人情報変更）とかだけ認証っていう形でもありじゃないかな？
良いセッションの使い方があれば他の人フォロー頼みます。
0177nobodyさん
04/11/26 20:15:19ID:5ndPRR48全く異なるネットワーク＆端末からの接続は排除できる。
(ＮＡＴ環境とか一部のＣＡＴＶ環境からのアクセスはどうしようもないけど)。
で、その上でブラウザバージョンとか「相手から送られてくる情報」を、
『セッション単位のワンタイム情報』として管理すればかなりいけるんでない？
まぁ、金銭扱う場合は「やりすぎ」ってのはないだろうけど、使う側の利便性を
考えればワンタイム情報として上記を扱う(＋独自のスパイス)でほぼ安全でしょう。
0178173
04/11/26 20:37:10ID:???やっぱりサーバ負荷は一番気になるとこですね。
たいへん参考になりました。
ありがとうございました。
>>177
大企業などアクセスのたびに
毎回IPアドレスが変わる環境もあるから
だめじゃないかな？
0179nobodyさん
04/11/27 05:47:30ID:pSdshSFH> 大企業などアクセスのたびに
> 毎回IPアドレスが変わる環境もあるから
> だめじゃないかな？
そんな場合、HTTPに限らず他のサービスでも認証が絡む奴は
大問題になりそうな希ガス...
気のせい？
0180nobodyさん
04/11/27 07:24:52ID:GhxEggFVIPで認証するの？
■ このスレッドは過去ログ倉庫に格納されています