【PHP】セッションについて語ろう！【PHP】

**nobodyさん** · 03/09/24 19:31

ブラウザを閉じたらセッションの効果がなくなるのって、
ブラウザを閉じることでクッキーを消しているからなのですね。。
知らなかったよーーーーうわーーーん

**nobodyさん** · 03/09/24 19:32

いちいちセッションの機能使わなくてもよく考えたら、
IPをキーにして
普通につくれるじゃん。。
と思ったんんだけどどうう？

**nobodyさん** · 03/09/24 20:24

1、スレ建て宣言…………１
2、開会の辞………………１
3、煽り………………住人有志
4、逝ってよし……………１
5、御前もな………………住人有志
6、決意表明………………１
7、祝電披露………………1の家臣
8、来賓挨拶………………1の母親
9、来賓挨拶………………1の主治医
10、余興……………………もな踊り保存会
11、余興……………………１騙り太夫
12、送辞……………………大検
13、答辞……………………１
14、板歌斉唱………………全員
15、閉会の辞………………スレッドストッパー
16、終了宣言………………ひろゆき（削除忍代読）

**nobodyさん** · 03/09/24 22:39

早くPHP5出ないかなぁ・・・。

**nobodyさん** · 03/09/24 22:40

>>2
世の中の全端末にグローバルIPアドレスを付与出来るようになったのなら、それでも良いんだろうけどな。
NATやNAPT、プロキシサーバなんてもんが存在してしまうわけだ。

**sage** · 03/09/24 23:20

>>5
それって何か問題ある？

**nobodyさん** · 03/09/24 23:48

完全ではない、という問題。

**sage** · 03/09/25 00:23

IPが変わる可能性がある、ということだよね。
変わらなければ問題はない。
けれども変わるから完全ではない。

でも用途によれば、問題なく利用できるよね。
使う目的によって、価値も変わってくるということだ。

**nobodyさん** · 03/09/25 00:41

あげ

**nobodyさん** · 03/09/25 00:57

セッションだけで1000まで逝くか?

**sage** · 03/09/25 02:07

実際、、どうやったら、セッションの代わりになるんですか？
誰かおしえてちょんまげ

**nobodyさん** · 03/09/25 10:43

IPが変わるとか、ブラウザの起動中だけとか言ってるけど
問題はその逆。
同じアドレスで複数の人がアクセスする可能性
同じクライアントで別人がアクセスする可能性

これがあるから、そのままでは使えない

**sage** · 03/09/25 17:47

っていうかIPをキーにするんじゃなくて、クッキーをキーにしたら、
セッションと同じ機能をまるごとつくれるんじゃないか？

**sage** · 03/09/25 17:49

>>12
同じクライアントで別人がアクセスする可能性

セッションでもそれが言える罠。

**nobodyさん** · 03/09/25 18:38

なんだこのレベルの低さは

**nobodyさん** · 03/09/25 19:19

>>14
いやだから、ログアウトやブラウザ閉じたら無効にする機能が必要

**sage** · 03/09/25 19:28

>>16
クッキーの有効期限を0にしたら同じじゃないの？

**nobodyさん** · 03/09/25 19:43

ｲｲﾖｰｲｲﾖｰあげ

**nobodyさん** · 03/09/25 21:11

今どきクッキーでセッション管理してﾓﾅｰ

**nobodyさん** · 03/09/25 22:05

>>8
アホか。

**nobodyさん** · 03/09/26 00:02

オマエラなぁー、せめて↓くらいひととおり見ろよ、とりあえず。

PHP マニュアル：セッション処理関数(session)
http://php.planetmirror.com/manual/ja/ref.session.php

クッキー仕様書日本語訳
http://www.futomi.com/lecture/cookie/specification.html

**nobodyさん** · 03/09/27 07:48

「ブラウザの戻るボタンで戻ってリロード→2重処理」
の回避策にsession使ってるけど邪道？

**nobodyさん** · 03/09/27 10:39

>>22
素直にDBの主キーと比較するとかもあると思うけど、それほど邪道でもないかと。
複数ページでのつながりを確保するのが目的だからな。

**nobodyさん** · 03/09/27 20:12

>>22
sessionでチェックという以前に、
遷移先画面にリダイレクトさせて、戻れなくするのが基本じゃないのかなぁ？？

**直リン** · 03/09/27 20:13

http://www.leverage.jp/bloom/qry/search.qry?function=first

**nobodyさん** · 03/09/27 20:30

>>24
エラーが出たとき入力内容が一切合切消えるのは非常に迷惑。

**nobodyさん** · 03/09/28 22:13

>>26
言ってる意味がよくわからん
それって、クライアント側のバッファ利用の問題で、二重投稿処理とは関係ない

**nobodyさん** · 03/09/28 22:40

戻れなくして不便を強いられるより、そういう配慮をしてくれる
ところのほうが好感が持てますね

**nobodyさん** · 03/09/30 15:43

age

**nobodyさん** · 03/10/01 12:48

php

**nobodyさん** · 03/10/01 18:29

sesson

**nobodyさん** · 03/10/01 18:45

Yahooのサイトでは、クッキーを使ったセッションで認証をやってて、クッキーが分かっても設定されてるクッキーが
Yahooドメインかどうかを判断して不正ができないようにしているみたいですが、これってクラックの危険性はありますか？
大丈夫そうだったらウチのサイトでも導入しようかと考えてます。

**nobodyさん** · 03/10/01 19:14

危険が無いわけじゃないが、あちこちで使われている手法だし
対策はされている。

**nobodyさん** · 03/10/02 04:12

session_startってやらないと、$_SESSって呼び出せないの？

**nobodyさん** · 03/10/04 01:01

>>34
php.ini

**nobodyさん** · 03/10/04 07:34

レベルの低さからしてネタスレか？

**nobodyさん** · 03/10/05 22:20

>>36

>>2から１０個ぐらいの書き込み見ると、完全にネタスレだと思ったけど、
その後、ベタっぽい低空飛行で展開されているようなので、俺も判断に苦
しんでる。

**age** · 03/10/11 00:19

