ブラウザを閉じたらセッションの効果がなくなるのって、
ブラウザを閉じることでクッキーを消しているからなのですね。。
知らなかったよーーーーうわーーーん
いちいちセッションの機能使わなくてもよく考えたら、
IPをキーにして
普通につくれるじゃん。。
と思ったんんだけどどうう？
1、スレ建て宣言…………１
2、開会の辞………………１
3、煽 り………………住人有志
4、逝ってよし……………１
5、御前もな………………住人有志
6、決意表明………………１
7、祝電披露………………1の家臣
8、来賓挨拶………………1の母親
9、来賓挨拶………………1の主治医
10、余興……………………もな踊り保存会
11、余興……………………１騙り太夫
12、送辞……………………大検
13、答辞……………………１
14、板歌斉唱………………全員
15、閉会の辞………………スレッドストッパー
16、終了宣言………………ひろゆき（削除忍代読）
>>2
世の中の全端末にグローバルIPアドレスを付与出来るようになったのなら、それでも良いんだろうけどな。
NATやNAPT、プロキシサーバなんてもんが存在してしまうわけだ。
IPが変わる可能性がある、ということだよね。
変わらなければ問題はない。
けれども変わるから完全ではない。
でも用途によれば、問題なく利用できるよね。
使う目的によって、価値も変わってくるということだ。
実際、、どうやったら、セッションの代わりになるんですか？
誰かおしえてちょんまげ
IPが変わるとか、ブラウザの起動中だけとか言ってるけど
問題はその逆。
同じアドレスで複数の人がアクセスする可能性
同じクライアントで別人がアクセスする可能性
これがあるから、そのままでは使えない
っていうかIPをキーにするんじゃなくて、クッキーをキーにしたら、
セッションと同じ機能をまるごとつくれるんじゃないか？
>>12
同じクライアントで別人がアクセスする可能性
セッションでもそれが言える罠。 >>14
いやだから、ログアウトやブラウザ閉じたら無効にする機能が必要 >>16
クッキーの有効期限を0にしたら同じじゃないの？ 「ブラウザの戻るボタンで戻ってリロード→2重処理」
の回避策にsession使ってるけど邪道？
>>22
素直にDBの主キーと比較するとかもあると思うけど、それほど邪道でもないかと。
複数ページでのつながりを確保するのが目的だからな。 >>22
sessionでチェックという以前に、
遷移先画面にリダイレクトさせて、戻れなくするのが基本じゃないのかなぁ？？
>>24
エラーが出たとき入力内容が一切合切消えるのは非常に迷惑。
>>26
言ってる意味がよくわからん
それって、クライアント側のバッファ利用の問題で、二重投稿処理とは関係ない
戻れなくして不便を強いられるより、そういう配慮をしてくれる
ところのほうが好感が持てますね
Yahooのサイトでは、クッキーを使ったセッションで認証をやってて、クッキーが分かっても設定されてるクッキーが
Yahooドメインかどうかを判断して不正ができないようにしているみたいですが、これってクラックの危険性はありますか？
大丈夫そうだったらウチのサイトでも導入しようかと考えてます。
危険が無いわけじゃないが、あちこちで使われている手法だし
対策はされている。
session_startってやらないと、$_SESSって呼び出せないの？
>>36
>>2から１０個ぐらいの書き込み見ると、完全にネタスレだと思ったけど、
その後、ベタっぽい低空飛行で展開されているようなので、俺も判断に苦
しんでる。 >>22,26,28,33
などは、典型だが、良い子は、まねしないでね。晒し上げ。 phpマニュアルのセッション関数（セキュリティ部分）を抜粋してみたYO。
------------------------------------------------------------------------------
セッションとセキュリティ
外部リンク: Session fixation
セッションモジュールは、セッションに保存した情報を見ることができるのが
そのセッションを作成したユーザーだけであることを保証することができません。
セッションの完全性を積極的に守るには、そのセッションに 紐づく値に応じた追加措置が必要です。
セッションに運ばれるデータの重要性を評価し、必要な保護策を講じて下さい。
これには通常、お金があかり、ユーザの利便性を損なうことになります。例えば、簡単な
社会工学的な策略からユーザを守るためには、 session.use_only_cookiesを有効にして下さい。
この場合、ユーザ側でクッキーは無条件に有効となっている必要があり ます。そうでない場合、
セッションは動作しません。
存在するセッションIDが第三者に洩れる手順は何種類かあります。
洩れたセッションIDにより、第三者が特定のIDに関連する全てのリソースにアクセスできるように
なります。まず、セッションIDがURLにより伝 送される場合です。外部サイトにリンクを張っている場合、
外部サイト のreferrerログにセッションIDを含むURLが保存される可能性があります。
第二に、よりアクティブな攻撃者がネットワークのトラフィックをモニターしている可能性があります。
セッションIDが暗号化されていない場合、セッションIDはネットワーク上を平文テキストで伝送されます。
解決策はサーバ上にSSLを実装し、確実にユーザに適用することです。
-------------------------------------------------------------------------------
>>40
で？
そんな分かりきった事をのっけて何が言いたいの？？ >>41
初心者には分かりきったことではないんでしょう。
なぜつっかかるのかわからん。 >>39
キャッシュを public にすると、そのままブラウザ閉じても、そのＵＲＬを開けばまた
情報が出てくるからじゃないの？
キャッシュの話と>>28は関係ない
>>28は戻るボタンを用意して、内容を復元する配慮をしてくれと
言ってるので、ブラウザの戻るでのキャッシュを使えとは言ってない >>33もあれだな。
クラックの危険があるから通常は対策していると言ってるので
指摘される理由がわからんな セッションが使えるケータイってありますか？
ちなみに、J-PHONE J-SH05ではダメみたいです。
>>48
セッションの仕組み一度自分で作ってみたらどう？と思ったよ session_set_save_handler()でDB(MySQL)にセッション情報を保存して管理する処理を
書いて普通にうまくいってたのですが、idを毎回変えたくて
http://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です。 訂正：session_switchingの２行目
if (!session_destroy()) {
↓
if (session_destroy()) {
ｱｹﾞ
実際の所さCOOKIE無効のクライアントでも同一か認識できるから
俺はCOOKIEへの保存をセッションに保存してるわけだが
邪 道 か な ？
セッション使ったプログラムかいてたんだけどさ、
使い方があまりにも簡単すぎて（$_SESSIONとクッキー使った場合）
こっちは身構えてるので、逆に解説とかがわかりにくかった(藁
>>56
確かにセッション使うのは楽だけど、
動作原理はしっかり理解する必要があるよ。
>>57
様々な解説書サイトなどはそういう意図で、原理を説明されてるんだとは思います。
なんか、「どう使うか！！！」がなかなかわからなかったんですよ(藁 ｵｲﾗも初めてセッションを使い始めた時は、>>58と同じような感じだったなぁ。
セッションが機能するのに何ページ必要かとか悩んだ悩んだ。
a.html フォーム
|
b.php session_start(); $_SESSION['data']='a';
|
c.php sessin_start(); $data = $_SESSION['data']; 同じく。実際やってみて思っていたより激しく簡単だったので
自分がやってることが、全然見当外れなのではないかと思ったりも。
もしかしたら、そうなのかもしれない。
一応自分の思ったとおりに動作しているし、人にチェックしてもらっても
ちゃんと動作していると彼は言う…。
>>57
使い方だけで、まだ原理とかあやふやなので
ちゃんと勉強してみようと思います。 >>54
どうやってクライアントを認識しているのか教えてほしいage 以前作ったショッピングサイト（注文数50件強/日※PHPではない）はクッキーでセッション管理してるけど、
カートに商品が入らないという問い合わせが、頻繁ではないがどうしても尽きない。
結局、クライアント側の設定に依存するし、やはり客に色々設定を強いるのはどうかと思う。
次やるとしたらamazonのようにURLに渡して管理したいけど、カート以前のページは
よほど商品数が多くない限り、一般的に静的に作りますよね？
そこで、URLでセッション管理したいがために、静的HTMLで済むものを、全部PHPで動的に
出力するのは馬鹿げた考えでしょうか？
>>62
いいんじゃない？
URLにセッションIDとか渡すのって普通だと思う。 俺はPHPじゃなくてJSPだが、静的ページも全部JSPだよ（商用）。
PHPでも同じようなことしてるひといるでしょう。
$_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
こんにちは、PHP、Apacheという構成でi modeでセッション管理を行うことは可能なのでしょうか、可能であるとすればphp.iniやhttpd.conf等の設定部分や、またPHPスクリプトに特に留意するポイント等あれば教えて下さい。
できるけどGETでのセッション管理なんで認証とかにはつかっちゃ駄目
>>62
Amazonのように作るならOKじゃないの。
あれのカートは「誰の」という情報とは結びつかないようにしてあって、
会計の段階で「誰の」に結びつけるようにしてる。
# cookieが使える場合には、名無しさんAのカートのように、名無しさんも
# 区別して結びつけるけど。cookieに保存したセッションIDを使って。
その辺の個人情報や決済部分と切り離して設計できてれば
カート情報なんて商品リストの中から商品を選んだだけの存在だからね。 >>68cookieなしで amazon 使えるの？ >>69
普通に使えますよ、カート機能自体はSIDがURLに付加されてますし。
cookieが使える場合はその他の機能がプラスされたり、
カート機能の照合補正が行われたり。結構上手く出来てると思います。
気にならない(気づかない)というところも上手いところ。 session_startした後にPOSTしたページに
戻るボタンで戻ったら有効期限切れってなるのは
どう言う解決法があるのですか？
おそレスですけど、
昔から、通販業者系はサーバサイドのセッション管理が標準だね。
>>71
session.cookie_lifetime integer
session.cookie_lifetimeは、ブラウザに送信す るクッキーの有効期間を秒単位で指定します。値0は、"ブラウザを閉じ るまで"を意味します。デフォルトは、0です。 session_get_cookie_params()および session_set_cookie_params()も参照して下さい。 ブラウザを閉じても１時間は有効であるように、
ini_set( 'session.cookie_lifetime' ,’3600’ );と記述しました。
書き方がおかしいでしょうか？
この書き方では、設定変更は出来ないようです。
Local Valueは3600に変わるのですが、Master Valueは0になっております。
Master Valueも3600には変わらないのでしょうか？
ini_setを使えばソースから書きかえられると思うのですが。
>>76
こっちのスレの方が相応しいけど、マルチポストいくないっ >>77
一言添えればよかったですね。
ちょっとこちらで質問させてください。 >>78
76の内容については向こうで既にレスが付いているが？
Local Valueではなく、Master Valueでないと駄目という理由が判らん。
値の優先度はLocal(高)、Master(低)。ディレクトリごと指定したいのなら、
Apacheの場合だと.htaccessを利用すれば良かろ ini_set( 'session.cookie_lifetime' ,’3600’ );と
記述して、セッションIDが追加されなくはなります。
しかし、// ini_set( 'session.cookie_lifetime' ,’3600’ );と
記述して設定をやめて、アップしても
セッションIDが作られないんです。
鯖を数日動かしてると、
セッションが不安定にならない？
漏れの鯖は三日くらいでセッションがプチプチ切れるようになる。
apacheを再起動すると治るけど、
コレってPHPの設定がおかしいからかな？
>>81
PHP のバージョンと OS は何？
Linux で PHP 4.2.x を使っていた頃に同じ状態で苦労したことがあるけど。
Apache の error.log に Segmentation Fault とかのログが残ってる？ >>82
child pid ***** exit signal Segmentation Fault
ログにはこんなもんがいくつか残ってました
OSはRedhatLinuxでapache1.3.27、PHP4.3.2です
なんか分かりますか？ >>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 が出そうだけど。
まあ、クリティカルなシステムをバージョンアップするなら、
十分にテストしてからにした方がいいと思う。 >>84
どうもです
ああ、やっぱバージョンのせいなんですかね
セッション機能にはmmを利用しているんですが、
どうせ処理速度には大差がないだろうし、filesを検討します
そのうちPHP5が出てきそうですが、
焦って飛びつくのは危険そうですね >>85
PHP 4.2.x の頃に、パフォーマンス的に有利ということだったので、
session.save_handler = mm
にしていたことがあったけど、>>81 とほぼ同じ症状になった。
原因が分からず、随分悩んだ後、files に戻したところ、安定するようになった。
PHP 4.3.0 以降では確認していなかったけど、修正はされていないのかな。 いまfiles指定して動かしてみたところ、
特に処理速度にも問題ないし、とりあえず大丈夫
まあ今後>>81の症状がでるかどうかまだ分かりませんが･･･
でもコレはPHP4.3.2の問題じゃないかもしれませんね
apacheもlogrotateの時にサービスが落ちたりしますから
今じゃ毎朝cronでapacheを再起動してます（苦笑） 自分で書いてて思ったんですが、
apacheがちょくちょく落ちるのってかなりやばいよなあ（汗）
OSのレベルからアップグレードを考えるいい機会かもしれない
>>87
その状態だと、PHP の方が問題の可能性が高いと思う。
当時は、3日から 1週間にに一度再起動していたし、
apachectl で restart すると Apache が落ちてしまって、
apachectl start しないと起動しない状態になっていたので。
files に変更してからは、Apache が落ちることもなくなったので、
同じ問題だとすると、安定するかもしれないので、しばらく様子を
見てもいいかもしれない。
セキュリティ問題のこともあるので、簡単にバージョンアップできる
のであれば、バージョンアップした方がいいと思うけど。 >>86
mm ってなんですか？
当方セッション情報を MySQL に入れるハンドら作って動かそうとしているのですが、
既存のがあるんなら使っちゃおっかな～ おぉ！phpに既に用意されてるのね。さんきゅー
どれどれ・・ふむふむ・・
なーんだ、mmってモジュールの名前なのね・・
こっちか・・ http://www.ossp.org/pkg/lib/mm/
UNIXで動くのね・・どれどれ
#whereis mm
mm: /usr/ports/devel/mm
をを、Portsに入ってるジャン
んでも、こいつの動作検証せなあかんのか～めんどくさっ
以上５分で却下しますた。ごめん。
こんなんが出てくるんですけど・・・
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のフォルダもＣドライブに作りますたがダメです。
なんででしょうか？
>>94
すんません！いきなり判明しました・・・
１行目を空白にしていたのが原因でした。
1: ←空白行にしていた
2:<?
3:session_start();
4:$_SESSION['register'] = 0;
5:
6:?>
1:<?
2:session_start();
3:$_SESSION['register'] = 0;
4:
5:?>
にしただけで治りました・・・
お騒がせしてすんません。
IE6でクッキー機能をOFFにしているのにセッションが使えてしまう。
PHPのSIDもOFFにしているのに・・・
なぜ？
・・・と書き込もうとしたら2chに書き込めないｗ
なぜ掲示板でクッキー必須なんだ？
>>96
見逃してるだけだよ。
セッションが使えているなら、cookieかURIパラメータの中に必ず埋め込まれている。 >>96
コンテンツの中に埋め込む場合もあるけどね。 セッションが使えていると勘違いしているに２００＄＄
いや、セッションが使えてるのは間違いないのよ
<?php
echo $_SESSION["name"];
?>
とかでセッション情報をページに表示させるようにしてるから
URIパラメータもないし・・・
クッキーがコッソリ動いてるのか？とも思ったが、
2chに書き込みが出来なかったので、それも考えにくい・・・
自分のサイトだけクッキーが有効になってたのか？分からん・・・
テストに使用してるブラウザは？
IEでプライバシーポリシーうんにゃらで2chからのクッキー食べてくれないとか・・
IE6でツール→インターネットオプション→プライバシー項目をMAXにして
「すべてのCookieをブロック」にしたのよ
ふつうコレでCookie機能は無効になるっしょ？
>>104
IEだけで動作チェックするのは間違い。 IEだけでしか使わない社内用とかならあり
んでも、Mozilla使った方が開発はしやすいぽ
>>108
ちゃうちゃう。
最終的なユーザのことを考えた場合のチェックとしてはIEは外せないけど、
デバッグには向かないから使うなってこと。JavaScript系は特にデバッグしにくい。
但しJavaScriptの挙動はIEとMozillaは違うので、そこは留意しないと駄目。
XMLのチェックの部分では、IEの方が出来がいいと思う。 そうだね～
XMLはIEの方が良い！
Mozillaのデバックコンソールってもう一声どうにかならんかなぁ
あとあと、CSSで幅の定義を１どっとずれて描画するのもどーにかならんかなぁ
はうっ！セッション関係無いし
セッションとは、 フラグである・・・
ようやく気が付いた。
>>112
セッションなんて言うからよく分からないんだよな。
「ページを超えて持ち運ばれるフラグ」って言えば分かり易いね。
以下の環境を構築しています。
＜環境＞
サーバ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を使う。
という状況なんですが、どうやれば、セッション情報の共有はできるんでしょうか・・
お教えください。。。
>114
セッションという機能がどういう風に実現されてるか、
またはどういう風にすれば実現出来るか考えてみれ
PHPのセッション機能は複数サーバ間で持ち越しすることは想定されていない（はず）なので、
書いてるようなことを実現したいなら、自分でセッション周りを作って、
セッション管理用のサーバを一つ用意すればいい。
が、そんなややこしいことするよりも、もっとスマートな解決法があると思うぞ。
根本的なとこから見直した方がいいと思う。
>114
DBは使わないの？
方法によっては簡単に出来るのに。
session.save_pathを指定しておいて、fsockopenするとか？
＃勘違いっぽいのでsageておこう・・
つーかJavaみたいにphp5ではクラスにセッション情報を保持できるようになるんでしょうか？
「ページを超えて持ち運ばれるフラグ」ってログイン後はhiddenで、一時的に生成されたユニークなIDみたいなの物をフォームに混ぜて本人確認しているってこと？？
perlでもできるよね。登録パスワードをフォームに混ぜちゃえばいいわけだし。
でもリファラー吐くブラウザだと他のサーバー行ったときにパスワードが入っているとまずいのか？？
だから一時的な物を生成するの？
>>119
セッションはサーバーサイドでデータを保持するのが最大の特徴
「クッキーの逆のもの」と考えてもいいかも
クッキーもセッションも「ページを超えて持ち運ばれるフラグ」には違いないが、
そのデータそのものをどちらに保持するかが違う
クッキーはクライアントで保存し、データそのものを含む
だけどセッションの場合にはデータを保持するのはサーバー側で
クライアント側ではデータそのものは保持しない
（代わりにクライアントを識別するためのセッションＩＤを保持する必要はあるが)
POSTでhidden使って渡すのも、さらにGETでURI渡しするのも、
ページを超えて運ばれるフラグには違いないけど、これらも結局は
クライアント（ブラウザ）でデータを所持しているんだよね
>>120
何かまとまってないぞ（笑）
要するに毎回データそのものをクッキーなりHIDDENフィールドなりで
運ぶという方法と
そうではなく、識別情報だけをクライアントとサーバー間で往復させて、
サーバー側にハッシュテーブルのようなものでデータを預けて置くという方法
の２つがある。
ぶっちゃけそれだけ。 >>121
書いているうちに訳分かんなくなっちゃったｗ
最初の1行だけで済ませばよかったかな
>>119
サーバ側で生成したサーバ側でしか利用しない値は、
わざわざhiddenで引き回したりしない。つか、してはいけない。
セキュリティホールにもなりうるし。
そういう用途のために(サーバ側の) session を利用するという理由もある。
情報の分離(隠蔽)だな。 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です。
バグと言うか、仕様じゃないの？
session_unregisterの注意を読むと、
unsetではフォーカス内の変数のみを消去して、
セッション内の登録は継続されるようだから、
セッションを再開した時にセッション内の登録変数を読み出し直すだけでは？
つまりそのunsetは現在の$session_aを削除するだけで、
$_SESSION['session_a']は削除しないんではないかと。
つーか、
$session_a['b']=$b;
って書くべきだし(typo?)、
session_(un)registerは非推奨
CGIに、PHPとPerlがあるんだけど、セッション管理は問題無くできるよね。
バージョンとか微妙なところで制限事項があるのかな？
はてさて、cookieに限定したセッションの話かしらん
サイトに会員制の部分をつくりたいのですが、パスワードをセッション
変数として保持しながらページを作成していくと、javascriptの
history.back()を使用してページを戻るときに「有効期限切れ」と
なってしまいます。
フォーム入力確認で戻る必要があるのですが、どういった方法で
会員制にするのがよいのでしょうか？
>128
history.backで戻ってセッション切れちゃうのは仕方ないね。
戻り先のページが別ページなら普通にリンク貼ればOKだと思うけど。。
言われただけの情報で結論出してセンスねえな～、想像力ゼロか？
それでカッコイイと思ってんのか？キモイ奴だな。
php使ってんならJS使わなくてもリファラからファイル（スクリプト）名と
必要ならクエリだけ取り出してリンクさせたらセッションも生きたままで
可変式のBACKボタンが生成できるだろ？
もっとも同一ドメイン内での話だけどな。
>>59
亀レスだけど、目から鱗。今日悩んでいたことが氷解した。
解説書に書いてあることが間違ってたよヽ(`Д´)ﾉ
とにかく、一言言わせてくれ。どうもありがとう。
ssl通信下でのみsessionＩＤをクライアント・サーバ間でやりとりする形で無い限り
セッションハイジャックの危険性は常につきまとうと思うのだが、
PCサイトならばcookieにsidを食わせて、sidの確認が必要なページのみsslで通信すれば
良いと思うが、携帯サイト等でsidをURLに引き連れまわす必要がある場合
全ページsslで通信という形にするしかないと思うのだが、どうしてる？
>>133
セッションに接続元のIPを記録しておいて
if ($_SESSON['ip'] != $_SERVER['REMOTE_ADDR']) {
die 'あぼーん';
} >>134
携帯サイトでクライアントをIPで判断できないでしょ？
キャリア側のプロキシのIPだらけになるのでは？
PCサイトの場合でもIPでの判断だと、NATの内側のクライアントは一纏めにしちゃうの？
>>136
PCの場合はCookieオンリー前提で書いてました。説明不足すんません。
携帯は端末とプロキシのIPは一対一対応だと思ってたんだけど、もしかして違います？
（IPアドレス自体はセッションごとに変わりますが）
だったらこの方法は使えませんね。う～ん。
現行の3G携帯（というか、そのサーバー）はFOMAを除いてCookieに対応してますが
シェア最大のドコモがこれでは将来的にも難しいですね・・・。
個人情報など、重要なデータをセッションで使うときは最初から最後までSSLで通信して、
漏れてもあまり困らないデータは普通にセッションを使うしかないのかな。
Amazonなんかはそうなってるみたいですね。 >>133
まず前提からして間違ってる。
>PCサイトならばcookieにsidを食わせて、sidの確認が必要なページのみsslで通信すれば
>良いと思うが
良くない、cookie値はglobal変数「$_REQUEST」として常にサーバへ渡っている。
したがって、cookieに設定したセッションIDを必要とする時のみSSL通信下で行っても、
それ以外のページではsidは平文でネットワークを流れる事になる。
結局、全てをSSLで通信しないとセッションハイジャックは防げないということでFA?
サーバー側に保存されるんだよね？
セキュリティ的にはどうなんだろう？
ただ、PHPはセッションIDにcookieを使う際にsecure属性をつけられないので
個人情報を扱うようなときはセッションを使うドメイン全体をSSLで保護するか
$_SESSIONを使う代わりにIDの発行からデータの出し入れまで全部を独自に管理しないといけない。
大丈夫、実際そこまでちゃんと気ぃ使ってるサイトなんてほとんどないからw
>>153
setcookieの最後の引数で指定でもいい？
この場合setするcookieのkeyによってセキュア属性のあるなしになるのかな？ >>155
setcookie() だと最後の引数で指定すれば個別に secure フラグありとなしで
複数の Cookie を設定できる。例えば、以下のような感じで。
setcookie('secure_on', 'test1', NULL, '/', NULL, 1);
setcookie('secure_off', 'test2', NULL, '/', NULL, 0);
正しく Cookie を処理できるブラウザだったら secure_on の方の Cookie は、
https 接続の時にしか送信されない。 >>143の
>もしくはhttp用のcookieとhttps用のcookieの二つを発行しろと言ってるね。
に関してはsetcookieの引数で分けるのが良さげかな。
うーん、携帯サイトでhttp://～～のショッピングサイトってかなりあるんかね。
気にしだすと怖いな。
GETのSIDをhttpとhttpsで切り替えるとか？イメージわかん… ヒロシです
MySQL使ってるんですが、
必要最小限の変数だけ session_register して
そのつどMySQLからデータひっぱってくるのと、
MySQLのデータ全て session_register しておくのでは
どっちがよかとですか？
ヒロシです
>>158
データの内容とアクセス頻度(規模)などによって一概にどっちが良いかは言えないし、
「良い」の基準が決まっていないとレスのしようもないんじゃない？
例）
・作成時に楽なら良い
・サーバー負荷を考えると良い
・セキュリティ的に安全だから良い
などなどなどなどなど・・・。
セッションの前に他のことを勉強しろよ。斬り。
ヒロシです
きれいに返されました。
セキュリティ・負荷面を重視しています。
よろしこです。
ヒロシです
アンケートページのフォームのValue値をセッションに入れて各ページ間で持ち回りってアブない？
PHPでセッションを使って管理ページに入りページの更新やメール配信などをしています。
使用人数は10人です。
ＯＳは基本的にwindowsでバージョンはＸＰや98など様々です。
ページの更新などをする際に5分くらいでセッションが切れます。
ほぼ10人ともその状態です。
セッションが頻繁に切れる原因とかってありますか？
漠然とした質問で申し訳ないでつ。。
Perlのセッションについて語るすれはどこですか？
ヤフーのセッション管理の仕組みって、どうなってるんでしょうか。
ページ移動するたびにDBにアクセスしてCookieと照合してます？
セッションで扱いたいクラスそのものをシリアライズして、セッションIDをKeyにし、
DBへ登録して使っている人って結構いる？
それともメモリー的にとか、DB容量的にとか、処理的に冗長だとかで、むしろ無駄？
Perlで固定のリクエスト投げるHTTPクライアント作ってるのですが、
返ってくるセッションクッキーをどうにかしてブラウザに食わせたいと思ってます。
firefoxのクッキーファイルに書き込むだけではだめでした。
expires付のクッキーはうまくいくのですが…
これを解決する手段はないものでしょうか？
Perlかどうかはどうでもよく、セッションクッキーの話なのでこちらに書き込みました。
もしもっと適切なスレがあれば是非教えてください。
>>169
どうも混乱しているようにしか見えないのだが…
HTTPクライアント作ってるって時点で「板違い」
セッションクッキーってのも意味わかんないし、
まずはセッションは何たるか、クッキーは何たるかを理解してから出直してね。
もしくは169の認識してる「セッションクッキー」と「クッキー」の違いを言ってみ。
>セッションクッキーってのも意味わかんないし
確かに「セッションクッキー」はセッションと言うにはアレかも知れんが、
簡易なセッションを実現するものではあるし、
なにより、みんな「セッションクッキー」って呼んでるじゃん。
で、普通、「セッションクッキー」に対して、単に「クッキー」って呼ぶのは、
「パーマネントクッキー(169曰く、expires付のクッキー)」でしょ。
>>169
セッションクッキーで通じるから別にいいけど
確かに用語の使い方がいろいろ不明な点があって
日本語として文が構築されてない 会員制のサイトつくるとき
セッションIDだけで管理してる？
セッションIDだけだと怖いので
ログインIDと暗号化したパスワードも
セキュアクッキーに書いて
毎回DBと比較してる。
これってやばい？
>>173
やばくはないと思うが
それじゃセッションIDを使う意味があまりなくね？
セッションIDの発行方法にもよるけど
PHPのセッション関数使ってるなら大丈夫じゃないの？ >>174
レスありがとうございます
ログイン前の匿名情報（ショッピングカートのようなもの）を
セッションIDで管理、
ログイン後の情報はセッションだとちょっと怖いので
セキュアクッキーでアクセスの度に毎回ログインチェックをしてます。
セッションIDだけで
クライアントを特定するのって
会員制のようなサイトでも普通なんでしょうかね？ >>175
個人的な構築法としてはセッションIDとログイン情報を関連付けて
セッションIDきたらログイン情報みて毎回チェックするけど
規模がデカイ or サーバしょぼい 場合は毎回チェックするとレスポンス落ちるから
Yahooみたいに重要な処理のときだけログインチェックみたいな形にしてる
けど173のケースだとログイン前からの情報とも連携するみたいだし
それならセッションIDとcookie使ってても納得できる
毎回ログインチェックするのに越したことはないけど
やっぱりサーバのスペック的な問題でレスポンスが結構影響でてくるから
重要なページ（個人情報変更）とかだけ認証っていう形でもありじゃないかな？
良いセッションの使い方があれば他の人フォロー頼みます。 PHPセッションを生成した段階で、接続元IPを保持すれば、少なくとも
全く異なるネットワーク＆端末からの接続は排除できる。
(ＮＡＴ環境とか一部のＣＡＴＶ環境からのアクセスはどうしようもないけど)。
で、その上でブラウザバージョンとか「相手から送られてくる情報」を、
『セッション単位のワンタイム情報』として管理すればかなりいけるんでない？
まぁ、金銭扱う場合は「やりすぎ」ってのはないだろうけど、使う側の利便性を
考えればワンタイム情報として上記を扱う(＋独自のスパイス)でほぼ安全でしょう。
>>176
やっぱりサーバ負荷は一番気になるとこですね。
たいへん参考になりました。
ありがとうございました。
>>177
大企業などアクセスのたびに
毎回IPアドレスが変わる環境もあるから
だめじゃないかな？ >>178
> 大企業などアクセスのたびに
> 毎回IPアドレスが変わる環境もあるから
> だめじゃないかな？
そんな場合、HTTPに限らず他のサービスでも認証が絡む奴は
大問題になりそうな希ガス...
気のせい？ >>179
そういう仕組みですから
みんなそれを前提につくってるんだよ そっか、世間ではFTPとかtelnet/sshとか、そんな奴にもクッキーセッションみたいな
「IPが変わってもサービスを継続する」実装が結構あるんですね。
確かに作っちゃえば可能だなー＞セッション管理
ちょっと遊んでみよう(w
>>183
FTPとtelnet/SSHはステートレスなプロトコルではないので
セッション管理自体要らんと思う $_SESSIONに"cid"っていう名前で登録しちゃいけないの？
他の変数は無事なのに、これだけたまに消えるんだけど…
>>184
>>178
> >>177
> 大企業などアクセスのたびに
> 毎回IPアドレスが変わる環境もあるから
> だめじゃないかな？
アクセスの度に変わるんだぜ?
Connection張りにきたからってACK返そうにも
すでにIPアドレスが変わっているんだぜ？
って、釣りか....>>178 >>186
それじゃインターネットに繋がってるだけで送受信できないし
ACK返す前に変わるとかそんなシステムあるの？
1回セッションした後でIP変わってもう一度セッションしたときに
どうなるかだろ
そもそも接続元IPを使ってどーのこーのって
今の時代に使ってるところないだろ >>187
セッション汁！？
>>186
なんかかみ合ってない。
どういう意見なの？
できればはじめての発言でないなら前のレス番使ってくれ。 >>188
その回答は>>178だけが知っている。
「毎回IPアドレスが変わる環境」の“毎回”って何よ？ >>189
もしかして
「ダイアルアップする度の間違いだろ」
とか思ってないよね？ｗ >>190
「アクセスの度」っていう「アクセス」の定義が不明なんじゃない？
セッションはその通りだけど、PHPのセッションとはまたちょっと違う気がする。
HTTPセッションが切れても状態を引き継ぐための一例としてPHPセッションが
有るんじゃないの? >>192
セッションが切れてない間は
IPアドレスが変わらないって言いたいの？
なにが言いたいのか
結論を書いてくれないと
話しが終わらないんだけど >>193
さっさと話を終わらせてくれって言いたいの？
ならそう言えよ >>193
逆でしょ？
「IPアドレスが変わっても(サービスのために)セッションを切らない」
為の仕組みが「PHPセッション」な訳ですよ。
つか、「セッション」の定義を表現せねばなるまいね。
IPセッションなのか、HTTPセッションなのか。
>>195
激しく同意！
ってかセッションってWEBでのセッションはHTTPセッションで
PHPセッションとかってセッション管理だろ
Perl=CGIみたいな初心者的勘違いだな
けど>>186とかACKが帰ってくる前にIP変わるわけだから
これはセッション自体成り立たない
>>192
それはセッション管理だろ どれがだれの発言なんだか
全くわからん
1人の自演だったらすごいけど
点呼とか死ぬほどｳｾﾞｰしさ、ｷﾓｲから消えてくんね？
>>204
そんな無意味なこと書く前に>>178の後半に突っ込み入れるなり
フォロー入れるなりしてみろよ。出来なきゃすっこんでろ。 結構入れ食いだと聞いたんですが、
ここでいいんですか?
かみ合わない会話が人格攻撃に発展したスレはココですか？
おまいらセッション使う時、ハンドラはファイル使ってますか？
それともDBハンドラ書いてます？
漏れはDBハンドラ使ってるけど。
>>210
バランシングしている複数のwebサーバでセッションを共有したいので
セッション情報はバックエンドのDBに入れてDBハンドラ使いまくりです。 俺はNFSでファイル共有してます。
物理的にバックエンドDBサーバと同じところにあるので
DBで共有しても良いのだが。特に意味は無いがファイルで。
>178 別に間違ってないと思うよ。
>183 とか >186 とかで訳分からん事言ってから話がおかしくなったみたいねえ。
>>211
漏れと用途が一緒だ。。
>>212
一度NFSでと考えたけど、オーバーヘッドでかくないですか？
DBハンドラでも大してかわらんかも。。。
ベンチはかってないから分からないけど。。
この前の書き込みはすいませんでした。
掲示板とか書き込むの初めてなので失礼なことをしてしました。
今、授業でPostgreSQLとPHPを用いてでセッション管理と
ユーザ認証をするプログラムを書かなければならなくて本から
ユーザ認証のプログラムをパクッたんですが、変更しなければ
ならない箇所があるらしく、さっぱり分かりません。
ﾛｸﾞｲﾝ後の画面のURLを直接入力してもﾛｸﾞｲﾝしていない状態
ではエラーがでて、そこにとべないようにようにするには
プログラムに何て書けばよいのでしょうか？
理解度が足りず、意味が通じないような質問になってすみません。
その授業とやらには、先生やら生徒やらはおらんのかのぅ。
>>221
パクった本をまずはよく読むこと。
"課題"なんだから、意味判らんままにコードを流用すんな。
つか、見るのはどんな先生かしらんが、
PHPぐらいなら出版物の量も少ないので
コードのパクりかたが、あからさまだとばれるよ。 俺もPHPじゃないけど課題出た時に
めんどくさくて書籍のサンプル丸写ししたんだが、先生にばれた。
しかし、先生が机に叩き付けた本は出版社も著者も全然違う人だった。
うーん。
コードは知らんが、解説は本も別の本からのパクリが入ってることもある。
かといって別の本や資料を全然参考にもしてない記述は、
アレ？と思うような変な(適正とは言いがたい)内容のものも、ちらほら
>>224
そう言うのは変数名くらい変えとかないと。
あと、インデント幅とかカッコの付け方とか
コメントを適当に付けたりして誤魔化すと完璧。 まじ役にたたねぇ。
まともな回答一つもないし。
結局そんなもんか。
つーかＰＨＰ読めないとその他の言語に移ると絶望的だぞ
これほど簡単な言語はない。arrayの取り扱いを
始めたみたときは正直チンポの先から汁がちょっと出た。ちょっとだけね
携帯でtopページ以外をﾌﾞｯｸﾏｰｸや直ﾘﾝ禁止にするという処理も
phpとセッション管理でできるのかな?
でも具体的にそういうスクリプト配ってる所ってないよね。
需要は充分すぎる程あると思うんだけど…
＞需要は充分すぎる程あると思うんだけど…
そんなケツの穴の小さいこと考えてんのお前だけだよ（ｶﾞﾊﾊ
>>1のことをﾌﾟｯて笑うスレですよ？
>>3書いたのｵﾚだ。懐かすぃ セッションってhiddenによるデータの持ちまわしや
URLにクエリ文字列を埋め込む方法等とどのように使い分ければいい？
ページの変遷すべてにformからsubmitで跳びたくなければURLで引き回しなさい
>>238は、
POST・GETの話じゃなくて、セッション使用とページ毎に全データ渡しの話の希ガス
ｵｲﾗは特に使い分けはしてない。その時の気分次第 >>229
セッション切れてたらTOPページにリダイレクトするとかで良いんじゃね？ つーかあれか。ページIDのようにボタンを押すたびに変わるような
ものはhiddenやクエリーで持ち、ログインIDやパスワードのような
ずっと持ちまわすようなものはセッションというような使い分けかな？
と自己レス。
俺はPerl⇒PHPときたが、Perlの場合は既存のスクリプトが腐るほどあったんでそれを参考にしながら覚えて
PHPはマニュアルが充実してるんで、殆どそれ見ながら覚えたヨ！
PHPは簡単だよ。・・・そう、知的障害児が道路を横断するのと同じぐらい
>>248
貴様の息子/娘が知的障害児で産まれるように強く願ってます ぶっちゃけPHPなんかリファレンス本を１日読めば次の日から
「PHPできます」って面接で言っちゃって大丈夫。
俺はそうした。余裕でしょこんな雑魚言語。
「できます」なんて指標は、客観的でないのでちっともあてに出来ない。
つうてもJava5年とか書かれてるスキルシートも全然あてにはならんが。
笑い事じゃなくて、PHPを習得するのに３日以上かかるようじゃ
正直プログラマとしてのセンスを疑うね。
>>251
そんなんで企業に入れるのか
やばくねぇかそこｗ お前等ってPHPを習得するのに１ヶ月とかかけるわけ？能無しか？
ちなみに俺は会社に入ったわけじゃなくて個人事業主として
業務委託されてるだけだけどな。
習得ってどの程度を言うのでしょうね
セッションの話まだー？ﾁﾝﾁﾝ
>>261
普通に業務をこなせるくらいだろ？
馬鹿かお前？ PHPのマニュアルに載っていたものです。
page2でgreenとcatと時間が表示されるはずですが、
Welcome to page #2
1969 12 31 23:57:00
page 1
しか表示されません。なんででしょう・・・(´・ω・｀)
--------------------------------------------
<?php
session_start();
echo 'Welcome to page #1';
$_SESSION['favcolor'] = 'green';
$_SESSION['animal'] = 'cat';
$_SESSION['time'] = time();
// cookieによるセッションが受け入れられていれば動作します
echo '<br /><a href="page2.php">page 2</a>';
// あるいは必要ならセッションIDを付加します
echo '<br /><a href="page2.php?' . SID . '">page 2</a>';
?>
-----------------------------------------------
<?php
session_start();
echo 'Welcome to page #2<br>';
echo $_SESSION['favcolor']; // green
echo $_SESSION['animal']; // cat
echo date('Y m d H:i:s', $_SESSION['time']);
// page1.phpでやったように、ここでSIDを使うことができます。
echo '<br /><a href="page1.php">page 1</a>';
?>
（追加）
OSとPHPは
Apache/1.3.28 (Win32)
PHP/4.3.10 です。
1969 12 31 23:57:00
と出るのは、$_SESSION['time'] がNULLのままだからでしょうね・・・
php.ini では
session.auto_start = Off
session.use_trans_sid = On
なんですが、他に設定するところなどがあるでしょうか？
まずは最初のページへアクセスした際に
php.iniで設定したsession.save_pathに
保存されているかを確認してみましょう。
あと、PHP will not create this directory structure automatically.
と書いてあるので、例えばsession.save_path = "C:\tmp"だったら事前に
tmpフォルダを作っておかないといけない。
>>267 >>268
お世話になります。
何故か php.ini で session.save_path = c:\php\sessiondata になってました・・・
（いつの間に？？？）
いろいろなページを参考にしていじっている内に、こうなってしまった様です。
一応、phpの下にsessiondataを作って動くようになりました。
基本的にはc:\tmpですよね・・・
お手数をお掛けしました。ｍ（＿ ＿）ｍ
セッション変数て、PHPデフォのファイルで管理すんのとDB使うのとぶっちゃけどっちが
早いの？軽いの？
どっちが速いかはようわからんっちゅーか、どーでもええし、どーせ大差ないとは思うんだけど
ユーザが増えたときにファイルだとinodeの制限を受けてエラー発生てのもあり得ますから。
だから大規模サイトならDB以外ありえない。
>>270
大規模の場合はバランサーはさんだりでめんどいからDBセッション多用する。 session_regenerate_id();を使うとc:\tmpにsess_***･･･････が残りまくります。
そこで、不要になったセッションファイルを削除しようと思います。
で、下記のようにしてみましたが、全然消えません・・・
session_start();
$session_id = session_id();//セッションＩＤのバックアップ
session_regenerate_id();//セッションＩＤ変更
unlink ("c:\\tmp\\sess_".$session_id);//以前のセッションＩＤのファイルを削除
ちなみに、
unlink("c:\\tmp\\sess_セッション番号の現物")を使うと確かに消えてくれます。
なんなんでしょか？これ？
>>274
セッションのタイムアウトくれば勝手に消えていくとは思うんだが。 >>274
ファイルがいやならＤＢセッションでもつかえば？ マジでハマっているんで、誰か教えて。
セッション管理を MySQL + PHP で考えていています。
$_SESSION['hoge'] = $hoge;
とかやった直後は、ハンドラで定義した関数が呼び出されて、
指定したテーブルに $hoge の内容をシリアライズしたような
文字列が格納されているのですが、その後に別の画面へ refresh で
遷移させた後、$_SESSION['hoge'] の値を参照すると何も入っていません。
テーブルを確認すると、直前まで入っていた文字列がブランクになっています。
ちなみに、全ての画面の先頭で session_set_save_handler() と
session_start() を行っています。
これが悪いんでしょうか？
>>274
PHP 5.1.0なら自動で削除されるよ。 >>279
ユーが定義したセッション保存関数を晒さない限りは何ともいえん。 >>281
こんな感じです。
class SessionHandler {
var $db;
function SessionHandler(&$database) {
$this->db =& $database;
}
function open($save_path, $session_id) {
$connectable = $this->db->connect();
$this->db->close();
return $connectable;
}
function close() {
return true;
}
function read($session_id) {
if (empty($session_id)) {
return "";
}
if (!$this->db->connect()) {
return "";
}
$sesid = $this->db->addQuote($session_id);
$sql = sprintf("SELECT sesdata FROM sessions WHERE sesid=%s", $sesid);
$result = $this->db->doQuery($sql);
if (is_object($result)) {
while ($row = $db->fetchAssoc($result)) {
$sesdata = $row["sesdata"];
}
$this->db->close();
return $sesdata;
}
else {
return "";
}
}
function write($session_id, $session_data) {
if (empty($session_id)) {
return false;
}
if (!$this->db->connect()) {
return false;
}
$sesid = $this->db->addQuote($session_id);
$sesip = $this->db->addQuote($_SERVER["REMOTE_ADDR"]);
$sesdata = $this->db->addQuote($session_data);
$sql = sprintf("SELECT * FROM sessions WHERE sesid=%s", $sesid);
$result = $this->db->doQuery($sql);
if ($this->db->getRowsNum($result) == 0) {
$sql = sprintf("INSERT INTO sessions (sesid, sesip, sesdata, sesupdated) VALUES (%s, %s, %s, %u)", $sesid, $sesip, $sesdata, time());
}
else {
$sql = sprintf("UPDATE sessions SET sesdata=%s, sesupdated=%u WHERE sesid=%s", $sesdata, time(), $sesid);
}
$is_write = $this->db->doQuery($sql);
$this->db->close();
return $is_write;
}
function destroy($session_id) {
if (empty($session_id)) {
return false;
}
if (!$this->db->connect()) {
return false;
}
$sesid = $this->db->addQuote($session_id);
$sql = sprintf("DELETE FROM sessions WHERE sesid=%s", $sesid);
$is_delete = $this->db->doQuery($sql);
$this->db->close();
return $is_delete;
}
function gc($expire_sec) {
$expired = time() - intval($expire_sec);
if (!$this->db->connect()) {
return false;
}
$sql = sprintf("DELETE FROM sessions WHERE sesupdated < %u", $expired);
$is_delete = $this->db->doQuery($sql);
$this->db->close();
return $is_delete;
}
}
よろしくお願いします。
>>279
なぜ保存関数が全部クラスにまとめられてるの？
session_set_save_handlerのサンプルでは単なる関数の集まりになってるけど、その辺大丈夫？
あとrefreshして表示されるアドレスのホスト名はおなじだよね？ URLにPHPSESSIDを出したくないのですが、どうすればよいのでしょうか？
>>287
session.use_trans_sid
session.use_cookies >>288
session.use_cookies = 1
session.use_trans_sid = 1
クッキーが使えるときはクッキーを使って渡し、
クッキーが使えないときはURLにパラメータを付けて渡す・・・ってことですよね。
ブラウザ側のクッキーは使える設定です。
が、全てURLにパラメータが付いてきます。
ちなみに、
session.use_trans_sid = 0
にするとページが変わる毎に新規にセッションIDが作られ、セッションが保持されていません。
なんなんでしょか？これ。
>>289
自己解決しました・・・
php.iniの中のsession.cookie_path =が
session.cookie_path = /tmp
になっていました・・・（何でだろ・・・？？？著しく不明。
session.cookie_path = /
で問題無く動きました。
>>290
！？
((((；ﾟДﾟ))))ﾌﾞﾙﾌﾞﾙ
。 。
/ ／ ﾎﾟｰﾝ！
( Д )
環境はwindowsですか？
Linuxならある意味凄いと思う。 ｵﾏｲﾗ教えてください。ｍ（＿ ＿；）ｍ
実はセッションファイルの置き場をtmpfsで作ろうと思います。
しかしながら、単純にtmpfsで/tmpを作って重ねてしまうと、既に入っている各種のファイルを使えなくなるため鯖の動作がおかしくなります。
んで、Apache+phpのセッションファイル専用に/tmp2を作ろうと思います。
が、php.iniのsession.save_pathを/tmp2にして再起動し、セッションが働くように動作させても、/tmpの方にセッションファイルが書き込まれて行きます。
/tmp2のパーミッションを777にしても同じです。
php.iniのsession.save_pathの設定が無視されているようです。
これはどういうことなのでしょうか？
教えて下さい。
>>293
わかった
先頭に;がついたままでコメントになってる >>294
ち・ちがう・・・orz
そこまでアホやないっつぅの (｀・ω・´)
>>295
じゃあスクリプトで
ini_set('session.save_path', '/tmp');
とかやってる
わけないよね
ていうか
ini_set('session.save_path', '/tmp2');
としたらどうなる。 >>296
どうもです。ｍ（＿＿；）ｍ
session_start();の前でやるってやつでしょ。
その手も考えたんですけど、それ以前に「なんでこ～なるの？？？」状態です。
php.iniの記載が無視されているんですよ。
別のphp.iniを読みに行っているのか？と。（そんなことは無いと思うが・・・）
最後の手段はini_set('session.save_path','/tmp2');ですね。
>>297
そのphp.iniが読み込まれてることは
確認した？ >>298
他に無いですから・・・
（ＺＥＮＤのツールがクサイのですが・・・）
尚、ini_set('session.save_path','/tmp2');では動くことを確認しました。
しかし、このini_set()で作ったセッションファイルも、
しかるべき確率で掃除してくれるんでしょうかね？
まぁ、暫く見ていれば分かる話なので観察しますよ・・・orz
お手数をお掛けしました。ありがとうございました。 (´・ω・｀)ノ~~~
あっ！ちゃんと掃除してくれますよ！
ini_set('session.save_path','/hoge');で作られたセッションファイルも消してくれるんですね。
1440秒経ったら１００分の１の確率で掃除してくれます。
これで行きますよ。
(´＾ω＾｀)ノ~~~~
サーバサイド側のセッション管理をした場合、例えばフォームを
行き来する場合はどうなるのでしょうか。
hiddenでセッションIDを持ち歩く必要性があるという解釈でよいの
でしょうか。
セッションを使うと必ずサーバー上の/tmpにファイルが作られブラウザを閉じるとファイルが残ってしまうのだけど
これを残さないようにすることってできるのかな？
>>306
セッションファイルはちゃんとガーベージコレクトされる筈だが。
ガーベージコレクトのタイミングやゴミとみなされるまでの時間を見直したら？ >>306
セッションハンドラをいじればDBにだって保存できるぞ。 >>303
＞hiddenでセッションIDを持ち歩く
すごく無意味＆恐ろしいこと言ってるな・・・ >>309
何が無意味でどう恐ろしいの？
俺も似たようなことやってるので教えて欲しい。
>>310
まんま続けてろ。
探してそのうち遊びに行ってやるw >>こういう人って知ってて教えてやらないの？
それとも知ったかぶりしてるの？
session.use_trans_sidがOnの状態にしてるのと変わんないよ＞hidden
そりゃcookieでSIDを持たせた方が、安全性は高まるけど
そうではなくGETとか選択してるのは、理由があってやってるんだろ？
セッション管理ってよくわからないんですけど
要するにパスワードかなんかでふるいにかけても
URLで「login=ok」みたいに渡しちゃってたら誰でも入れてこれは困ったな
見たいになるのを防ぐものなんですか？
>>316
＞「login=ok」みたいに渡しちゃって
ということを普通は最初からしないので、何とも。
セッションはその名のとおり、C/S間のやり取りが
継続しているということを実現するための仕組み。
かといって特に新しいことも、物凄く高度なことでもなく
かつてPHPの標準のセッション機能が無い頃は、各々が
ごく当たり前に独自にセッション機能を作ってやってたもんだよ。
(PHPlibとかあったけど)
だから今でも、何も難しく考えることはない。ただあるものを使えばいい。 クッキーなんで偽造出来るんだけどね。
セッション乗っ取れば認証回避出来るよ。
セッション生成場所にF5アタックされたら
めちゃくちゃセッション作ってくれるとおもうんだけど
貴殿らどういう対策してる？
>>320
セッション生成場所に限らずF5アタックは嫌なので
httpdより前にブロックしてる。 >>320
F5アタックなら全部同じセッションになるんでないの？ >>321
ううむ、やっぱそのレベルで防がないとだめかー
スクリプトレベルで防ぐのはあんまり賢くないかな
たとえば何件いったら新規セッションを一時発行しなくするとかね
>>322
クッキー拒否だと新規セッションにならない？ クッキー切ってる香具師にはセッションを発行しなきゃいい
>>321
httpdより前でブロックって
何を使ったらできるの？ 企業ではセキュリティ上クッキー食べなくさせてる所も多いので、そう言う客も失う覚悟だな。
httpd自身(libwrappr)とか鯖のIP処理レベルとか、本命のファイヤーウォールとか。
ちなみにルータで処理させるとルータの負荷が騰がって、他の通信にも影響が出るから辞めるべき。
mod_php弄って特定IPからのアクセスにRSTパケット返しちゃうってのも、F5連打廚にはいいカモな。
>>325
自分が使ってるのはiptablesだから、そこの中で。
つかhttpだけじゃなくて、sshやftpへのブルートフォースアタックがかなり多いので、
それらもまとめて弾いてる。Apacheでやるなら、mod_dosevasiveみたいなまんまの奴や
帯域を絞るモジュールなど色々あるよ。
phpで対処するってのは、自分で手を出せるところの範囲が狭くて
どうしようもない時の残された方法かと。F5アタックならphpでなくても
負荷のかかるコンテンツならどこを狙っても良いわけだし。
レンタルサーバなら、収容している他のユーザが対処してないなら意味無いしね。 セッションをDBに保管する方法は幾つかあるかと思いますが
皆さんのところは何を使ってますか？
とりあえずうちは「session_pgsql」を使ってますが他になにかいいのないですかねぇ。
全くのスクラッチと言うかオリジナル？
何からパクりましたか？
Cookie必須にできないのでhiddenで引き回してるんだけど、
IPとブラウザのUA（吐かない場合あり）チェックだけだと
例えば社内LANとかでのハイジャックの危険性は残ったままだよね？
何かいい方法ないですか？
>>332
社内LANってやつからWAN（サーバ）へのアクセスがプロキシ経由やNAT経由ならね。
<?
class session{
var $idname;
var $id;
function session($idname=""){
if(!isset($idname) || $idname=="") $idname="sid";
$this->idname=$idname;
$this->id=$_GET[$this->idname];
if($this->id==""){
$this->id=$_POST[$this->idname];
}
}
function init($id=""){
if(isset($id)&& ($id!="")){
session_id($id);
session_start();
$this->id=$id;
}else{
if(isset($this->id) && ($this->id!="")){
session_id($this->id);
session_start();
}else{
session_start();
$this->id=session_id();
}
}
}
function getId(){
return $this->id;
}
function VarExist($varname){
if(isset($_SESSION[$varname])) return TRUE;
return FALSE;
}
function get($varname){
if($this->VarExist($varname)) return $_SESSION[$varname];
return FALSE;
}
function set($varname,$value){
$_SESSION[$varname]=$value;
}
function remove($varname){
unset($_SESSION[$varname]);
unset($GLOBALS[$varname]);
return TRUE;
}
function clear(){
while (list($key, $val) = each($_SESSION)){
unset($_SESSION[$key]);
unset($GLOBALS[$key]);
}
}
}
?>
携帯のﾗﾝｷﾝｸﾞでｾｯｼｮﾝﾊｲｼﾞｬｯｸしたいんですが、携帯のIPでの接続のみ
ｾｯｼｮﾝ発行してるみたいで、PCではｾｯｼｮﾝを採取できません。
特定のｾｯｼｮﾝが欲しいのではなく発行されているｾｯｼｮﾝであればOKです。
ｾｯｼｮﾝの有効期限は3分？ﾗﾝｷﾝｸﾞアウトPhpでｾｯｼｮﾝ破棄しています。
何か有効な方法があれば教えてください。
DoCoMoの社員になってDoCoMo鯖からソケット使ってセッション取るとか(w
まぁ昔のRanklink改造した奴なんか簡単にセッションハイジャック出来たが、
セッション管理をファイルでやっててそのファイルがあるディレクトリに穴でもない限りは無理やね。
いまさらだけど、ＰＨＰとセッションは関係ないじゃん。
関数の話がしたいならＰＨＰスレじゃね？
うわ。。
10日以上前の書き込みにレスしちまった。。
ヤケクソage
１０日くらい間空けろよ。
なんか期待しちまうじゃないかorz
でも力任せでセッションID生成して送りつければいつかは突破できそうだけどな。
そのまえに鯖が異常に重くなってあぼんするだろうけど(w
次のｽﾚﾀｲはこうだね。
PHPじゃないとセッションつかえないと思ってる香具師の数→
ちょっと質問ですが、WebアプリでセッションにクライアントIPアドレス
を入れるという実装って普通しますか?
IPアドレスなんて変わることが多いからそんなことしないかと思っていたの
ですが
結論としてはやめておいた方が良い。
再利用しているところが多いし、同じIPアドレスを使ってるPCだって結構ある。
再利用というのは、DHCPから配られるIPアドレスという意味でいいですか?
あと同じIPアドレスを使っているというのは、NATのことでしょうか?
それくらいしか思いつかなかった。
データが通信途中全て第三者に取得されていると言う前提で、
SSLを使わないでデータを安全にやりとりする方法ってありますか？
JavaScriptとPHPでRSA暗号使ってやりとりしようと思ったのですが、
もっとスマートで対応するブラウザが多い方法ってありますか？
どなたかご存じの方教えていただけると嬉しいです。
大企業やCATVとかでファイヤーウォール噛ませててインターネットからは一つのIPに見えてるってネットワークは有る。
RSAで簡単にやるのがSSLなんだけどね。わざわざSSL使わずにどうにかするほうが面倒で難しい。
SSLに対応しないブラウザの為に、、と考えていたんですが、
きょうびJavaScriptに対応しないブラウザよりSSLに対応しないブラウザの歩が珍しいかな。。orz
>>350
俺は「一応の保険」みたいな感じでやってるなー
もちろん単なる簡単な保険程度の扱いだけど。
>>350
作る「もの」によるかな？
シビアなチェックが要求されるものならＩＰチェックには頼らないが、セッションハイジャックされたところで
そんなに大したもんでもない程度のものなら、ＩＰチェックすらしてないw
ＩＰチェック程度を実装する事もある
みたいな。 >>349
>>357の書く通りそれに頼ってしまうのは間違いだけど、セッションハイジャックを防ぐ方法としては比較的一般的に使われてる手法。
http://www.google.com/search?num=50&hl=ja&q=%E3%82%BB%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3%E3%83%8F%E3%82%A4%E3%82%B8%E3%83%A3%E3%83%83%E3%82%AF+%EF%BC%A9%EF%BC%B0+%E3%83%81%E3%82%A7%E3%83%83%E3%82%AF&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=lang_ja セッションハイジャックを防ぐ手法一つとしての存在するのは理解できるのですが、
実際にどんな場合に利用してます?
個人的には無意味かなぁと思っていたのですが
保険的に利用する場合ってIPチェックして違った場合、ログを残すとかそんな感じですか?
セッションを使ったログイン・システムを作ったのですが、
ログイン後、操作をしない（通信をしない）時間が数分続くと、
勝手にログアウトしてしまいます。
ブラウザを閉じたわけでもないですし、session.gc_maxlifetimeは1440あります。
明示的にログアウト処理をしない限りログイン状態が続くようにしたいのですが、
どこの設定をいじれば良いのでしょうか・・・。
>>358
そこ読んだけど
IPチェックはあまり意味ないって言ってる気がするが？ >>362
そう。あんまり意味無い。
でも、全く意味が無いってわけでも無い。
つまり、それ程シビアなチェックを必要とされないものなら、この程度でも良いかもね程度に考えておけばと。
とにかくだな。
あくまで１つの手段としてこんなのもあるよって話しなので、気に入らないのなら別の方法を実装すれば良いだけの話。
頭で色々考えるのも良いが、まずは先に物を作って実際に動かした方が余程勉強になるかと。
>>363
↓書き方悪かったな。
まずは先に物を作って実際に動かした方が余程勉強になるかと。
↑っていうのは、自分でセッションを使う簡易的なサイトでも作ってみて、それを自分でセッションハイジャック出来るかどうか試してみたら良いよって感じかな。
ハイジャックできてしまったら、それを防ぐにはどうすれば良いかを考えて改良し、また自分でハイジャックを試す。
そんな感じで完成度を上げていくと良いかなって思う。
IPチェックだけは意味が無いね。
他との併用でしょ。セコムのシール貼ってるだけに近い。実際の防犯にはちゃんと対策が必要。
元々HTTPはステートレス。
セッションを使って無理矢理ステートフルに見せかけてるだけ。
NATとかkeepalive切ってる場合も有るから、鯖でがんばっても無理が有ることが多い。
放置されてるところを見ると、くだ質に行くべきでしたね。。。 行ってきます。
質問させてください
セッションIDでログイン状態を判断するっていうのは
最初ログインしたときに
サーバ側のDBなどでセッションIDとログインしたユーザを
紐づけて管理するってことですよね？
それとは別に、ログイン時に
ログインIDとパスワードをクッキーに書き込んで
認証が必要なページでは毎回クッキーで判定しようと思うのですが
どんなリスクがあるのでしょう？
もちろんパスワードはMD5などの不可逆な変換を行い
クッキーもSSLのページのみで受け渡しします。
クッキーがPCに残るから、それを第三者に取られたとき危うい。
セッションIDなら一度ログアウトしてしまえば大丈夫だけど、
それだとログアウトしてもクッキーさえ持っていれば再度ログインできる。
>>368
すみません、クッキーと書きましたが
ブラウザを閉じたら消えるやつで
いわゆるセッションと同じようなもののことでした。
でもブラウザの実装によっては
一時的でもクライアントに保存されるため
リスクが高いということでしょうか。
>>369
強いて言うなら、その方法だと、XSSでクッキーを盗まれたときに、
パスワードを変更しない限り、その情報が使えてしまうけど、
XSS心配したらセッションも使えないし、
リスクという点では大差ないと思う。
セッションには、
・PHPに初めから実装されていて、手軽に使える
・ブラウザを閉じるまでは、以前の情報を継続して使える
という利点があるけど、単にログイン状態を保存しておくだけだったら、>>367の方法でも良いんじゃないかな。 >>369
永続的なパスワードは一時的であれクッキーに保存するべきではない。
XSSでコッソリ取られた日には目も当てられない。
>>371
パスワードそのままじゃない
って言ってるよ session.gc_maxlifetime を10にしているのに
10秒たってもセッションがタイムアウトしません。
なぜなんでしょうか？
環境はIIS5.0 / php5.0.3 です。
php.iniの値はこのようになってます。
session.auto_start Off Off
session.bug_compat_42 Off Off
session.bug_compat_warn On On
session.cache_expire 180 180
session.cache_limiter nocache nocache
session.cookie_domain no value no value
session.cookie_lifetime 0 0
session.cookie_path / /
session.cookie_secure Off Off
session.entropy_file no value no value
session.entropy_length 0 0
session.gc_divisor 100 100
session.gc_maxlifetime 10 10
session.gc_probability 1 1
session.hash_bits_per_character 5 5
session.hash_function 0 0
session.name PHPSESSID PHPSESSID
session.referer_check no value no value
session.save_handler files files
session.save_path no value no value
session.serialize_handler php php
session.use_cookies On On
session.use_only_cookies Off Off
session.use_trans_sid 0 0
>>372
よくよめ。
>>371
確かに。XSSの事忘れてた。。
つーか、わざわざパス記録すんなよ。メリット無いだろ。
セッションならXSSで取られてもIPで再度チェックすれば大体防げる。 IPでチェックって言ってる人は
IPが変わる環境のクライアントは切り捨ててるの？
可変範囲考えて実装すれば何も問題ない。
ホスト名が取得出来るんだったら、末尾から数えて二つめのドットまでマッチングとかな。
自分はもうちょっと複雑に可変範囲決定してるが、方法はいくらでもあると思われ。
>>375
携帯サイトのことを言っているのならIPチェック自体がナンセンス
通常のネットワーク環境を前提にしているとしたらIPが変わった時点でセッションが切れて当然 自分はIP変わった時点ではログアウトさせて無いなぁ。。
苦情来ない？実際自分も不便だと思うからneverにしてる。
クリティカルなやりとりに入る場合は再入力させてるけど。
>>379
いや、so-net.netとか。.ne.jpとかは末尾ドット二つじゃ足りなくて三つ遡ってマッチしなきゃならんが。
ヤフやらはてなやらアマゾンはそんな実装だな。>>378
関係ないけど、ヤフの会員登録(HTTP)は生でパス流してる。 更に関係ないけど、ヤフのログインてHTTPが標準なのは勘弁して欲しい。
チャレンジレスポンスだけど、途中に割り込まれたらっつーのもあるし、今時HTTPって。。
＞＞３８１
所謂セッション管理についてのスレだから一行動としてのセッションで捉えなくて良いと思ふ、
つか、今時そんな短時間でログアウトさせてる方が珍しい、金融機関除いて
確かにログアウトまでの時間については悩ましいところ。
セキュリティ的には短い方が望ましいが、長い方が明らかに便利。
あ、良いこと考えた。
httpsのリンクをお気に入りに登録させ、毎回ログインさせれば良いじゃん、とか考えたけど、
直接PCを操作される場合のリスクを考えてﾅｶﾀ。何か良い方法無いですか？
>>386
質問したいなら
要点をまとめてからにしてくれ $_SESSIONに値を入れたときに
ちゃんとセションファイルに書きこまれないときがあります。
具体的には
画面AでA.php?hoge=aで
$_GET['hoge']から'a'を取得し
$_SESSION['hoge']="a"といれ、
画面Bに行く。
このとき$_SESSION['hoge']はaとなっている。
ブラウザの戻るでAにもどり
URLにA.php?hoge=bと入力しエンターキー。
（$_SESSION['hoge']="b"となっているはず。）
画面Bに行く。
するとこのとき、
$_SESSION['a']の中には
aが入っていて、こちらの期待する値（b)になりません。
画面Aに戻り
URLにA?hoge=bと入力しエンターキーを押して
F5を押すと
$_SESSION['a']には期待値（b)が入っています。
どうしてこのようになるのか分かりません。
どなたか教えていただけないでしょうか。
また期待値を得るためにはどうしたら良いでしょうか？
>>388
とりあえずAとBのソースを書いてみろ。 >389
↓こんな感じで書いてます。よろしくおねがいします。
top.php
<?
session_start();
$_SESSION['name'] = $_GET['name'};
print($_SESSION['name']);//ここでは表示される値は毎回更新されている
:
:
:
//入力へのリンク
print ("<a href ='input.php'>リンク</a>");
?>
input.php
<?
session_start();
print($_SESSION['name']);//←ここで値が更新されず、前の値がでることがある。
：
：
：
?>
>>390
別に問題なく動作したが。。。
動作がおかしいときは、ブラウザがキャッシュから表示してるのだと思う。
session_cache_limiterを弄ったりしてなければ、あまり起きないはずだが、
どうしても以前の情報を表示したくないのなら、
input.phpにランダムなクエリーをつけるか、POSTでアクセスするかかな。 >>390
それから、本当にキャッシュから表示してるのか確かめたければ、
input.phpに現在時刻の表示とかを入れると良いよ。 >>390
どうもありがとうございます。
>input.phpに現在時刻の表示とかを入れると良いよ。
私もこれは試したのですが、
時刻は現在時刻を表示してるのですが
$_SESSIONの値は変わらずといった状態でした。
設定をもう一度見直してみます。
お世話になりました。 373で質問させてもらいましたが
もしかしたらここの主旨とずれていたかもしれません。
質問用スレッドにて質問させて頂きます。
どうもすみませんでした
質問ですがユーザ認証の仕組みは
みなさんは自作されてるのでしょうか？
PEAR::Authを使ってるのですが
このスレを読んで心配になりました。
PEAR::Authのログインしたときのクッキーの送受信を
セキュアな接続のときに限定することはできないですよね？
どうやってセキュアな接続って判定するの？
ブラウザのキャッシュとは限らんよ。
ブラウザに到達するまでに色んな所でキャッシュする装置が挟まってることは良くある。
ファイヤーウォールとか、キャッシュサーバとか、プロクシとか。
そういえばmixiって、一度ログインしたら、明示的にログアウトしない限り
ずっとログイン状態が続いてるよね。
あれってどうやって実現してるんだろう？（＆セキュリティ的に大丈夫か？？）
ソースでも見たら？
一時期流出してたしどこか有るでしょ。
>>398
たしかにネットカフェとかでmixiにログインして
そのままログアウトし忘れてそのまま帰っちゃうヤツとか多そうで危ないな。 それは自業自得だからしょうがない。
ネカフェでミクシなんてあり得ないでしょ。
個人情報漏れまくりだ。
いやぁ、mixiだからこそ十分ありうるぞ。
だってPCに詳しくない女性とかライトユーザが超多いから。
。。。
「次回から自動的にログイン」のチェックを入れてログインしないと、そんな事にはならないでしょ。
当たり前の実装が普通にしてあったぞ。
>>403
ハァ？？
「次回から自動的にログイン」にチェックを入れなくても
ログインが継続される仕様になってるから>>398のような疑問が出るわけだが。
今、俺が実際に実験してみたところ、「次回から自動的にログイン」をチェックせずに
ログインした状態でパソコンを再起動してもログインが継続されていた。
すなわちネカフェなどでの使用は超危険。 それは不思議だな。俺の環境では普通にブラウザ閉じた時点でログアウト。XP SP2+IE6
http://mixi.jp/help.pl#10dこうも書いてあるし、バグレポ送ったらｲｲﾝｼﾞｬﾏｲｶ。
正直、そんなバグあったら界隈で大騒ぎされているとおもうが。。 送られてくるCookieを見ると、次回から自動的にログインに
チェック無し
→有効期限無し＝セッション限り
チェック有り
→有効期限2011年5月28日
再起動後もログインが継続されるとすると、ブラウザ側に問題があるが、
そういうブラウザがあるなら気をつけた方が良いな。
セッションに詳しくないミクシ住人が、「次回から自動的にログイン」のチェックの危険性なんて理解できる訳ないじゃん。
便利だからって理由で「次回から自動的にログイン」にチェック入れてるでしょ。例え不特定多数が使うPCでも。
>>402
俺もIE6なんだが、、、バグだろうか？？
「自動ログイン」にチェック入れなくても、
ブラウザ閉じようがPC再起動しようが、ログイン状態が継続されてるよorz
みんなそうだと思ってたら、俺だけなのか・・・ 今、自分mixiのクッキーを調べてみた。
「自動ログイン」のチェック無しでログインすると
「BF_SETTING」って項目とデータ７行。
「自動ログインあり」だと、「BF_SETTING」に加えて、
「BF_SESSION」と「BF_STAMP」ってのが追加されるみたいだね。
>>411
チェック外しても昔送ったクッキーを生かしたままにしてあるとか？ >>414
少なくとも、ログイン画面を見ているときはクッキーが切れてる。 むしろログアウト判定のクッキー喰わせてる訳か。ダサイ設計だ。
ログアウトしてるのに、クッキー消したら認証突破できるんじゃね？
>>417
ん？ 何を見当違いのこと言ってんだ？
「ログアウト判定のクッキー喰わせてる」って、何を根拠に言ってんだか・・・ >>417
ログアウトは、有効期限切れのクッキーを送ってる。
つまり、クッキーを削除するのに通常使われる方法だぞ。 _, ._
（ ・ω・）
○=｛=｝〇,
|:::::::::＼, ', ´
.ｗｗし ｗ`（.＠）ｗｗｗｗ
あるwebアプリの開発を引き継いでるんだけど、検索結果とか一覧で同じ表示形式（ページングとカラムごとのソート機能付き）を共通で使いたい。
なおかつ、結果と、ソート状態、何ページ目は、他のページを開いても戻って来た時保持したい。
いちいちGETやPOSTからsqlクエリを毎度生成するのはめんどくさ過ぎるから、
検索条件が投げられた時点でsql文をつくって、まるごとセッションにぶち込む。URLにGETに含めるのは現在何ページ目、ソート対象、ソート方向、表示件数だけにしてしおうかと思ってるけど、こういうのはありなのかな？
>>429
2枚ウインドウを開いて違う検索しようとしたら、一方の検索条件が両方に適用されて
まともに使えないサイトがあった。
ウインドウ毎に区別されるようにしてね >>430
暫く前の@type(転職サイト)がそう。最悪の使い心地だった。
今は他社同種のと同程度には改良されてるけど。 >>430-431
なるほど。そういう弊害もあるのか。
いい事聞いた。ありがと。
やはり自分で想定できることってかぎられてるんだなと。
だったら新たに窓を開いたら窓ごとに別のセッションネームをつけてsql文を格納すればよさそうですね。
表示部分の関数がsql文をわたす設計で、結果からのリンクはすべてget渡しなんで、関数内でsql文を生成するとおそろしく面倒なことになりそうだ。 使い回ししやすいように関数化して、ダブらないように独自のセッションネームを吐くようにしてるけど、けっこう苦戦中。
でもこれが完成したらすげー楽になるかも。
だめだ。検索掛けるときにgetで投げるときもあれば、postでやるときもあるし、selectのonchangeつかって同時にget投げるときもある。
全ての入力を統合するのは、やっぱり無理っぽいかも。もう限界に近づいて来たというのに、ひどい状態になってしまったorz
コメントアウトだらけで自分でもわけわからん、
会員制サイトのログイン状態の保持にセッションを使ってるのですが
アイドル状態が続くとセッションが切れてしまうのを
回避する方法を考えています。
・ サーバでのセッション保持期間を長くする
・ セッションでなくクッキーなどによる管理に変更する
これ以外になにかいい方法があったら教えてください
>>438
普通に考えたらクッキーだよな。
面白い方法だと、例えば幅無しのフレーム作って、そっちのフレームの中を<META>タグで
何秒か置きに更新させて、その中でセッションを更新させてやるとか。
↑まぁこんな事やる意味が分からないけどね(w >>439
フレームはちょっと考えてました。
あとはFlashとかで定期的に通信するとか。
でも最後の手段と考えてます。
クッキーの場合は、パスワードも暗号化したクッキーとして
クライアントに返して
毎回そのクッキーで認証するって感じでしょうか？
>>440
「毎回」の意味が不明だけど。
認証に通ったらワンタイムパスワードを発行。 セッション保持はメモり喰うし、メモリリークが発生しやすい。
クッキーやワンタイムパスワードは総当たり攻撃で突破される。
そもそもHTTPなんてステートレスなプロトコルでセッションが切れるのは仕様。
SOAPとかCORBAとか他のプロトコル使ったら？
>>438
＞アイドル状態が続くとセッションが切れてしまう
session.cookie_lifetimeが「0」なら、
ブラウザを閉じない限りセッションも切れないだろ。
しかもそれってデフォルト設定だし。 >>444
削除されないよ。
実際自分のとこで動かしてるスクリプトは、
一度ログインしたらブラウザ閉じるまで何日でもログイン状態（＝セッション）続いてるし。 ブラウザがセッション切る場合もあるし、間に入ったNATやプロクシが切る場合も有る。
何日もログインできるってメモリリークしまくりに気づいてないだけじゃ？
>>446
お前が>>442で書いてることは間違い。
セッションはファイル（またはDB）で管理されるものであり、
メモリとは直接関係ない。したがってメモリリークなど起きない。
悔しかったら具体的にどういう根拠でメモリリークが発生するか書いてみたまえｗ >>445
他にアクセスがなければ削除されないでしょ
自分しか使わないシステム？ PHPのデフォのセッションの場合、
セッション管理はセッションIDをベースファイルネームにしたファイルベースで行われてて、
セッションIDに対応したファイルがあるかないかだけの話だと思うのだけど、
そこに一体どういう原理でメモリリークが発生するの？？？？
>>448
ガーベッジコレクションの動作についてよく勉強したまえ。
gcは、「ガーベッジ」となっていないものまでは回収しない。 >>442
＞セッション保持はメモり喰うし、メモリリークが発生しやすい
アタマ大丈夫？？ 総当たり攻撃で突破できる弱いユーザ管理です。
ファイルでもDBでもセッションが多数に成ればその分だけメモリの使用量が増えて、解放されないメモリが増えるよ。
事実上メモりリークしてメモリの再活用や再割当が出来なくなる。回収しないのではなくて回収できないメモリが増えていくのがメモリリーク。
セッションの保持にメモリが使用されるのはコンパイルオプション付けたときだけだろ。
メモリを使用したときでも、きちんと解放がセッション保持のプロセスに含まれてるしメモリリークするとは考えられないが。
>>453
＞ファイルでもDBでもセッションが多数に成ればその分だけメモリの使用量が増えて
↑こいつキチガイだなｗｗｗ
なんでセッションファイルの数が多いとメモリ使用量が増えるんだよｗ
そしたらセッション以外にもスクリプト自身とか、さまざまファイルが
多ければ多いほどメモリリークが発生する…って理屈になるなｗｗ ファイルハンドルでメモリ喰うから。プログラムやったこと無いの？
>>456
だから食わねぇっつーの。
そんなに自説を主張したかったらソース出せソースを。
誰がどこでそんな珍説を広めてんだ？ >>456はおそらく、Ｃ言語を中途半端にかじったヤツである悪寒。
で、PHPの自動メモリ解放機能とかを知らずに、
最近覚えた「メモリリーク」という言葉を連呼したくてたまらない厨房なのでは？？
まあ、何にせよセッション・ファイルとメモリリークとは関係ない話なんだけどね。 馬鹿だなあ。
１０万セッションのサイトでは、１０万セッション分のファイルハンドルが必要なんだよ。
十分メモり喰うし、長時間セッション使ってるとメモリリークも起きる。
>>459
10万セッションも必要なサイトの管理者はこんなスレ来ねぇよバカ。
っていうか10万セッションもあったらファイルハンドラじゃ無理があるからＤＢ使うし、
そもそもサーバ１台じゃなくて複数台に分散するんだよクズ。 っていうか10万セッションをファイル使って、
しかも負荷分散しないでやってたら（やれるとしたら）、
そもそもメモリリーク以前にもっと別の問題が起きると
思うけどなｗｗ
>>459
もう少し勉強したら自分がキチガイなこと言ってるって分かるよ。 >>459はセッション処理の為に開かれたファイルは、そのまま開かれているものとして語っているみたいだな。
恥さらしもその辺にしとけよ(w
つまりセッションは大規模サイトでは無理ってことですね。
phpで１０万セッション自体があり得ない。
その前にメモリ喰いまくりで太ったアパッチごとkillされる。
〃∩ ∧ ∧
⊂⌒（ ・ω・） はいはいわろすわろす
｀ヽ_っ⌒/⌒ｃ
⌒ ⌒
大丈夫。リナクスの場合は１０万セッションも接続北来た瞬間再起動するから(w
2003鯖を使ってる漏れは勝ち組。
>>465がトドメという感じだが、流石にもう食い下がってはこないか？？ しっかし、「セッションでメモリリーク」なんて珍説、はじめて聞いたよｗｗ
メモリリークしないって思い込みって、バグは無いって思い込みで出荷しちゃったシンドラエレベータの殺人プログラマ並みに馬鹿だな。
人氏んでるんやで。プログラムぐらいまともに組め。
>>473
だからメモリリークが発生するというのなら、
具体的な根拠や発生機序を示せよ。 港区のエレベータで死亡事故。
上昇直前に開ボタンを押すとメモリリークが発生して死亡事故が起きる。
メモリリークするって思い込みって、バグは無いって思い込みで出荷しちゃったシンドラエレベータの殺人プログラマ並みに馬鹿だな。
人氏んでるんやで。プログラムぐらいまともに組め。
セッションといえばWeb製作板の携帯スレで暴れてた馬鹿が居たが、同一人物っぽい香りがするな(w
> メモリリークが発生して死亡事故が起きる。
おめでたい思考回路ですね。
他人に何を言われても引き下がらない
とても漢らしい生き方だと思いました
テポドン２の発射もメモリリークが原因！ とか言い出しかねないなｗｗｗ
ハワイまで到達できなかったのはメモリリークでしょ。
セッションによるメモリリークの存在を強硬に主張しているが、
いまだに具体例や証拠が一切出されていないのが笑えるｗ
メモリリークの存在を必死に否定しているが、１０万セッション達成の具体例や証拠が一切出されていないのが笑える。
メモリリークの意味を知らないか、PHPがステートレスだと言うこと自体知らないんだろ。
>>444-450
これってどういうこと？
ブラウザが閉じられるまでgcが発生しないようになんて
できないよね？
そんな方法があるなら知りたい。
gc_maxlifetimeを1年ぐらいに設定するとかはなしでｗ
>>491-492
んなこたぁないだろう。
そしたら「ブラウザ閉じない限りはずっとログインし続けたまま」の
システムを作ることが不可能になるじゃんか。 つーか、session.gc_maxlifetimeって、
一体どのタイミングからカウントされた秒数なの？
最初のアクセスか、それとも最後のアクセスか・・・
>>495
不可能じゃないよ。
だってmixiとか、ブラウザ閉じなければ何日でもずっと
ログイン状態が継続してるし。 >>497
それ、セッションじゃなくて、クッキーにユーザー名とか保存してるだけじゃ無いの？
セッション何日も維持するなんて、セキュリティ上あり得んよ。
クッキーに何を保存してるか、見てみれば？ mixiはブラウザ閉じても次アクセスすればログイン状態では？
ちなみにクッキーは3個。すべてセッションオンリーはNO、有効期限は5年。
クッキーにユーザー名とか保存はしてない。直接の値が書き込まれているのは表示設定のみ。
ていうかそっちの方がセキュリティ上問題あるだろう
>>498
mixiのクッキーにはユーザー名（メアド）は書いてないよ。
>>499
＞セッションオンリーはNO
↑これどういう意味？？
＞mixiはブラウザ閉じても次アクセスすればログイン状態では？
「次回から自動ログインする」にチェックを入れてログインしたなら、ね。 >>500
＞セッションオンリー
ブラウザを終了したらクッキーを破棄するかどうか（これがオンだと有効期限は設定されない）
「次回から自動ログインする」にチェックしたらセッションオンリー=オフで有効期限5年のクッキー
チェックしなかったらセッションオンリー=オンのクッキー
という使い分けみたいですね。 >>501
あれっ、mixiのクッキー内にそんなデータあった？？
俺見てみたけど、見当たらないぞ・・・
っていうか「BF_STAMP」って何を指してるんだろう？ BFが何の略なのかも気になる。 >>501
言いたいことは分からないでもないが
セッションオンリー
って言葉はどうなの？
>>502
独自のセッションを実装してるみたいだね
ワンタイムパスワードみたいなのを3つくらい返してる
mixiって同じIDで別の端末からも利用できるの？
できるんならサーバ側の情報管理はたいへんそうだな
>>503
たしかにワンタイムパスワードみたいなのがあるね。
でも何回かログインとログアウトを繰り返してみたところ、
そのワンタイムパスワードみたいなのは変化しなかった。
ってことは「ワンタイム」じゃない！？ >>504
ってことはmd5とかで変換しただけのものを
クッキーに保存して毎回アクセスするたびに認証してるだけだね
セッションじゃないじゃん
一番確実な方法だと思うが
セキュリティ的にはhttpsでもないしだめだと思う
気になったからみてみた＞mixi
BF_SESSION
が 999_jidjaijdiojaidjhifjaj1399
みたいになってて先頭の数字が会員IDで後ろは
会員に対するランダムな文字列
（ってことで会員IDもかかれてるよ）
BF_STAMP
がパスワードになにかしたもの。
（パスワードを変更すると変化する）
BF_LOCAL_SESSION
が一時的なセッション管理用っぽい。
認証はCOOKIE（BF_SESSIONとSTAMP）で管理して
一時的なセッション情報（すぐに消えてもいいもの）を
BF_LOCAL_SESSIONのほうでやってると思われ。
ちなみに BF_ がなんの略かは分からない。
BFはmixiのコアライブラリBoofyのことやろね。
以前フロントエンドのソースコード流出で話題になってた。
>>506が神に一歩近づきました。
mixiはDBもロードバランスしてたりするから、
セッション管理とかもやたら複雑なんだろうなぁ。。。
もっと小規模のSNSだったなら、そこまで複雑なCOOKIEにならないで済むのかな？
たとえばOpenPNEとか。使ったことないけど。 >>511
> >>506が神に一歩近づきました。
> mixiはDBもロードバランスしてたりするから、
> セッション管理とかもやたら複雑なんだろうなぁ。。。
レイヤ7スイッチなら関係なし 通常完全ランダムなハッシュを一つクッキーに入れるのが一番良いんだと思うんだけど、
なんかmixiは色々と入れてるんだね。しかも会員情報と関係する物を。
>>513
完全ランダムなハッシュ？
どうやって認証するの？
セッション使うってこと？
ログイン時にランダムなハッシュをクッキーとして渡して、鯖側でユーザと結びつけて管理。
いや、別に変わった事言ったわけではないっす。セキュリティを確保する為の問題はそこからだよね。。
その普通が出来ていないサイトがなんと多いことか・・・
man in the middleを考えるならSecure発行も必須だな。
>>515
> ログイン時にランダムなハッシュをクッキーとして渡して、鯖側でユーザと結びつけて管理。
sessionと何が違うんだ？ セッションを語るスレなのにPHPに標準実装されてるセッションをただ"セッション"というのは紛らわｼｽ
ブラウザをIEの同義語で使うのと同レベル
>>518
sessionid 以外にハッシュを渡して
認証済みチェックをやるってことだろ
>>519
？？？ セッションを実装するには、何もPHPで標準で用意されてるセッションを使わなくてもいいよ
って事が言いたいのでは？違うか？？
>>520
PHPのセッション関数によって発行されたセッションIDをクッキーに渡すんじゃダメなの？
>>518も書いてるが、セッションIDとは別にわざわざハッシュ値を用意する意味がよく分からない。 CookieをSecureにすると負荷で死ぬから、うちでは自前でセッションハイジャック対策やってるんだが、
そうなると確かにsessionは使えないな。常にSSL使える環境なら標準のでいいんじゃね？
>>523
＞自前でセッションハイジャック対策やってるんだが、
＞そうなると確かにsessionは使えない
どうして？？ 対策としてログイン時のホストとUserAgentをセッションと結びつけてる。
これをsessionでやろうとすると結果的にハッシュが二重に保存される上に処理にロスが出る。
>>525
言ってる意味がわからん。
なんか無駄に難しく考えてないか？ そろそろセッションはPHPが普及する前からあるときがついてくだしあ。
>>525
それを実装したいなら、セッション変数にホストとUA入れればいいじゃん。
ただし、既出のように、それだけではセッションハイジャックを完全には防げないし、
ホスト(IPアドレス)がHTTP接続ごとに変わる環境のやつが利用できなくなる罠。 >>529
ごめん。書き忘れてたんだけど、
複数のアクセスポイントからアクセスする人もいるから、
一つのユーザに複数のセッションを割り当てて管理してます。
その過程でIDと複数のセッションを関連づけてるんだけど、
sessionだとIDからセッションの逆引きが出来ないので。。
ちなみに、ホストが変わるのは適度にマッチングして対応しています。
ところでNonSSLでセッションハイジャックを完全に防ぐ方法ってあるかな？
無理だよね。。まぁ、SSL使えって話しなんだろうけど。 物理的アクセスとかウィルスはやめてください＞＜
そういや、ny系のウィルスでCookieやらをzipにして流すのがありましたね。
>>530
っていうかSSLは通信内容を暗号化するだけで、
セッションハイジャックを防ぐ手段とは関係ないわけだが。 いやー、そりゃねーだろー。
不安になって確認しちまったじゃんか。ぐぐればざくざく出てきますぜ。
というか、ログイン認証時以外にも常にHTTPSで通信するなんて
実用的には無理があるよな。
mixiみたいに、認証時以外はHTTPにするしかないだろ。
負荷やレスポンスなどを考えると。
mixiはセッション管理的にアレだけどな。
重要な情報をやりとりするとき以外はhttpでいいんじゃね。
YahooもBiddersも楽天だってAmazonだってそうしてるし。
鯖側よりクライアントに負荷の比重を置くセキュアプロトコルが欲しいところだな。
https通信時にどういうやり取りが行われてるか見ればわかると思うが、
負荷を考えるのであれば全てをhttpsでやろうとするのはナンセンスだよな。
1日10アクセスぐらいのサイトなら好きにすりゃいいけど(w
会員専用以外のとこで
すべてをhttpsでやってるとこなんてあるの？
っていうかさぁ、みんな「セキュリティ、セキュリティ・・・」って念仏のように唱えてるけど、
実際にSSLを使わずに重要情報をスニファされた事件って、実例あるの？
そんなもん、いまだに聞いたことないんだが。
>>545
実際には存在しない「架空の泥棒」を生み出して大騒ぎし、
人々の恐怖心を煽って大儲けしているヤツらがいることに少しは気付こう。
だからキミらはいつまで経っても搾取され続けるんだよ。バカだから。
そんなキミらは映画『ボウリング・フォー・コロンバイン』でも見ると良い。 まぁ、プロと素人の意識の差だね。
素人の趣味でやるなら好きにすりゃいい。
>>547
論点のすり替え乙。
意識だのプロだの関係ない。
ただ単に想像の産物で騒いでるお前みたいなバカのことを笑ってるだけだよ。 セッションでメモリリークの次はこんな話題かｗ
本当レベル低いよな。
たしかにSQLインジェクションとかXSSとかが原因の事件はよくニュースになるけど、
SSLを使用しないせいでパケットスニファされた事件なんて記憶にないな。
誰か実例知ってる？
別に去る者追わずの個人サイトならそれでいいんじゃね。
ユーザの事考えなくても良い素人ならね。
>>555
何回もクドクドとウゼェなぁ。「素人、素人」って、お前は何様なんだボケ。
つーか歯車リーマンが何を偉そうに語ってんだバカが。
悔しかったら早くスニファが原因での情報漏洩事件を挙げてみろカス。 同一ネットワークでARPが届く範囲ならフニファできるけど
それ以外だと無理だとおもわれ。ルータでARPがクッションされるから。
>>556
獲得できるユーザが少なくなったり評判が悪くなるって言ってるんだよ。白書読め。
キミはユーザにそう説明してれば良いんじゃない？ >>558
言い訳は要らないから、早く実例出せよ。
SQLインジェクションやXSSでの被害実例は豊富にある。
だからその対策を講じるのは合理的な理由がある。
しかしSSLを使用しなかったことによるスニファでの被害実例は、少なくとも俺は知らない。
まさかお前、実際にはありもしない不安を煽って、客から高い金取ってるんじゃないだろうな？
そういうのを詐欺とかボッタクリと呼ぶんだぜ。 UZEEEE
勝手にベリサインにでも電凸でもしてSSLサイトでも作ってろ
いつまでスレ違いネタ続ける気だ死ね
まちげぇた
SSLサイト→SSL叩きサイト
掲示板のルールすら守れないやつが正義漢振るな
ゴミが
>>559
まさかここまで言っても分からない馬鹿だとは思わなかった。
被害がある被害がないは関係ないんだよ。ユーザがそれを気にしているかどうか。SSLを使用しているかどうかをチェックするユーザがいる事実、これだけが大事。
XSS、インジェクション、それらの対策がなされているかチェックしてからサイトを使うユーザが何処にいる？
それに対しSSLのチェックは簡単で、大きくメディアにも取り上げられている。また、上にも挙げたとおりいくつかの白書に載っている統計にもユーザがそれらを判断基準にしているとの統計が出ている。
お前みたいなユーザ数を気にする必要のない素人には関係ないがな。ユーザ数獲得を目的とする"プロ"の"SSL使用"の何処が非合理なんだか。
セキュリティよりもお前は自分の馬鹿さ加減を気にした方が良いな。 これ以上エサを与えんなよ
空気読まない質問に答えてやってもいい相手は小さい子供だけだ
だから素人は好きにやっとけって事でＦＡで終了
いつまでやってんだか。。。
セッションで呼び出す毎にハッシュ変更する機能付けるのってどうやってやるんだっけ？
何処かで見たような気がするんだけど思い出せん
>>565
session_start();
session_regenerate_id();
こゆこと？ >>562
いやぁ、スゴい論点ずらしの逃げだね。見事な負け犬っぷりだｗｗｗ
お前みたいな馬鹿システム屋がいるせいで、ますますド素人の客やユーザーたちは
「SSLさえあれば安全！」みたいな間違った認識を増大させ、
もっと重要かつ事件が頻発している穴をふさぐための費用を出そうとしない。
それからユーザ数獲得云々とか、お前の論理なんてどうでもいいわけ。そんなの誰も聞いてないだろ。
そうじゃなくて「SSLが無い場合の危険度＝過去に起きた被害実例」を挙げてみろよ、って言ってんの。
もしユーザからそれを質問されたらどう答えんの？ あ？
お前の論理でいくと、「ユーザ数獲得を目的とするプロ」なら、上記の質問には答えて然るべきだよなぁｗｗｗ ユーザは使用者、君が言ってるのはクライアント。ユーザはわざわざSSLが無いサイトを選んだりしません。
在日の君にはまず日本語を覚えて貰わないと話しにならないなぁ。
しかも、>>555に最初にレスしてきたのは君でしょ。それがルートレスになってるんだからそのレスに基づいて話すのは当たり前。論点をずらさないで欲しいね。
まぁ、君の質問にも答えてあげると、情報の盗聴というごくごく受動的な行為は被害を受けたと認識する事は出来ないってこと。
被害実例？気づいてないんだから少ないのは当たり前。普段と何ら変わりないのにどうやって気づく？個人情報漏洩した企業の"情報の悪用は確認できない。"という言い訳と同じ。
その前に君はなぜベリサインなどの企業が成り立っているか考えるべき。受動的攻撃の検知に疎いのは良いとして、こちらは世間一般で分かる常識だ。
"間違った認識をする奴がいるから"ベリサインは成り立つ。そんなはずがないだろう。もう少し謙虚に生きた方が多くのことを学べるよ。 長文は読む気も書く気もしないので。
ま、クレジットカード番号送るのに、SSLも使ってないサイトを使いますか？って事だ。
で、素人は好きにやっとけって事でＦＡで終了。他所いってやってくれ。
きっと考えが営業的なんだと思うよ。
お金を投入して、それに見合う効果があるのかどうかという話。
観測できない被害は、あったとしても気づいていなければ、会計的に被害額を算出不能なので被害に遭ってないのとのと同じ。
また、その観測できない被害を被るのは、多くの場合サイトの運営側でなく利用者の側なので被害を受けるとみなさないとする向きもあるかと思う。
そういう考え方は賛同はできないけれど、「あり」な考えかたの一つだと思う。
利用者から安全でないと思われ、最初から利用を控えられるということによる損失。
情報流出の被害が発覚した場合の信用失墜による損失。
こういったものを軽く見積りすぎているように思います。
もちろん、被害が発覚して問題になったときの対応にかかるコストも含めて、事後対応のほうがコストが安いと思うならそれもありです。通常はかなり高くつくようですけど。
一言で書けば価値観の違い。
ボッタクリと思うのなら使わなければ良い話。
価値観の押し付けウザ。長文ウザ。
で、素人は好きにやっとけって事でＦＡで終了。
頼むから他所いってやってくれ。
>>571
お前が一番ウザいということに早く気付けよチンカスくん。
>>568で自ら長文書いてるし。お前ウザいんだよ。５回くらい氏ねやボッタクリ屋。 それともう言い訳は聞き飽きたから、
早く「SSL不使用によるクレジットカード番号流出」の実例を挙げろ。
言い訳や、捨てゼリフによる逃げはもう飽きたからいいよ。
>>574
ん？長文書いてる奴は俺じゃないぞ？？
SSL不使用によるクレジットカード番号流出？そんなのｼﾗﾈｰﾖｗ
ま、クレジットカード番号送るのに、SSLも使ってないサイトを使いますか？って事だ。
価値観の押し付けウザ。長文ウザ。
で、素人は好きにやっとけって事でＦＡで終了。他所いってやってくれ。
クレジットカード番号送るのに、SSLも使ってないサイト
↑で金を取る方がボッタクリだと思った。
あと>>575の人コテハンにしてくれ。ｱﾎﾞﾝしとくから。 >>578
準会員制みたいなもんですね
微妙だけど >>576
だから逃げるなって、チンカス。
「クレジットカード番号送るのに、SSLも使ってないサイトを使いますか」って、
お前の主張なんか誰も聞いてないんだよ。早くSSLを使わなければ問題が起きるという実例を示せ。
「価値観の押し付けウザ」 ← これをそっくり熨斗でもつけてチンカスに返却しましょう。 たかだかSSLの設定が出来ない香具師が騒いでいるだけ。
SSLあり/なしの両方で運用できるように書いときゃいいだけなのに。
>>582
論点のズレた認識乙。
＞SSLあり/なしの両方で運用できるように
実際の運用に当たってはそんなの当たり前だろボケカス。
そもそも、話の流れはそういうことを言ってるんじゃないだろうが。
SSL無しの場合の被害実例を早く挙げてみろって言ってんだよ。
いつまで逃げてんだチンカス。 「SSLを使わなければ問題が起きるという実例を示せ」って、
お前の主張なんか誰も聞いてないんだよ。
早く「クレジットカード番号送るのに、SSLも使ってないサイトを使いますか」に回答しろ。
>>580ってweb製作板の「携帯端末用のWeb制作」で暴れていた馬鹿と同じやつだな。
結局GETが何かすら分かってなかったというオチで逃げ去った馬鹿。
放置推奨。 >583
結局こいつは何がいいたいの？ｗ
誰か説明して
皆さんドコモ向けのセッションってsession.use_trans_sidでやってますか？
>>584-588
悔し紛れのｼﾞｻｸｼﾞｴﾝ乙。
でもお前ｼﾞｴﾝし杉だから、ほどほどにな。
で、早くその逃げの人生を止めろよ。
答えに窮する事実を突きつけられたからって、発狂しちゃいかんよキミｗｗｗ そうして>>592は「答えられない質問」から逃げ通すことに成功した。
その後彼は一生逃げ続けるヘタレな人生を送るのであった。
めでたしめでたし。 質問への返答よりもスレ違いな場所で質問する事のが重要ってことか
死ねばいいのに
unset($_SESSION)してしまった場合の対処法おしえてくださいっ！
結構探したけどみつかんないです。。。
>>596
// unset($_SESSION)
でオケ >>597
レスありがとー。
ということは session 機能がいきなり動かなくなったのは
これが原因じゃないのね。
>unset($_SESSION)によって 全ての$_SESSIONを初期化してはいけません。 $_SESSIONスーパーグローバル変数を用いた セッション変数の登録ができなくなってしまうからです。
これの意味勘違いしてました。 そもそもネットで個人情報やカードの番号入力する時点でセキュリティが低い。
セッションやSSLに関係なく、個人情報は漏れてるし。
ベリサインも個人情報の流出までは保証してないよ。
実在証明の証明書ならね。実在証明無しの証明書も有るし。
PマークもISMSも認証に合格しましたってだけで、漏れない保証は無い。
現場では平気でシュレッダーせずに捨ててたりするし。
まぁ、SSL通っていてもマーチャントがカード情報を持つようなのは
俺はちょっと引くな。よっぽど大きな企業じゃなければ。
できれば、実績のあるカード決済代行会社を通してる所を使いたい。
で、実績のあるカード決済代行会社って具体的にどこ？
ZEROとか？
エロ系サイトでよく見かける大手ｗｗ
むろん、「手数料分を上乗せしてます」なんてわざわざ言うわけないだろバカ。
んで結局、「SSLを使わなかったばかりに問題が起きたという実例」ってあるの？
みんな結局、これをしとけば自分もﾕｰｻﾞｰも安心ってな気持ちでSSLを使用してるんかな？
>>611
ｼﾗﾈ
金貰って仕事やってると、クレジットカード決済にSSL使ってません…なんて鼻で笑われるのは事実だが。
SSLを使う一番の理由は、問題が起きる起きないという事よりも、利用者に与える安心感（サイトイメージ）を得る為。
一般人はSSLが何かなんて全く分かってない。
だけど、ベリサインがどうので高度なセキュアをかましてると謳うと、かえってSSLが何かすら
全く分かってない素人には、安心感を与える事が出来る。
SSLを使う理由なんてそんなもん。つまりあなたの仰るとおり。
個人の趣味でやるのなら好きにやればいいし、
金貰ってやるならそれに意味があるかどうかなんて考える必要性は全くない。 安心感なんて気持ち程度だけどね。
ssl対応でも個人情報ただ漏れの鯖なんていくらでもある。
やばい、yahooショッピングにセキュリティホール見つけたんだけど
ここで公開するべき？それとも電話かけておしえてあげるべき？
それともメール発射するべき？
やばい､yahooｼｮｯﾋﾟﾝｸﾞでアナルホール見つけたんだけど
ここで公開するべき?それとも電話かけておしおきしてあげるべき?
それともホールに発射するべき?
>>614
そんなの一般人にとっては分からない事だしどうでもいい。
個人の趣味でやるのなら好きにやればいいし、
金貰ってやるならそれに意味があるかどうかなんて考える必要性は全くない。
そこんとこの差が理解できない奴が多すぎ。 俺はルータにしてたLinuxマシンに、
パケットスニッファを仕込まれた経験がある。
rootkitとか仕込まれると、怪しいファイルを消してもroot権取られたままで踏み台にされるらしいね。
Ajax系画面遷移無しの非同期通信で、ポストゲットを使わずにセッションの値を変えられないだろうかぁ～？
ポストゲットすると変数いじれるし… ボタンを押したイベント時に、セッションの値を代入したいんだよなぁ。
そんなセキュリティーを求められてるんだが… 一日いろいろ試したけど、ポストゲット使う以外の方法が見つからなかった；；
エロイ人教えて；；
4.4.0でsession_regenerate_id(true)すると古いセッションIDって消してくれます？
>>625
trueで消せるのは5.1で有効になったから4系では消えない。 PerlとPHPで、sessionの共有は可能でしょうか？
Perlモジュールは CGI::Session を使おうかと思ってます。
SessionIDが同じならPerlとPHPでsessionの共有はできるものでしょうか。
「sessionの共有」する方法をご存知の方、いらっしゃいますか？
できるできないじゃなくて、
簡単なコードかいて試せば数分でわかることじゃん。
そんな時間ももったいなくて使いたくないのか？
>>628
ごもっとも。
でも
共有鯖で、Perl用のSessionが組み込まれていないので試しようがない。
モジュールの追加は申請中だけど、いつになるか判らない。
自宅鯖は、崩壊中。
判んないないら黙っててね。煽るのは止めてね。 >判んないないら黙っててね。煽るのは止めてね。
何様だ
>質問スレだ、煽る前に答えてやれ。
あれが煽りに見える時点でアレだし、この理屈はおかしい
>>627
俺はperlから離れてはや数年経つしCGI::Sessionは使った事ないが、
PHPに標準実装されてるセッション管理法はファイルベースで、
指定ディレクトリの中にセッションIDを含んだファイル名を使って管理している。
つまり、perlでもそのファイルと全く同じものを使ってセッションを実装するなら、
共有は出来る。それが出来ないなら、自前のセッション管理法にすればいい。 ログインフォームからログインしてセッションでtime()使ってタイムアウトさせるようにしたんですけど、
今のままだとログイン後に設定した時間が来たらタイムアウトされます。
何かしら操作したら情報をリセットするようなことってできますでしょうか･･･。
>>634
そうなんだけど、PHPのセッションハンドラって指定できなかったっけ？
デフォルトはファイル管理だと思うけど（サーバー設定次第）DB管理にもできるし。
DB管理にしちゃえばPerlの共有前提なら楽チンだと思った。
まぁ、いずれにしよ、モジュール任せの実装じゃ共有は難しいね。
>>636
出来るよ。
session_set_save_handler()使うのが楽。
＞まぁ、いずれにしよ、モジュール任せの実装じゃ共有は難しいね。
そういう事。
>>635
PHPのデフォのセッション使ってるなら、タイムアウトの指定が出来るから確認してみ。 php5.2でセッション使ってる人の感想聞きたいのですが、
php5.1とくらべて何か変わったところありますか？
そろそろ5.2がインデックスにでてくるころじゃね。
でもなんでベータ版ってわかりずらいところにおいてあるんだろう。
>>637
ありがとうございました。解決しました。 馬鹿がダウンロードしないようにでしょ。
バカ避け。
馬鹿は安定板を使うべき。
セッションが簡単に共有できたら、レン鯖なんてセッション取られまくりだ(w
つ他人のセッション
そもそも、セッションIDがばれたら何が怖いんですか？
どこをどうされてログインされるんですか？
こないだセッションIDというヤツを他人に知られたんですけど、
何をされるんですか？
ググって自分なりに調べたらまたきなさい。
あげんなバカ
セッションの有効期限なのですが
session_cache_expire(1440); //12時間
session_start();
セッションが必要なページ全てに書いているのですが
途中で切れています 12時間持ったことが今までないのですが、
なにか注意点はありますか？
その関数はHTTPのキャッシュコントロールで
セッションの有効期限とは関係ないと思うけど
質問者ではないけど、キャッシュコントロールと有効期限とは別物なんですか？
ちょっと気になったもので。
session_cache_expire(12*60); //12時間
にしたらよかったのに
>>646
セッションの有効期限は
session.gc_maxlifetime
session.cookie_lifetime
前者はサーバ側でのセッション保持期間、
後者はクライアント側でのセッションID保持期間。
>>647
キャッシュが有効だとサーバ側で予測できない遷移が起こってしまう。
セッション中ではその予測できない遷移によって、セッション変数に不整合が生じるなど、
悪影響がでる可能性が増大する。
そのため、セッション中におけるキャッシュの制御を、
通常のキャッシュ制御とは別にセッション関連の設計者・プログラマにゆだねる必要がある。
session_cache_expireはそのための関数であって、セッションの有効期限とは無関係。 >>652
サーバー側の設計が分からないためか、イマイチすっきりと分からない。 session_regenerate_id使うとSet-Cookieが２度送られるのな。
それのせいで、IE6のCookieがたまに誤動作を起こして、
旧SESSION_IDを送ってしまうのはバグ？
>>656
ちゃんとマニュアル読んでればわかる話。
あと10回session_regenerate_idについてマニュアルを読み返してみろ IEってサービスパックでも挙動が変わる問題ブラウザだからな。
IE7対応できてる香具師居る？
セッション中のキャッシュってメモり喰いまくって腹膨れてるから、早めに解放しないとリソース枯渇して鯖ごと落ちるだけだぞ。
他人のセッションが取れたら、他人のカードで買い物しまくれるよな(w
ミクシだと、他人の垢使いまくり(w
>>652
質問者ではないのですが教えていただけるでしょうか
ini_set("session.gc_maxlifetime", 3600);
ini_set("session.cookie_lifetime", 3600);
session_start();
でサーバ・クライアント両方のセッション保持期間が1時間になるかと思いますが、
これはセッションを使っているページすべてに書かなくてはいけないでしょうか？
現在保持時間を気にしている部分は
page1 → page2 → page3 → page4
という風に移動するものではなく、
page1 → page2 → page1 → page3 → page1
という感じで常に page1 に戻るのですが、この場合は
page1にこの指定をいれておけばいいでしょうか？
お手数だと思いますがよろしくお願いいたします
何度もすいません
セッション保持期間なのですが、値を読んだときからという認識であってますでしょうか
値を更新した時からではないですよね？
世の中、暇人や言語マニアばっかじゃないから、いちいちマニュアルなんか読んでらんないんだよ。
答える気がないんだったら、ウザイから黙ってろよ。
プログラマでマニアじゃないのは致命的と釣られてみよう
>>664
単なるマニアは致命的。プログラマーという仕事に向いてない。
しかも、プログラムする人間が職業プログラマーだけという閉塞した思考回路も致命的。
世の中には本来の目的とは別に、仕方なくプログラムを組まなきゃならん人間がいるのだ。
>>665
文盲乙！ なぜそう答えられたのか自分のレスと読み比べてみたらｗ
> 暇人や言語マニアばっかじゃないから、いちいちマニュアルなんか読んでらんないんだよ
指をくわえて答が返ってくるのを待つほど暇じゃない人のためのマニュアルだし
ソース読んで仕様を舐めまわすマニアじゃないから使い方だけ知るためにマニュアルを参照するんだよ
応用が利くという複利もあるしね。現実に>>661はこのケースだったわけだ
さて、日本語がよめてコミュニケーション能力のある奴ならなんて答えるんだろうねｗ マニュアルの該当部分をここに書けってか死ねばいいのに
答えが書いてある場所を示されただけでも良いほうだろ
ここはサポセンか？
釣り宣言していいから去れ
１．登録→２．確認（セッション保存）→３．完了（セッションからDB登録）
って流れでセッション使うのは皆どういうやり方してるの？
以降、登録画面用セッションデータをSDと、登録・確認・完了は１・２・３で記述
一．SD１件方式
１で既存SDがあればクリアする？２で上書きする？
２でSD保存
３で登録後にSD消去
つまり、登録確認画面を開いたまま、別ウインドウで登録処理を同時にやると最初の画面は正常動作しない
二．SDｎ件方式
１で何もしない
２でSD増加し保存
３で登録後にSD消去
つまり、確認画面を開かれる度にSDが増加し、完了までいかなければゴミSDが無限に増加していく
どちらも問題点があるんだが、みんなセッション使ってるみたいだし
問題点のないスマートなやり方ってあるの？
>>669
日本語が不自由な奴、乙
>>670
マニュアルの該当部分でもコピペすればいいだろ。コピペの仕方なら初心者板で聞いて来い >>671
俺はSD(ってセッションデータ？)1件方式だな。
登録画面を開いたときに、一意になるようなキーをセッションデータにセットして、
その値をhiddenで確認まで持ちまわる。
３で画面から渡されたキーと、セッション内のキーを比較して同じなら登録。
違ってたらやり直せと。
大体この程度で許されるんじゃない？甘い？
もちろん
単純にセッションIDだけで管理するなら、理論上は総当りで奪えるよ
現実的にどうだかはトリップ解析の総当りを見れば分かる
セッションIDが特定できる場合は言わなくても分かるな？
なんだ実際に試してないのか
空論で語られてもな
> 単純にセッションIDだけで管理
そりゃそうだ
物理的にネット上のIPを奪ってセッションIDを盗み見られたら終わりだね。
【セキュリティ上の注意】
php の セッションIDは、マイクロ秒単位の現在時刻 + ユーザーのリモートアドレス + combined-LCG（線形合同法自体は、疑似乱数生成方法としてはセキュアな方法ではない。） が種となっている。
セキュリティの専門家の高木浩光氏も 「phpらしい駄目っぷりだ。」 と批判している。
Unix 系 の OS ならば php.ini などで /dev/urandom を乱数の種に使うように設定しよう。
次のように記述すれば良い。
| session.entropy_file = /dev/urandom
| session.entropy_length = 32
/dev/urandom では、周囲で発生するノイズ等の攻撃者に推測されない値をデバイスドライバや他の情報源から収集して、乱数の種として使用する。
これは、特殊なハードウェアが無い普通のPCでも使えて大変便利。
HDDの回転数、CPUの温度、ハードウェアの温度、マウスの動き、HDDの寿命、ハードウェアのエラーセクタ、HDDのSMART情報、周囲のノイズによる
ハードウェア内部エラーなど、PCにはセキュアな擬似乱数としての使用に耐える攻撃者に推測されない値がいっぱいそなわっているのだ。
参考:
http://tdiary.ishinao.net/20061120.html#p01
http://www.linux.or.jp/JF/JFdocs/Secure-Programs-HOWTO/random-numbers.html
>>683
マイクロ秒単位の現在時刻 + ユーザーのリモートアドレス + combined-LCG（線形合同法自体は、疑似乱数生成方法としてはセキュアな方法ではない。） が種となっている。
↑
それで充分。
/dev/urandom を乱数の種に使うように設定しよう。
↑
自己満足の世界
良い意味でも悪い意味でも、ＰＨＰ程度のスクリプト言語に何を求めているの？
と逆に問いただしたいものだ。 >>684
> 良い意味でも悪い意味でも、ＰＨＰ程度のスクリプト言語に何を求めているの？
php程度って…、そのphpは銀行のシステムや証券会社のシステムでも使われてるよね？
まぁ大抵はaspだろうけどさ。 むしろPHPを使うのはこの程度の奴らかって思うけどな
>>684
> 良い意味でも悪い意味でも、ＰＨＰ程度のスクリプト言語に何を求めているの？
session.entropy_file という設定があるからには、
PHPはそういう利用法も想定していると推測できるでしょ？
偉そうな阿呆の書き込みを見ると疲れるな・・。 だよな
１．設定が用意されている
２．PHPはLinux以外のOSも対象にしているのでデフォルトは違う
脳みそのある人間ならこう考えるのが普通だと思う俺の視点では
＞＞＞「phpらしい駄目っぷりだ。」
こいつ痛すぎるだろｗ
で、設定変更すればよりセキュアな環境を提供できるにも関わらず
自己満足などと言い切るのは、とてもプロだとは思えないな
> ２．PHPはLinux以外のOSも対象にしているのでデフォルトは違う
そういや、Windows はセキュアな擬似乱数発生器持ってないのかなー
Unix の /dev/urandom みたいなやつ
乱数発生は本来プログラミング言語レベルじゃなくて、OSがやるべき話
ハードウェアのノイズを取得するのはOSがやるのが一番効率いいし
ちなみに、乱数の安全性ってのは馬鹿にできない話だよ
「ハッカーズ その侵入の手口 奴らは常識の斜め上を行く」 にもあるように、
それでラスベガスのカジノでぼろもうけしたやつもいるしさ、オンラインゲーム(MMO)なんかでも
時間種乱数のせいでクラックされてゲームバランス崩れた例もある
>>689
> で、設定変更すればよりセキュアな環境を提供できるにも関わらず
> 自己満足などと言い切るのは、とてもプロだとは思えないな
激しく同意 いや、自己満足だろ。
クライアントから見て理解できない部分へのこだわりっていうのは、所詮は自己満足。
自己満足と分かった上でやるかやらないかだけだ。
つか、素人のくせにプロ面して語るのが激しくウザい。
俺はsmartyで挫折してcakephpでも挫折した男だけど、プロ意識は持ってます。
そろそろ、セッション＝PHPじゃないって気が付こうぜ。
つーか、単発スレ使ってるなよ。
携帯でセッション持たせようとするときって、どうやってる？
>>697
携帯から取得できる一意キーを元に、アプリ側でセッションを作成してる。 >>698
レスありがとうございます。
それはPOSTの時にしか使えないと思いますが、GETでも必要な場合にはどうしていますか？ >>699
キャリアによるわ。
au だと EZ番号 (サブスクライバID) を常に送信するのがデフォルトだし。
個体識別番号を常に送信するのはプライバシー上問題あるが、セッションCookieにすら対応していない
糞キャリアドキュモの場合には、URIにセッションIDいれるというセッション固定攻撃の被害を受ける可能性のある
脆弱な実装しかできない。
>>700
レスありがとうございます。
なるほど。ある程度覚悟してましたが、やっぱり面倒臭そうですね。 そもそもプロならphpなんて使ってないだろ。
やっつけ仕事向けのVB感覚が売りなのに、しっかり業務としてインターネットに公開している企業は痛い。
金無いのかよと(w
あと、/dev/urandumは本当に乱数かどうか検証したのか？
疑似乱数って実装は、ありがちだぞ。リナックスは変に妥協してたりするし。
で、クッキー無しでセッションを安全に使う方法ってあるの？
クッキーなんて偽造できるし、セッションIDぐらい総当たりで突破できるし。
セッションに何を求めてんの？
安全にしたいならSSL＋ワンタイムパスででも武装しろよ
>>702
俺、そのPHPで今年は年収2000万超えたけどねｗ
金あるところにはあるもんだ。いくらでも需要ある。 >>702みたいな変なプライド持ってる開発者に限って、
ものを作らせるとインターフェースが糞で使い物にならない事が多いｗ >>702
> あと、/dev/urandumは本当に乱数かどうか検証したのか？
> 疑似乱数って実装は、ありがちだぞ。リナックスは変に妥協してたりするし。
コード見ればわかるだろ
複数のハードウェアのノイズをもとに生産している乱数であって線形合同法とか時刻などは一切使ってない
全てのWEBアプリをCで書く人が居ると聞いて飛んできました
おまいらのOSってphpで動いてるのか？
２０００万のサイトってどこだよ。
個人情報対策できてるかどうかチェックしてやるよ。
ハードウェアのノイズって割と周期的だが。
>>702
>そもそもプロならphpなんて使ってないだろ。
・・・ 今日の迷言
おまいらのOSってphpで動いてるのか？
さて、次はどんな事書いて笑わせてくれるのでしょうか。この人は
>>709
＞２０００万のサイトってどこだよ。
質問の意味が分からんしｗ
俺は個人で小さな会社経営してて、小回りの効く分色んな仕事をとってこれるってだけだよ。
会社経営者なら分かると思うが、この仕事は経費作るの大変でさ、売り上げのほとんどが利益になってしまうから、
自分や従業員の給料を歩合制にしてるんだよ。
このスレにはSOHOやってるやつとかも多いんじゃね？手挙げてみ。 俺の経験上、>>702みたいな奴に限って、仕事任せると全然使いものにならないんだよなｗ >702
>あと、/dev/urandumは本当に乱数かどうか検証したのか？
「本当に乱数か」
「本当に乱数か」
「本当に乱数か」
「本当に乱数か」
「本当に乱数か」
「本当に乱数か」
「本当に乱数か」
あまりにも酷い無知加減ですね
>>702には乱数の定義から教えないと駄目って事だな > あと、/dev/urandumは本当に乱数かどうか検証したのか？
> 疑似乱数って実装は、ありがちだぞ。リナックスは変に妥協してたりするし。
何度見ても笑えるｗ
/dev/urandun はセキュアな擬似乱数生成器だ。
擬似乱数じゃない乱数なんてPCで生成するのは不可能だから
もし、生成できるソフトがあるんだったら教えてくれ
絶対ないけどな
疑似乱数でなければ、セッションの意味ないだろ。乱数じゃないし。
総当たりされたら終わりだ
phpで稼いでるのってウェブデザだろ？ プロじゃないし。
どうでもいいけど>>702はVBの業務アプリケーションの多さを知らないのか？
C/S廃れてからは流石にあんまし見ないけどさ。
ちなみに今業務で使ってるのもPHPです。お手軽さが売りです。
本当にどうもありがとうございました。 VB.NETなんてインターネットに公開してたらすぐやられるけどな(w
phpサイトも個人情報漏れまくりだ。セッションも乗っ取り放題。
VB.NETの話と違うんじゃない
バック側の管理でVB使ってるところは沢山見たことあるぞ
非.NET時代のASPでも言語はVBが使われてたりしたけどな
言語が何であろうが、それで金稼げば一応はプロ。
年収１０００万以下の奴はカスだが。
どんなに素晴らしい能力があっても、ウンチクたれるだけで金稼げ無い奴は素人。
プログラムやHTML書けるけど、人と話せない引きこもりって居るよな。
買い叩かれて氏ねば良い。
>>728
そういうことはまずは就職してからな。
みんなニートの妄想に付き合う程暇じゃないと思うよ あの、お忙しいところ、質問があります。
インターネットオプションで、クッキーの設定を行っているのですが、
クッキーが巧いこと、保存されません。
具体的には、プライバシー設定の詳細で
「自動Cookie処理を上書きする」のチェックをon,off両方を試し、
onの場合、どちらも受け入れるを選択、常にセッションCookieを許可するのon,offの
全てのパターンで試しました。
しかし、Cookieが保存されませんでした。
こういうことってあるのでしょうか？解決方法を教えていただける方いませんか？
serversideでちゃんとクッキーが発行されているのか？
別のクライアントブラウザからは、クッキーの発行が確認できました。
ブラウザのセキュリティーﾚﾍﾞﾙの設定等で受け入れられない状態とか
世の中にはクッキー非対応の環境も有るし。
ひたいおうでもうごくようにしとけ。
session.gc_maxlifetimeってデフォルトが24分(1440秒)なのは、実装した人の勘違い？
ちゃんと意味があるの？
というのは、session.cache_expireが180分(3時間)になってても、実際は24分で切れちゃうでしょ？
この辺を論理的に説明できる偉い人の登場を期待ｱｹﾞ
ごめん、sageた・・・
ついでに、このガーベージコレクションだけど、
/htdocs/を1440秒
/htdocs/admin/を3600秒に.htaccessなんかで変更した場合、（set_iniでもいいけど）
変更したディレクトリはちゃんと時間が反映されるんでしょうか？
（自分で試せば分かるだろって？そうですね・・・試してみます）
>>741の補足です。
なんで1440秒が勘違いかと思ったかというと、session.cache_expireが分指定だから、
session.gc_maxlifetimeも分指定の値になっているのかと。
つまり、GCは24時間毎に行う指定になっている？
でも、24時間って長すぎるよなぁ・・・
（つうか、この場合のGCってデフラグと同意だろうから、24時間サイクルじゃ頻繁すぎるのかなぁ？） >>741
まず、じぶんの環境ぐらいかけ。
話はそれからだ。 疲れてる？
憑かれてる？
突かれてる？
吐かれてる？
>>746
「キャッシュ」がなんなのか理解してるか？
理解してるなら>652で十分な回答になるはずなんだが。
>>744
自分のレスを参照されてうれしかった。ありがとう。 >>750
君はその知識で実際に運用して、推測通りにセッションを
コントロールできてるか？伺いたいものだ。
例えば、セッション24時間にしょうとして、実現できているか？
できていないはずだ。自分で推測することは科学といわない
普遍的な（と思われる）手段で反証して確かめることが「科学的」なんだよ。
それと、デフォルトのmaxlifetimeが1440秒ということについての
ご意見をお伺いしたいのだが？ ×演繹を行うのは甚だ筋違いだ。
○演繹や帰納に基づく実験を～
質問です
session_regenerate_id() でID再生成を行うと、
セッションの有効期限(gc_maxlifetime, cookie_lifetime)のカウントは
リセットされるんですか？
マニュアル嫁、簡易なスクリプト書いて検証しろで片付くような質問は、なぜか延々繰り返される不思議
php内で
GCが走ったか（走るか）否かを検出する方法ってある？
あとGCが走った時ってレスポンスに差あるの？
大量のファイルを削除するのはそれなりに負荷があると思うんだけど
>>758
無い。
GC自体を自前で実装することはできるから、
それでどうにかすることはできる。 なんかPHPのセッションて糞すぎねーか？
パーセントでgcの割合指定するのも
アクセス数に左右されるおかしな仕様だし
微妙に挙動が良くわからんし。
PHP氏ね
>>760
文句あるなら使わなきゃいい。
技術力あるならextension作ればいい。 >>760
そういう人の為に、自前のセッション処理を簡単に組み込める関数まで用意されてるのにｗ セッション使うより
会員制サイトならユニークIDにしたほうが効率よくない？
セッションだと
セッション→ID&PASS→DBより一致するデータを取得
ユニークIDだと
ユニークID→一致するデータを取得
GETにでも入れておけばいいんじゃね？
すみません。根本的な質問なのですがセッションを使うのにライブラリーが
いりますか？ＰＨＰ５．２．２なのですがsession_start()を入れるだけで
ＰＨＰが動かなくなります。//でコメント扱いすると動作します。
ちなみにsession_start()のスペルミスなどではございません。
>>765
何かしらの出力の前にsession_start()してみろ <?php
session_start();
としています。error_reportingが非表示？になってますので画面が白く
なるだけでエラーの内容はかえってきません。
サクラの専用サーバー借りたのですが初期設定でＧＤも使えないので
そういうのがセッションにもあるのか？と思いましてここで聞いています。
エラーログ見るかdisplay_errors設定すればいいじゃん。
それかphp -iかphpinfoでsessionの項目見てみたら？
何で専用サーバなんて借りたんだ。
レンタルでやっていたのですが負荷が高くて
専用じゃないとやれなくなりました
セッションハイジャックってどういう時に起こりうるの？
>>771
1.セッション付きのURLから外部のサイトに飛びました
2.外部サイトの鯖ログ（もしくはアクセス解析）に、セッション付きのURLが残りました。
3.その外部サイトの管理者がURLにアクセスしました
セッション管理法が糞なら、こんな事でハイジャックされてしまう事もあるわな。
非常に低レベルなお話だが 2.外部サイトの鯖ログ（もしくはアクセス解析）に、セッション付きのURLが残りました。
↑これは、リファラとしてって事な。
>>771
実装次第だけど、セッションIDがどこに保存されているかは大体目星が付くよね？
それをどうにかして奪おうと頑張る人がいるんだよ。 >>773
それってURLがPHPSESSIDってなっているサイトだよね？
たまに大手サイトであるけど、ほとんどセッションはクッキーで保存
するタイプじゃないの？ ブラウザ側でクッキーが無効だったらURLに付加するしかねーだろ
恥を知れ
いや、それはわかってるよ。携帯サイトとかもだろ？
けど、上記に出てるようにセキュリティ的なリスクが高いじゃないか。
PCサイトではCookie必須とし、session.use_trans_sidはOFFにする。
携帯サイトの場合は、最低限session_nameはデフォルト以外を使う(EZwebを除く)。
ってことでOK?
アマゾンのあれもセッションじゃん
セキュリティもへったくれもないような
>>778
だから、セッションIDが漏れても大丈夫なように対策をするわけだ。
非常に低レベルな対策としてはIPアドレスを使う方法だが、
これは例えばDoCoMo携帯みたいに接続ごとにIP変わる場合には使えねぇな。
DoCoMoはリファラ吐かないが、auなんかリファラ吐くから簡単にセッションIDは漏れる。
だから、例えばauの個体識別番号なんかを使って、万が一セッションIDが漏れても
大丈夫なように対策をするわけだろ？
でも個体識別番号の通知をオフにする設定も出来るわけで、そこら辺どう対策していくかとかさ。
それ以前に、最近のau機種の大半ははクッキー対応してるけどｗ
俺の管理しているサイトの鯖ログには、
mixiのセッションIDがくっついたリファラや、
YahooメールのセッションIDがくっついたリファラがたくさん残ってるが、
だからといってそのURLにアクセスｂｵても無駄だわｂﾈ。当たり前。 >>781
mixiはたぶん、毎ログインごとにセッションIDをDBに保存していると思う。
だから、1人のユーザがログインしている時だけ有効なセッションIDを
利用するから、二度と同じセッションIDは使えないわけで、
それがセキュリティ対策になっているのだと思う。
と言ってもOpenPNEのソースをみた印象なので、正しいかどうかはわからないが。 すみません質問です！
localhost/test/sessiontest/index.php ←ここでsession_start()してprint session_id(); print session_name();
localhost/test/index.php ←ここでsession_start()してprint session_id(); print session_name();
すると両方とも名前はPHPSESSIDなんですがIDが違ってて、sessiontest/index.phpでセットした値が上の階層で使えません。
下階層でセットしたセッション情報って上の階層で拾うにはどうすればいいのでしょうか。
session_set_cookie_params
セッション管理のヘルパとかライブラリってありますか。
軽量な奴で。
いや、つうかさ、
＞セッション管理のヘルパとかライブラリ
とかって、何に対してして欲しいのさ？
Perlやってた俺としては、PHPは十分便利だと思うけど？
クッキーは1024byteまでしか使えないんじゃなかった？
4096bytes/cookieで特定のホストかドメイン毎に20cookieまで。
さらに携帯では制限付くよ。
というかDoCoMoがいつまでもCokkie非対応で
そろそろ機能が付くという話も聞いた気がしたがサイトに情報なかったな。
最近、セッションが勝手に切れるんだけど、
同じ現象を経験した人いる？
>>798
俺が作ったショッピングサイト。
ショッピングカートの中身が消えるという現象が起きてる。
タイミングは不明。
商品を10、20個入れても消えない時もあるし、3個で消えた事もある。
セッションが破棄されるタイミングがさっぱりわからないんだ。 hpのセッション管理について、動作が不明な点があります。
（現象）
1. ログイン実行、ログイン成功ならばクッキー変数にセッションIDを設定します。
2. しばらくログインしたままで画面を開いていました。
ガベージコレクションが実行されてプログラム内で設定したセッション変数が削除
されました。
3. ログアウトの処理を実行せず、画面を閉じて終了しました。
明示的にsesson_destroy()は実行していません。
4. 再度ログインしました。その後設定されているセッション変数を確認したところ、
上記1.で設定していたセッションIDと同じ値が設定されました。
2.でガベージコレクションが実行されてセッション変数が
削除されたはずなのに、再度ログインすると同じ以前と同じセッションIDとなる
理由がわかりません。
セッションIDはガベージコレクション実行後でも削除されないのでしょうか。
PHPでセッションIDが変更されるのはどのようなタイミングなのでしょうか。
もしかすると私のphpのセッションの仕様理解不足な点があるかもしれません。
わかる方がおりましたら教えてください。
すみません、1行目入力ミスしました
× hpのセッション管理について、動作が不明な点があります。
○ phpのセッション管理について、動作が不明な点があります。
>803
>ガベージコレクションが実行されてプログラム内で設定したセッション変数が削除されました。
何かでちゃんと確認した？ガベージコレクションがセッションを軒並み
削除してしまうなんてことはないはずだけど
質問なんだけどａｕサイトでのセッション管理はＵＲＬにセッションＩＤ埋め込む方法でＯＫ？
docomoとｿﾌﾄﾊﾞﾝｸは上手くセッション管理できてるけどａｕだけ何故か上手くいかなくて。。
>>803
セッション固定脆弱性と同じ原因でしょ。
この場合はセッションIDが悪意を持つだれかが用意したものではなくて、
クッキーや履歴の一部(クエリ文字列でセッションＩＤを引き回した場合)に古いセッションＩＤが残っていて、それが利用されたと考えられる。
この動作には害はないけどセッション固定攻撃されると危険なので対策を施した方がいい。
>>806
auはクッキー使える PHPに限ったことではないんですが、タブブラウザとかで1つのwebアプリに
ログインした状態でもう一つタブを作ると、同一セッションになってしまいますよね。
これを回避するブラウザ、もしくは対策はないでしょうか。
（全てのページのURLにセッション名を埋め込むとかは面倒なのでしたくないです）
セッションの仕組みを考えれば分かる事だろう？勉強不足。
あーはいはい。余程悔しかったんだね。
そんな書き込みしてる暇あったら少しはお勉強しなよ僕＾＾
まずは、日本語のね(笑)
windowsで開発するときのセッションファイルってどこにあるん？
XPだと
C:\WINDOWS\Temp
ほかの環境は試したことないからわからん
//$_SESSION['abc']; は前ページで123を代入
//ここから
$_SESSION = array();
if (isset($_COOKIE[session_name()])) {
setcookie(session_name(), '', time() - 42000, '/');
}
session_destroy();
echo $_SESSION['abc'];//123
と表示したいのですが何か方法はないのでしょうか？クッキーとか使わずに。
要するにセッションを破棄した後で、そのセッションに入っていた変数を参照したい、ということなら、
$_SESSION = array();
の直前に
$temp = $_SESSION;
とかしておいて、最後の
echo $_SESSION['abc'];
の代わりに
echo $temp['abc'];
とかすればよいのでは？
はずしてたらｽﾏｿ
質問です。mixiってＳＳＬじゃないけど大丈夫なんですか？
これが、楽天やアマゾンだと
普通の商品ページ→http
しかし、購入後の清算ページ OR 会員登録 OR 会員登録変更などは
全部httpsです。
これって、とりあえずセッションＩＤを変えてるってことですよね
mixiなんてプレミアムの申し込み以外は個人情報入力するわけでもないのにSSL化する意味あるのか
２ちゃんで名前欄にコテハン入力するのと同じレベルだぞ
PHP.iniのsession.save_handler に、独自のセッションハンドラを定義する
方法はあるのでしょうか？
セッション変数をDBに格納したいので独自にハンドラを書きたいのですが、
事情によりスクリプト内でsession_set_save_handler関数は使えないんです。
>>822
独自のセッションハンドラを、標準的なセッション（ファイルベース）と挙動が変わらないように実装するのは意外に面倒。
セッション変数をDBに格納したい理由が分からんが、session_start()を呼んでいる前後でsession_id()をDBに登録するのでは駄目かな？ 問い合わせフォームのページ遷移で、自分のページから来たことを確かめるためにセッションを使っています。
input type="hidden" name="token"
他人のブログ等見ると、
■session_idを使う方法
$token = hash('sha256', session_id());
↓
if ($_POST['token'] != hash('sha256', session_id())) {
■$_SESSIONと照合する方法
$_SESSION['token'] = rtrim(base64_encode(openssl_random_pseudo_bytes(32)),"=");
↓
if ($_SESSION['token'] != $_POST['token']) {
と２種類（他にも？）見られますがどちらがいいのでしょうか？
htmlspecialcharsはここでは省略しています。
>>824
session_idを使う方法は新たなセッション変数が不要なので最も簡便だが、
フォームとcookieを比較されたらすぐにバレるので、
バリデーションを保証する要素としては使わない方が良い。
$_SESSION['token']を作る場合は、いつどこで作るのか、
それが既に定義されていた場合のフローなどを考える必要がある。
よって、ページ遷移元を保証するだけならsession_idでも構わないが、
バリデーションを保証する目的で$_SESSION['token']を作る価値はある。 >>825
詳しくありがとうございます。
それぞれ単独で説明する記事は見られるのですが比較する記事が見つからなくて迷ってました。
助かりました。 >>826
セキュリティに対する意識は単価の高い案件に携わるには必須だよ。
ガンバレ！ 誰でも簡単にネットで稼げる方法など
参考までに、
⇒ 『半藤のブブイウイウレレ』 というサイトで見ることができます。
グーグル検索⇒『半藤のブブイウイウレレ』
FBZK1A4NUV
プログラミングを誰でも習得できる方法は、「前場アキドルのプログラミングマスター方法」というブログで見られるらしいよ。ネットで調べると見られるらしいです。
5TNTB
ブックマークへ