>>22,26,28,33
などは、典型だが、良い子は、まねしないでね。晒し上げ。

**nobodyさん** · 03/10/11 00:23

根拠を書かない>>38を晒しあげ

**nobodyさん** · 03/10/11 00:39

phpマニュアルのセッション関数（セキュリティ部分）を抜粋してみたYO。

------------------------------------------------------------------------------
セッションとセキュリティ
外部リンク: Session fixation

セッションモジュールは、セッションに保存した情報を見ることができるのが
そのセッションを作成したユーザーだけであることを保証することができません。

セッションの完全性を積極的に守るには、そのセッションに紐づく値に応じた追加措置が必要です。
セッションに運ばれるデータの重要性を評価し、必要な保護策を講じて下さい。
これには通常、お金があかり、ユーザの利便性を損なうことになります。例えば、簡単な
社会工学的な策略からユーザを守るためには、 session.use_only_cookiesを有効にして下さい。
この場合、ユーザ側でクッキーは無条件に有効となっている必要があります。そうでない場合、
セッションは動作しません。

存在するセッションIDが第三者に洩れる手順は何種類かあります。
洩れたセッションIDにより、第三者が特定のIDに関連する全てのリソースにアクセスできるように
なります。まず、セッションIDがURLにより伝送される場合です。外部サイトにリンクを張っている場合、
外部サイトのreferrerログにセッションIDを含むURLが保存される可能性があります。
第二に、よりアクティブな攻撃者がネットワークのトラフィックをモニターしている可能性があります。
セッションIDが暗号化されていない場合、セッションIDはネットワーク上を平文テキストで伝送されます。
解決策はサーバ上にSSLを実装し、確実にユーザに適用することです。
-------------------------------------------------------------------------------

**nobodyさん** · 03/10/11 08:32

>>40
で？
そんな分かりきった事をのっけて何が言いたいの？？

**nobodyさん** · 03/10/11 10:46

>>41
初心者には分かりきったことではないんでしょう。
なぜつっかかるのかわからん。

**nobodyさん** · 03/10/11 21:38

>>42何が言いたいかわからん、ということを言いたいのじゃないのか？>>41は

参考 · 03/10/12 02:38

貧弱なセッション管理について
ttp://www.atmarkit.co.jp/fsecurity/rensai/webhole03/webhole01.html

・セッションハイジャック
・Session Fixation攻撃

**nobodyさん** · 03/10/12 02:43

>>39
キャッシュを public にすると、そのままブラウザ閉じても、そのＵＲＬを開けばまた
情報が出てくるからじゃないの？

**nobodyさん** · 03/10/12 02:47

キャッシュの話と>>28は関係ない
>>28は戻るボタンを用意して、内容を復元する配慮をしてくれと
言ってるので、ブラウザの戻るでのキャッシュを使えとは言ってない

**nobodyさん** · 03/10/12 02:51

>>33もあれだな。
クラックの危険があるから通常は対策していると言ってるので
指摘される理由がわからんな

**nobodyさん** · 03/10/12 03:08

セッションが使えるケータイってありますか？
ちなみに、J-PHONE J-SH05ではダメみたいです。

**nobodyさん** · 03/10/12 03:14

>>48
セッションの仕組み一度自分で作ってみたらどう？と思ったよ

**nobodyさん** · 03/10/14 21:07

session_set_save_handler()でDB(MySQL)にセッション情報を保存して管理する処理を
書いて普通にうまくいってたのですが、idを毎回変えたくて
ttp://www.asahi-net.or.jp/~wv7y-kmr/note/2003-09.html#YMD20030907_PHP
を参考に、疑似 session_regenerate_id()を作りました。

function session_switching() {
$qq = serialize($HTTP_SESSION_VARS);
if (!session_destroy()) {
session_id(md5(uniqid(rand(), 1)));
session_start();
$HTTP_SESSION_VARS = unserialize($qq);
return true;
} else {
return false;
}
}

んで、
session_start();
$noerr = session_switching();
ってやってみたんですが、関数の中のsession_start()で
「Fatal error: Failed to initialize session module」が出てしまいます。
destroy()したあとすぐにstart()するときに何か特別に注意することってあるんですか？
DB関連とsession_set_save_handlerはここをヒントにしました。
http://itbtech.itboost.co.jp/php/php_12.php
DBじゃなく、普通のファイル管理ではうまく動きました。
環境は、RedHat8.0, PHP-4.2.2, MySQL-3.23.56です。

**nobodyさん** · 03/10/14 21:11

訂正：session_switchingの２行目

if (!session_destroy()) {
　↓
if (session_destroy()) {

**nobodyさん** · 03/11/13 18:52

生きてるか？ｗ

**nobodyさん** · 03/11/19 18:30

ﾊｲ

**nobodyさん** · 04/01/08 05:26

ｱｹﾞ

実際の所さCOOKIE無効のクライアントでも同一か認識できるから
俺はCOOKIEへの保存をセッションに保存してるわけだが

邪道かな？

**nobodyさん** · 04/01/09 19:32

良いんでない？俺もそうするときがあるよ。

**ななしくん** · 04/01/27 22:58

セッション使ったプログラムかいてたんだけどさ、
使い方があまりにも簡単すぎて（$_SESSIONとクッキー使った場合）
こっちは身構えてるので、逆に解説とかがわかりにくかった(藁

**nobodyさん** · 04/01/28 03:07

>>56
確かにセッション使うのは楽だけど、
動作原理はしっかり理解する必要があるよ。

**ななしくん** · 04/01/28 06:10

>>57
様々な解説書サイトなどはそういう意図で、原理を説明されてるんだとは思います。
なんか、「どう使うか！！！」がなかなかわからなかったんですよ(藁

**nobodyさん** · 04/01/28 08:42

ｵｲﾗも初めてセッションを使い始めた時は、>>58と同じような感じだったなぁ。

セッションが機能するのに何ページ必要かとか悩んだ悩んだ。
a.html　フォーム
　|
b.php session_start(); $_SESSION['data']='a';
　|
c.php sessin_start(); $data = $_SESSION['data'];

**nobodyさん** · 04/01/29 07:51

同じく。実際やってみて思っていたより激しく簡単だったので
自分がやってることが、全然見当外れなのではないかと思ったりも。
もしかしたら、そうなのかもしれない。
一応自分の思ったとおりに動作しているし、人にチェックしてもらっても
ちゃんと動作していると彼は言う…。

>>57
使い方だけで、まだ原理とかあやふやなので
ちゃんと勉強してみようと思います。

**nobodyさん** · 04/02/01 18:12

>>54
どうやってクライアントを認識しているのか教えてほしいage

**nobodyさん** · 04/02/12 11:51

以前作ったショッピングサイト（注文数50件強/日※PHPではない）はクッキーでセッション管理してるけど、
カートに商品が入らないという問い合わせが、頻繁ではないがどうしても尽きない。
結局、クライアント側の設定に依存するし、やはり客に色々設定を強いるのはどうかと思う。

次やるとしたらamazonのようにURLに渡して管理したいけど、カート以前のページは
よほど商品数が多くない限り、一般的に静的に作りますよね？

そこで、URLでセッション管理したいがために、静的HTMLで済むものを、全部PHPで動的に
出力するのは馬鹿げた考えでしょうか？

**nobodyさん** · 04/02/12 16:36

>>62
いいんじゃない？
URLにセッションIDとか渡すのって普通だと思う。

**nobodyさん** · 04/02/14 08:52

俺はPHPじゃなくてJSPだが、静的ページも全部JSPだよ（商用）。
PHPでも同じようなことしてるひといるでしょう。

**nobodyさん** · 04/02/14 17:19

$_SESSION['msgs'] .= htmlspecialchars($_POST['msg'])
とすると、<input name="msg">に入力された文字列が
/tmpのセッションファイルに書き込まれると思いますが、
保存されるときの文字コードはブラウザから送られてくる
文字コードのままなんでしょうか？

1行目の方法で保存したものを、echo $_SESSION['msgs'];
で出力しても日本語部分が表示されません。
よろしくお願いします。

ブラウザはIEで、サーバー側はこうなってます。
mbstring.internal_encoding = EUC-JP
mbstring.http_output = SJIS
/tmpにある今回のセッションファイル　：　SJIS

**nobodyさん** · 04/02/14 19:01

こんにちは、PHP、Apacheという構成でi modeでセッション管理を行うことは可能なのでしょうか、可能であるとすればphp.iniやhttpd.conf等の設定部分や、またPHPスクリプトに特に留意するポイント等あれば教えて下さい。

**nobodyさん** · 04/02/17 21:52

できるけどGETでのセッション管理なんで認証とかにはつかっちゃ駄目

**nobodyさん** · 04/02/18 22:47

>>62
Amazonのように作るならOKじゃないの。
あれのカートは「誰の」という情報とは結びつかないようにしてあって、
会計の段階で「誰の」に結びつけるようにしてる。
# cookieが使える場合には、名無しさんAのカートのように、名無しさんも
# 区別して結びつけるけど。cookieに保存したセッションIDを使って。

その辺の個人情報や決済部分と切り離して設計できてれば
カート情報なんて商品リストの中から商品を選んだだけの存在だからね。

**nobodyさん** · 04/02/19 21:15

>>68cookieなしで amazon 使えるの？

68 · 04/02/19 23:37

>>69
普通に使えますよ、カート機能自体はSIDがURLに付加されてますし。
cookieが使える場合はその他の機能がプラスされたり、
カート機能の照合補正が行われたり。結構上手く出来てると思います。
気にならない(気づかない)というところも上手いところ。

**nobodyさん** · 04/03/04 23:25

session_startした後にPOSTしたページに
戻るボタンで戻ったら有効期限切れってなるのは
どう言う解決法があるのですか？

**nobodyさん** · 04/03/07 22:46

ﾎｼｭﾎｼｭ

**nobodyさん** · 04/03/09 22:32

おそレスですけど、
昔から、通販業者系はサーバサイドのセッション管理が標準だね。

**nobodyさん** · 04/03/18 02:35

セッションですか?!
私にお任せあれ!!!!!

**nobodyさん** · 04/03/18 05:54

>>71
session.cookie_lifetime integer

session.cookie_lifetimeは、ブラウザに送信するクッキーの有効期間を秒単位で指定します。値0は、"ブラウザを閉じるまで"を意味します。デフォルトは、0です。 session_get_cookie_params()および session_set_cookie_params()も参照して下さい。

**nobodyさん** · 04/03/18 09:33

ブラウザを閉じても１時間は有効であるように、
ini_set( 'session.cookie_lifetime' ,’3600’ );と記述しました。
書き方がおかしいでしょうか？
この書き方では、設定変更は出来ないようです。

Local Valueは3600に変わるのですが、Master Valueは0になっております。
Master Valueも3600には変わらないのでしょうか？

ini_setを使えばソースから書きかえられると思うのですが。

**nobodyさん** · 04/03/18 10:37

>>76
こっちのスレの方が相応しいけど、マルチポストいくないっ

**nobodyさん** · 04/03/18 10:53

>>77
一言添えればよかったですね。
ちょっとこちらで質問させてください。

**nobodyさん** · 04/03/18 12:14

>>78
76の内容については向こうで既にレスが付いているが？
Local Valueではなく、Master Valueでないと駄目という理由が判らん。
値の優先度はLocal(高)、Master(低)。ディレクトリごと指定したいのなら、
Apacheの場合だと.htaccessを利用すれば良かろ

**nobodyさん** · 04/03/18 14:49

ini_set( 'session.cookie_lifetime' ,’3600’ );と
記述して、セッションIDが追加されなくはなります。

しかし、// ini_set( 'session.cookie_lifetime' ,’3600’ );と
記述して設定をやめて、アップしても
セッションIDが作られないんです。

**nobodyさん** · 04/03/19 15:09

鯖を数日動かしてると、
セッションが不安定にならない？
漏れの鯖は三日くらいでセッションがプチプチ切れるようになる。
apacheを再起動すると治るけど、
コレってPHPの設定がおかしいからかな？

**nobodyさん** · 04/03/19 17:48

>>81
PHP のバージョンと OS は何？
Linux で PHP 4.2.x を使っていた頃に同じ状態で苦労したことがあるけど。

Apache の error.log に Segmentation Fault とかのログが残ってる？

**nobodyさん** · 04/03/19 22:04

>>82
child pid ***** exit signal Segmentation Fault

ログにはこんなもんがいくつか残ってました
OSはRedhatLinuxでapache1.3.27、PHP4.3.2です
なんか分かりますか？

82 · 04/03/20 00:30

>>83
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 が出そうだけど。

まあ、クリティカルなシステムをバージョンアップするなら、
十分にテストしてからにした方がいいと思う。

**nobodyさん** · 04/03/20 10:00

>>84
どうもです
ああ、やっぱバージョンのせいなんですかね
セッション機能にはmmを利用しているんですが、
どうせ処理速度には大差がないだろうし、filesを検討します
そのうちPHP5が出てきそうですが、
焦って飛びつくのは危険そうですね

84 · 04/03/20 10:55

>>85
PHP 4.2.x の頃に、パフォーマンス的に有利ということだったので、

session.save_handler = mm

にしていたことがあったけど、>>81 とほぼ同じ症状になった。
原因が分からず、随分悩んだ後、files に戻したところ、安定するようになった。

PHP 4.3.0 以降では確認していなかったけど、修正はされていないのかな。

**nobodyさん** · 04/03/20 12:40

いまfiles指定して動かしてみたところ、
特に処理速度にも問題ないし、とりあえず大丈夫
まあ今後>>81の症状がでるかどうかまだ分かりませんが･･･

でもコレはPHP4.3.2の問題じゃないかもしれませんね
apacheもlogrotateの時にサービスが落ちたりしますから
今じゃ毎朝cronでapacheを再起動してます（苦笑）

87 · 04/03/20 13:11

自分で書いてて思ったんですが、
apacheがちょくちょく落ちるのってかなりやばいよなあ（汗）
OSのレベルからアップグレードを考えるいい機会かもしれない

86 · 04/03/20 13:35

>>87
その状態だと、PHP の方が問題の可能性が高いと思う。
当時は、3日から 1週間にに一度再起動していたし、
apachectl で restart すると Apache が落ちてしまって、
apachectl start しないと起動しない状態になっていたので。

files に変更してからは、Apache が落ちることもなくなったので、
同じ問題だとすると、安定するかもしれないので、しばらく様子を
見てもいいかもしれない。

セキュリティ問題のこともあるので、簡単にバージョンアップできる
のであれば、バージョンアップした方がいいと思うけど。

**nobodyさん** · 04/03/20 15:55

>>86
mm ってなんですか？
当方セッション情報を MySQL に入れるハンドら作って動かそうとしているのですが、
既存のがあるんなら使っちゃおっかな～

**nobodyさん** · 04/03/20 16:33

>>90
maji mukatsuku

86 · 04/03/20 20:56

>>90
セッションの保存用の共有メモリ。
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 を起動。

90 · 04/03/21 03:27

おぉ！phpに既に用意されてるのね。さんきゅー
どれどれ・・ふむふむ・・
なーんだ、mmってモジュールの名前なのね・・
こっちか・・ http://www.ossp.org/pkg/lib/mm/
UNIXで動くのね・・どれどれ

#whereis mm
mm: /usr/ports/devel/mm

をを、Portsに入ってるジャン
んでも、こいつの動作検証せなあかんのか～めんどくさっ

以上５分で却下しますた。ごめん。

**nobodyさん** · 04/04/02 20:40

こんなんが出てくるんですけど・・・
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のフォルダもＣドライブに作りますたがダメです。

なんででしょうか？

**nobodyさん** · 04/04/02 20:46

>>94
すんません！いきなり判明しました・・・
１行目を空白にしていたのが原因でした。

1:　　　　←空白行にしていた
2:<?
3:session_start();
4:$_SESSION['register'] = 0;
5:
6:?>

1:<?
2:session_start();
3:$_SESSION['register'] = 0;
4:
5:?>

にしただけで治りました・・・
お騒がせしてすんません。

**nobodyさん** · 04/04/04 21:49

IE6でクッキー機能をOFFにしているのにセッションが使えてしまう。
PHPのSIDもOFFにしているのに・・・
なぜ？

・・・と書き込もうとしたら2chに書き込めないｗ
なぜ掲示板でクッキー必須なんだ？

**nobodyさん** · 04/04/04 22:30

>>96
見逃してるだけだよ。
セッションが使えているなら、cookieかURIパラメータの中に必ず埋め込まれている。

**nobodyさん** · 04/04/04 23:29

>>96
勘違いしてるだけだな。

**nobodyさん** · 04/04/04 23:53

>>96
コンテンツの中に埋め込む場合もあるけどね。

90 · 04/04/05 01:55

セッションが使えていると勘違いしているに２００＄＄

96 · 04/04/05 23:36

いや、セッションが使えてるのは間違いないのよ
<?php
echo $_SESSION["name"];
?>
とかでセッション情報をページに表示させるようにしてるから

URIパラメータもないし・・・
クッキーがコッソリ動いてるのか？とも思ったが、
2chに書き込みが出来なかったので、それも考えにくい・・・
自分のサイトだけクッキーが有効になってたのか？分からん・・・

**nobodyさん** · 04/04/05 23:45

テストに使用してるブラウザは？
IEでプライバシーポリシーうんにゃらで2chからのクッキー食べてくれないとか・・

**nobodyさん** · 04/04/05 23:55

Localだから

96 · 04/04/05 23:57

IE6でツール→インターネットオプション→プライバシー項目をMAXにして
「すべてのCookieをブロック」にしたのよ
ふつうコレでCookie機能は無効になるっしょ？

96 · 04/04/05 23:58

>>103
www

**nobodyさん** · 04/04/06 00:01

今やったらセッション使えなかったよ
なんやねんな

**nobodyさん** · 04/04/06 00:34

>>104
IEだけで動作チェックするのは間違い。

**nobodyさん** · 04/04/06 02:28

IEだけでしか使わない社内用とかならあり
んでも、Mozilla使った方が開発はしやすいぽ

**107** · 04/04/06 05:26

>>108
ちゃうちゃう。
最終的なユーザのことを考えた場合のチェックとしてはIEは外せないけど、
デバッグには向かないから使うなってこと。JavaScript系は特にデバッグしにくい。
但しJavaScriptの挙動はIEとMozillaは違うので、そこは留意しないと駄目。
XMLのチェックの部分では、IEの方が出来がいいと思う。

**107** · 04/04/08 00:30

そうだね～
XMLはIEの方が良い！
Mozillaのデバックコンソールってもう一声どうにかならんかなぁ
あとあと、CSSで幅の定義を１どっとずれて描画するのもどーにかならんかなぁ
はうっ！セッション関係無いし

**108** · 04/04/08 00:31

>>110 ごめん名前間違えたｗ

**nobodyさん** · 04/04/14 12:42

　セッションとは、　　　フラグである・・・

　ようやく気が付いた。

**nobodyさん** · 04/04/14 14:05

>>112
セッションなんて言うからよく分からないんだよな。

「ページを超えて持ち運ばれるフラグ」って言えば分かり易いね。

**教えてください・・・** · 04/05/16 22:13

以下の環境を構築しています。
＜環境＞
サーバ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を使う。
という状況なんですが、どうやれば、セッション情報の共有はできるんでしょうか・・

お教えください。。。

**nobodyさん** · 04/05/16 22:43

>114
セッションという機能がどういう風に実現されてるか、
またはどういう風にすれば実現出来るか考えてみれ

PHPのセッション機能は複数サーバ間で持ち越しすることは想定されていない（はず）なので、
書いてるようなことを実現したいなら、自分でセッション周りを作って、
セッション管理用のサーバを一つ用意すればいい。
が、そんなややこしいことするよりも、もっとスマートな解決法があると思うぞ。
根本的なとこから見直した方がいいと思う。

**nobodyさん** · 04/05/17 18:19

>114
DBは使わないの？
方法によっては簡単に出来るのに。

**nobodyさん** · 04/05/17 23:43

session.save_pathを指定しておいて、fsockopenするとか？

＃勘違いっぽいのでsageておこう・・

**nobodyさん** · 04/05/19 00:08

つーかJavaみたいにphp5ではクラスにセッション情報を保持できるようになるんでしょうか？

**nobodyさん** · 04/05/21 09:38

「ページを超えて持ち運ばれるフラグ」ってログイン後はhiddenで、一時的に生成されたユニークなIDみたいなの物をフォームに混ぜて本人確認しているってこと？？

perlでもできるよね。登録パスワードをフォームに混ぜちゃえばいいわけだし。
でもリファラー吐くブラウザだと他のサーバー行ったときにパスワードが入っているとまずいのか？？
だから一時的な物を生成するの？

**nobodyさん** · 04/05/21 14:11

>>119
セッションはサーバーサイドでデータを保持するのが最大の特徴

「クッキーの逆のもの」と考えてもいいかも
クッキーもセッションも「ページを超えて持ち運ばれるフラグ」には違いないが、
そのデータそのものをどちらに保持するかが違う
クッキーはクライアントで保存し、データそのものを含む
だけどセッションの場合にはデータを保持するのはサーバー側で
クライアント側ではデータそのものは保持しない
（代わりにクライアントを識別するためのセッションＩＤを保持する必要はあるが)
POSTでhidden使って渡すのも、さらにGETでURI渡しするのも、
ページを超えて運ばれるフラグには違いないけど、これらも結局は
クライアント（ブラウザ）でデータを所持しているんだよね

**nobodyさん** · 04/05/21 23:41

>>120
何かまとまってないぞ（笑）

要するに毎回データそのものをクッキーなりHIDDENフィールドなりで
運ぶという方法と
そうではなく、識別情報だけをクライアントとサーバー間で往復させて、
サーバー側にハッシュテーブルのようなものでデータを預けて置くという方法
の２つがある。

ぶっちゃけそれだけ。

**nobodyさん** · 04/06/01 20:28

>>121
書いているうちに訳分かんなくなっちゃったｗ
最初の1行だけで済ませばよかったかな

**nobodyさん** · 04/06/01 22:09

>>119
サーバ側で生成したサーバ側でしか利用しない値は、
わざわざhiddenで引き回したりしない。つか、してはいけない。
セキュリティホールにもなりうるし。

そういう用途のために(サーバ側の) session を利用するという理由もある。
情報の分離(隠蔽)だな。

**nobodyさん** · 04/06/02 16:13

session_register("session_a");
$b=array(1,2,3);
$session_a[b]=$b;

として

session_start();
unset($session_a);

しても$session_a[b]が消えてなかったんだが、バグですか？

PHP Version 4.3.3です。

**nobodyさん** · 04/06/03 15:13

バグと言うか、仕様じゃないの？

session_unregisterの注意を読むと、
unsetではフォーカス内の変数のみを消去して、
セッション内の登録は継続されるようだから、
セッションを再開した時にセッション内の登録変数を読み出し直すだけでは？
つまりそのunsetは現在の$session_aを削除するだけで、
$_SESSION['session_a']は削除しないんではないかと。

つーか、
$session_a['b']=$b;
って書くべきだし(typo?)、
session_(un)registerは非推奨

**nobodyさん** · 04/08/20 09:10

CGIに、PHPとPerlがあるんだけど、セッション管理は問題無くできるよね。
バージョンとか微妙なところで制限事項があるのかな？

**nobodyさん** · 04/08/20 15:48

はてさて、cookieに限定したセッションの話かしらん

**nobodyさん** · 04/08/22 18:42

サイトに会員制の部分をつくりたいのですが、パスワードをセッション
変数として保持しながらページを作成していくと、javascriptの
history.back()を使用してページを戻るときに「有効期限切れ」と
なってしまいます。

フォーム入力確認で戻る必要があるのですが、どういった方法で
会員制にするのがよいのでしょうか？

**nobodyさん** · 04/08/24 16:45

>128
history.backで戻ってセッション切れちゃうのは仕方ないね。
戻り先のページが別ページなら普通にリンク貼ればOKだと思うけど。。

**nobodyさん** · 04/08/24 16:52

結論
セッション(ﾟ⊿ﾟ)ｲﾗﾈ

**nobodyさん** · 04/09/02 15:49

言われただけの情報で結論出してセンスねえな～、想像力ゼロか？
それでカッコイイと思ってんのか？キモイ奴だな。

php使ってんならJS使わなくてもリファラからファイル（スクリプト）名と
必要ならクエリだけ取り出してリンクさせたらセッションも生きたままで
可変式のBACKボタンが生成できるだろ？

もっとも同一ドメイン内での話だけどな。

**nobodyさん** · 04/09/03 00:37

>>59
亀レスだけど、目から鱗。今日悩んでいたことが氷解した。
解説書に書いてあることが間違ってたよヽ(`Д´)ﾉ
とにかく、一言言わせてくれ。どうもありがとう。

**nobodyさん** · 04/09/03 09:53

ssl通信下でのみsessionＩＤをクライアント・サーバ間でやりとりする形で無い限り
セッションハイジャックの危険性は常につきまとうと思うのだが、
PCサイトならばcookieにsidを食わせて、sidの確認が必要なページのみsslで通信すれば
良いと思うが、携帯サイト等でsidをURLに引き連れまわす必要がある場合
全ページsslで通信という形にするしかないと思うのだが、どうしてる？

**nobodyさん** · 04/09/03 10:05

>>133
セッションに接続元のIPを記録しておいて
if ($_SESSON['ip'] != $_SERVER['REMOTE_ADDR']) {
die 'あぼーん';
}

**nobodyさん** · 04/09/03 10:14

>>134
携帯サイトでクライアントをIPで判断できないでしょ？
キャリア側のプロキシのIPだらけになるのでは？
PCサイトの場合でもIPでの判断だと、NATの内側のクライアントは一纏めにしちゃうの？

**nobodyさん** · 04/09/03 13:24

>>136
PCの場合はCookieオンリー前提で書いてました。説明不足すんません。
携帯は端末とプロキシのIPは一対一対応だと思ってたんだけど、もしかして違います？
（IPアドレス自体はセッションごとに変わりますが）
だったらこの方法は使えませんね。う～ん。

現行の3G携帯（というか、そのサーバー）はFOMAを除いてCookieに対応してますが
シェア最大のドコモがこれでは将来的にも難しいですね・・・。

個人情報など、重要なデータをセッションで使うときは最初から最後までSSLで通信して、
漏れてもあまり困らないデータは普通にセッションを使うしかないのかな。
Amazonなんかはそうなってるみたいですね。

**nobodyさん** · 04/09/05 23:33

age

**nobodyさん** · 04/09/06 14:10

>>133
まず前提からして間違ってる。

>PCサイトならばcookieにsidを食わせて、sidの確認が必要なページのみsslで通信すれば
>良いと思うが

良くない、cookie値はglobal変数「$_REQUEST」として常にサーバへ渡っている。
したがって、cookieに設定したセッションIDを必要とする時のみSSL通信下で行っても、
それ以外のページではsidは平文でネットワークを流れる事になる。

**nobodyさん** · 04/09/27 20:49:22

結局、全てをSSLで通信しないとセッションハイジャックは防げないということでFA?

**nobodyさん** · 04/09/28 01:10:51

あてずっぽう

**nobodyさん** · 04/09/28 17:26:54

　　　　　　は、

**nobodyさん** · 04/09/28 18:58:14

　　　　　　　　　　　　　　防げ

**nobodyさん** · 04/09/29 14:00:46

お上(経産省-産総研)はすべてのページをhttpsにしてcookieにsecure属性を付けるか
もしくはhttp用のcookieとhttps用のcookieの二つを発行しろと言ってるね。

ttp://securit.gtrc.aist.go.jp/research/paper/AIST03-J00017/csec200307-takagi-slide-sp1.pdf

ことネットワーク絡みの話に関しては、お上とその周辺が出してる情報は
とても役に立つよ。

**nobodyさん** · 04/10/06 22:15:29

基本的なことでスマンがセッションって何？

**nobodyさん** · 04/10/07 21:46:09

セッションってどこに保存されるの？

**nobodyさん** · 04/10/07 22:01:55

tmp

**nobodyさん** · 04/10/07 22:05:54

session.save_path

**nobodyさん** · 04/10/07 22:28:49

サーバー側に保存されるんだよね？
セキュリティ的にはどうなんだろう？

**nobodyさん** · 04/10/07 22:40:45

>>148
レン鯖でもセーフモードかCGI+suEXECでsession.save_pathを適切に設定してれば大丈夫。
ちなみにメモリやデータベースにセッションを保存するようにもできる。
ttp://jp.php.net/manual/ja/function.session-set-save-handler.php

**nobodyさん** · 04/10/07 22:54:49

ただ、PHPはセッションIDにcookieを使う際にsecure属性をつけられないので
個人情報を扱うようなときはセッションを使うドメイン全体をSSLで保護するか
$_SESSIONを使う代わりにIDの発行からデータの出し入れまで全部を独自に管理しないといけない。

**nobodyさん** · 04/10/07 23:27:27

む、難しいな orz

**nobodyさん** · 04/10/07 23:33:22

大丈夫、実際そこまでちゃんと気ぃ使ってるサイトなんてほとんどないからw

**nobodyさん** · 04/10/08 00:39:22

>>150
>ただ、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

**nobodyさん** · 04/10/08 00:56:47

素で知らんかった。マジありがとう。

**nobodyさん** · 04/10/08 01:37:35

>>153
setcookieの最後の引数で指定でもいい？
この場合setするcookieのkeyによってセキュア属性のあるなしになるのかな？

**nobodyさん** · 04/10/08 11:59:28

>>155
setcookie() だと最後の引数で指定すれば個別に secure フラグありとなしで
複数の Cookie を設定できる。例えば、以下のような感じで。

setcookie('secure_on', 'test1', NULL, '/', NULL, 1);
setcookie('secure_off', 'test2', NULL, '/', NULL, 0);

正しく Cookie を処理できるブラウザだったら secure_on の方の Cookie は、
https 接続の時にしか送信されない。

**nobodyさん** · 04/10/08 14:14:20

>>143の
>もしくはhttp用のcookieとhttps用のcookieの二つを発行しろと言ってるね。
に関してはsetcookieの引数で分けるのが良さげかな。

うーん、携帯サイトでhttp://～～のショッピングサイトってかなりあるんかね。
気にしだすと怖いな。
GETのSIDをhttpとhttpsで切り替えるとか？イメージわかん…

**nobodyさん** · 04/11/05 23:35:57

ヒロシです

MySQL使ってるんですが、
必要最小限の変数だけ session_register して
そのつどMySQLからデータひっぱってくるのと、
MySQLのデータ全て session_register しておくのでは
どっちがよかとですか？

ヒロシです

**nobodyさん** · 04/11/07 18:16:49

>>158
データの内容とアクセス頻度(規模)などによって一概にどっちが良いかは言えないし、
「良い」の基準が決まっていないとレスのしようもないんじゃない？

例）
・作成時に楽なら良い
・サーバー負荷を考えると良い
・セキュリティ的に安全だから良い
などなどなどなどなど・・・。

セッションの前に他のことを勉強しろよ。斬り。

**nobodyさん** · 04/11/07 21:42:34

ヒロシです

きれいに返されました。
セキュリティ・負荷面を重視しています。
よろしこです。

ヒロシです

**nobodyさん** · 04/11/09 18:20:01

アンケートページのフォームのValue値をセッションに入れて各ページ間で持ち回りってアブない？

**nobodyさん** · 04/11/12 12:40:22

PHPでセッションを使って管理ページに入りページの更新やメール配信などをしています。
使用人数は10人です。
ＯＳは基本的にwindowsでバージョンはＸＰや98など様々です。

ページの更新などをする際に5分くらいでセッションが切れます。
ほぼ10人ともその状態です。

セッションが頻繁に切れる原因とかってありますか？
漠然とした質問で申し訳ないでつ。。

**nobodyさん** · 04/11/12 13:38:08

Perlのセッションについて語るすれはどこですか？

**nobodyさん** · 04/11/12 14:19:13

>>162
これが参考になるんじゃないかな
http://www.asahi-net.or.jp/~wv7y-kmr/memo/php_security.html#PHP_Session_GC

**nobodyさん** · 04/11/16 15:55:39

このスレだけでご飯一杯食べれました。

**nobodyさん** · 04/11/16 16:34:38

食前酒みたいなスレやなｗ

**nobodyさん** · 04/11/17 21:13:10

ヤフーのセッション管理の仕組みって、どうなってるんでしょうか。
ページ移動するたびにDBにアクセスしてCookieと照合してます？

**nobodyさん** · 04/11/19 11:05:17

セッションで扱いたいクラスそのものをシリアライズして、セッションIDをKeyにし、
DBへ登録して使っている人って結構いる？
それともメモリー的にとか、DB容量的にとか、処理的に冗長だとかで、むしろ無駄？

**nobodyさん** · 04/11/19 15:38:04

Perlで固定のリクエスト投げるHTTPクライアント作ってるのですが、
返ってくるセッションクッキーをどうにかしてブラウザに食わせたいと思ってます。
firefoxのクッキーファイルに書き込むだけではだめでした。
expires付のクッキーはうまくいくのですが…
これを解決する手段はないものでしょうか？

Perlかどうかはどうでもよく、セッションクッキーの話なのでこちらに書き込みました。
もしもっと適切なスレがあれば是非教えてください。

**nobodyさん** · 04/11/21 01:16:45

>>169
どうも混乱しているようにしか見えないのだが…
HTTPクライアント作ってるって時点で「板違い」

セッションクッキーってのも意味わかんないし、
まずはセッションは何たるか、クッキーは何たるかを理解してから出直してね。
もしくは169の認識してる「セッションクッキー」と「クッキー」の違いを言ってみ。

**nobodyさん** · 04/11/24 00:14:55

>セッションクッキーってのも意味わかんないし
確かに「セッションクッキー」はセッションと言うにはアレかも知れんが、
簡易なセッションを実現するものではあるし、
なにより、みんな「セッションクッキー」って呼んでるじゃん。
で、普通、「セッションクッキー」に対して、単に「クッキー」って呼ぶのは、
「パーマネントクッキー(169曰く、expires付のクッキー)」でしょ。

**nobodyさん** · 04/11/24 06:52:52

>>169
セッションクッキーで通じるから別にいいけど
確かに用語の使い方がいろいろ不明な点があって
日本語として文が構築されてない

**nobodyさん** · 04/11/24 09:17:36

会員制のサイトつくるとき
セッションIDだけで管理してる？
セッションIDだけだと怖いので
ログインIDと暗号化したパスワードも
セキュアクッキーに書いて
毎回DBと比較してる。
これってやばい？

**nobodyさん** · 04/11/24 14:09:50

>>173
やばくはないと思うが
それじゃセッションIDを使う意味があまりなくね？
セッションIDの発行方法にもよるけど
PHPのセッション関数使ってるなら大丈夫じゃないの？

**173** · 04/11/24 15:43:40

>>174
レスありがとうございます

ログイン前の匿名情報（ショッピングカートのようなもの）を
セッションIDで管理、
ログイン後の情報はセッションだとちょっと怖いので
セキュアクッキーでアクセスの度に毎回ログインチェックをしてます。

セッションIDだけで
クライアントを特定するのって
会員制のようなサイトでも普通なんでしょうかね？

**nobodyさん** · 04/11/25 03:52:30

>>175
個人的な構築法としてはセッションIDとログイン情報を関連付けて
セッションIDきたらログイン情報みて毎回チェックするけど
規模がデカイ or サーバしょぼい　場合は毎回チェックするとレスポンス落ちるから
Yahooみたいに重要な処理のときだけログインチェックみたいな形にしてる

けど173のケースだとログイン前からの情報とも連携するみたいだし
それならセッションIDとcookie使ってても納得できる

毎回ログインチェックするのに越したことはないけど
やっぱりサーバのスペック的な問題でレスポンスが結構影響でてくるから
重要なページ（個人情報変更）とかだけ認証っていう形でもありじゃないかな？

良いセッションの使い方があれば他の人フォロー頼みます。

**nobodyさん** · 04/11/26 20:15:19

PHPセッションを生成した段階で、接続元IPを保持すれば、少なくとも
全く異なるネットワーク＆端末からの接続は排除できる。
(ＮＡＴ環境とか一部のＣＡＴＶ環境からのアクセスはどうしようもないけど)。

で、その上でブラウザバージョンとか「相手から送られてくる情報」を、
『セッション単位のワンタイム情報』として管理すればかなりいけるんでない？

まぁ、金銭扱う場合は「やりすぎ」ってのはないだろうけど、使う側の利便性を
考えればワンタイム情報として上記を扱う(＋独自のスパイス)でほぼ安全でしょう。

**173** · 04/11/26 20:37:10

>>176
やっぱりサーバ負荷は一番気になるとこですね。
たいへん参考になりました。
ありがとうございました。

>>177
大企業などアクセスのたびに
毎回IPアドレスが変わる環境もあるから
だめじゃないかな？

**nobodyさん** · 04/11/27 05:47:30

>>178
> 大企業などアクセスのたびに
> 毎回IPアドレスが変わる環境もあるから
> だめじゃないかな？
そんな場合、HTTPに限らず他のサービスでも認証が絡む奴は
大問題になりそうな希ガス...

気のせい？

**nobodyさん** · 04/11/27 07:24:52

>>179
IPで認証するの？

**nobodyさん** · 04/11/27 13:53:20

>>179
そういう仕組みですから
みんなそれを前提につくってるんだよ

**nobodyさん** · 04/11/27 14:23:13

>>179
今更何を言ってるんだ？

**nobodyさん** · 04/11/28 09:37:50

そっか、世間ではFTPとかtelnet/sshとか、そんな奴にもクッキーセッションみたいな
「IPが変わってもサービスを継続する」実装が結構あるんですね。
確かに作っちゃえば可能だなー＞セッション管理

ちょっと遊んでみよう(w

**nobodyさん** · 04/11/28 17:21:57

>>183
FTPとtelnet/SSHはステートレスなプロトコルではないので
セッション管理自体要らんと思う

**nobodyさん** · 04/11/28 23:38:51

$_SESSIONに"cid"っていう名前で登録しちゃいけないの？
他の変数は無事なのに、これだけたまに消えるんだけど…

**nobodyさん** · 04/11/29 12:38:23

>>184

>>178
> >>177
> 大企業などアクセスのたびに
> 毎回IPアドレスが変わる環境もあるから
> だめじゃないかな？

アクセスの度に変わるんだぜ?
Connection張りにきたからってACK返そうにも
すでにIPアドレスが変わっているんだぜ？

って、釣りか....>>178

**nobodyさん** · 04/11/29 14:14:13

>>186
それじゃインターネットに繋がってるだけで送受信できないし
ACK返す前に変わるとかそんなシステムあるの？

1回セッションした後でIP変わってもう一度セッションしたときに
どうなるかだろ
そもそも接続元IPを使ってどーのこーのって
今の時代に使ってるところないだろ

**nobodyさん** · 04/11/29 16:37:42

>>187
セッション汁！？

>>186
なんかかみ合ってない。
どういう意見なの？
できればはじめての発言でないなら前のレス番使ってくれ。

**nobodyさん** · 04/11/29 22:17:54

>>188
その回答は>>178だけが知っている。
「毎回IPアドレスが変わる環境」の“毎回”って何よ？

**nobodyさん** · 04/11/30 01:20:22

ttp://yougo.ascii24.com/gh/79/007983.html
黙って読め

**nobodyさん** · 04/11/30 09:58:03

>>189
もしかして
「ダイアルアップする度の間違いだろ」
とか思ってないよね？ｗ

**nobodyさん** · 04/11/30 12:42:02

>>190
「アクセスの度」っていう「アクセス」の定義が不明なんじゃない？
セッションはその通りだけど、PHPのセッションとはまたちょっと違う気がする。
HTTPセッションが切れても状態を引き継ぐための一例としてPHPセッションが
有るんじゃないの?

**nobodyさん** · 04/11/30 14:41:16

>>192
セッションが切れてない間は
IPアドレスが変わらないって言いたいの？

なにが言いたいのか
結論を書いてくれないと
話しが終わらないんだけど

**nobodyさん** · 04/11/30 21:15:35

>>193
さっさと話を終わらせてくれって言いたいの？

ならそう言えよ

**nobodyさん** · 04/11/30 22:03:43

>>193
逆でしょ？
「IPアドレスが変わっても(サービスのために)セッションを切らない」
為の仕組みが「PHPセッション」な訳ですよ。

つか、「セッション」の定義を表現せねばなるまいね。
IPセッションなのか、HTTPセッションなのか。

**nobodyさん** · 04/11/30 22:54:22

>>195
激しく同意！

ってかセッションってWEBでのセッションはHTTPセッションで
PHPセッションとかってセッション管理だろ
Perl=CGIみたいな初心者的勘違いだな

けど>>186とかACKが帰ってくる前にIP変わるわけだから
これはセッション自体成り立たない

>>192
それはセッション管理だろ

**nobodyさん** · 04/12/01 11:09:14

どれがだれの発言なんだか
全くわからん
1人の自演だったらすごいけど

**nobodyさん** · 04/12/01 15:47:55

ここにはｵﾚとｵﾏｲしかいませんよ？

**nobodyさん** · 04/12/01 17:02:20

>>198
よかった、一人じゃなかったんだ

**nobodyさん** · 04/12/01 19:13:52

少なくとも３人いるな(w