5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :nobodyさん:03/09/24 19:31 ID:SnRvXmpI
ブラウザを閉じたらセッションの効果がなくなるのって、
ブラウザを閉じることでクッキーを消しているからなのですね。。
知らなかったよーーーーうわーーーん

2 :nobodyさん:03/09/24 19:32 ID:SnRvXmpI
いちいちセッションの機能使わなくてもよく考えたら、
IPをキーにして
普通につくれるじゃん。。
と思ったんんだけどどうう?

3 :nobodyさん:03/09/24 20:24 ID:???

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

4 :nobodyさん:03/09/24 22:39 ID:???
早くPHP5出ないかなぁ・・・。

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


6 :sage:03/09/24 23:20 ID:???
>>5
それって何か問題ある?

7 :nobodyさん:03/09/24 23:48 ID:???
完全ではない、という問題。

8 :sage:03/09/25 00:23 ID:???
IPが変わる可能性がある、ということだよね。
変わらなければ問題はない。
けれども変わるから完全ではない。

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

9 :nobodyさん:03/09/25 00:41 ID:ZJmN+3d3
あげ

10 :nobodyさん:03/09/25 00:57 ID:???
セッションだけで1000まで逝くか?

11 :sage:03/09/25 02:07 ID:???
実際、、どうやったら、セッションの代わりになるんですか?
誰かおしえてちょんまげ

12 :nobodyさん:03/09/25 10:43 ID:???
IPが変わるとか、ブラウザの起動中だけとか言ってるけど
問題はその逆。
同じアドレスで複数の人がアクセスする可能性
同じクライアントで別人がアクセスする可能性

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

13 :sage:03/09/25 17:47 ID:???
っていうかIPをキーにするんじゃなくて、クッキーをキーにしたら、
セッションと同じ機能をまるごとつくれるんじゃないか?


14 :sage:03/09/25 17:49 ID:???
>>12
同じクライアントで別人がアクセスする可能性

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

15 :nobodyさん:03/09/25 18:38 ID:???
なんだこのレベルの低さは

16 :nobodyさん:03/09/25 19:19 ID:???
>>14
いやだから、ログアウトやブラウザ閉じたら無効にする機能が必要

17 :sage:03/09/25 19:28 ID:???
>>16
クッキーの有効期限を0にしたら同じじゃないの?

18 :nobodyさん:03/09/25 19:43 ID:T3dpzMyk
イイヨーイイヨーあげ

19 :nobodyさん:03/09/25 21:11 ID:???
今どきクッキーでセッション管理してモナー

20 :nobodyさん:03/09/25 22:05 ID:???
>>8
アホか。

21 :nobodyさん:03/09/26 00:02 ID:???
オマエラなぁー、せめて↓くらいひととおり見ろよ、とりあえず。

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

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

22 :nobodyさん:03/09/27 07:48 ID:efY9iLPN
「ブラウザの戻るボタンで戻ってリロード→2重処理」
の回避策にsession使ってるけど邪道?

23 :nobodyさん:03/09/27 10:39 ID:???
>>22
素直にDBの主キーと比較するとかもあると思うけど、それほど邪道でもないかと。
複数ページでのつながりを確保するのが目的だからな。

24 :nobodyさん:03/09/27 20:12 ID:76PBBTl7
>>22
sessionでチェックという以前に、
遷移先画面にリダイレクトさせて、戻れなくするのが基本じゃないのかなぁ??



25 :直リン:03/09/27 20:13 ID:fK1fC/Fc
http://www.leverage.jp/bloom/qry/search.qry?function=first

26 :nobodyさん:03/09/27 20:30 ID:???
>>24
エラーが出たとき入力内容が一切合切消えるのは非常に迷惑。


27 :nobodyさん:03/09/28 22:13 ID:???
>>26
言ってる意味がよくわからん
それって、クライアント側のバッファ利用の問題で、二重投稿処理とは関係ない




28 :nobodyさん:03/09/28 22:40 ID:???
戻れなくして不便を強いられるより、そういう配慮をしてくれる
ところのほうが好感が持てますね

29 :nobodyさん:03/09/30 15:43 ID:2jXpVkA5
age

30 :nobodyさん:03/10/01 12:48 ID:???
php

31 :nobodyさん:03/10/01 18:29 ID:MgXABHqI
sesson

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

33 :nobodyさん:03/10/01 19:14 ID:???
危険が無いわけじゃないが、あちこちで使われている手法だし
対策はされている。

34 :nobodyさん:03/10/02 04:12 ID:jb4S4+xE
session_startってやらないと、$_SESSって呼び出せないの?

35 :nobodyさん:03/10/04 01:01 ID:8tSg2rjL
>>34
php.ini

36 :nobodyさん:03/10/04 07:34 ID:???
レベルの低さからしてネタスレか?

37 :nobodyさん:03/10/05 22:20 ID:???
>>36

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

38 :age:03/10/11 00:19 ID:???
>>22,26,28,33
などは、典型だが、良い子は、まねしないでね。晒し上げ。

39 :nobodyさん:03/10/11 00:23 ID:???
根拠を書かない>>38を晒しあげ

40 :nobodyさん:03/10/11 00:39 ID:???
phpマニュアルのセッション関数(セキュリティ部分)を抜粋してみたYO。

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

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

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

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

41 :nobodyさん:03/10/11 08:32 ID:???
>>40
で?
そんな分かりきった事をのっけて何が言いたいの??

42 :nobodyさん:03/10/11 10:46 ID:f+KUGOmH
>>41
初心者には分かりきったことではないんでしょう。
なぜつっかかるのかわからん。

43 :nobodyさん:03/10/11 21:38 ID:???
>>42何が言いたいかわからん、ということを言いたいのじゃないのか?>>41

44 :参考:03/10/12 02:38 ID:hB6ZK8LU
貧弱なセッション管理について
ttp://www.atmarkit.co.jp/fsecurity/rensai/webhole03/webhole01.html

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


45 :nobodyさん:03/10/12 02:43 ID:hB6ZK8LU
>>39
キャッシュを public にすると、そのままブラウザ閉じても、そのURLを開けばまた
情報が出てくるからじゃないの?


46 :nobodyさん:03/10/12 02:47 ID:???
キャッシュの話と>>28は関係ない
>>28は戻るボタンを用意して、内容を復元する配慮をしてくれと
言ってるので、ブラウザの戻るでのキャッシュを使えとは言ってない

47 :nobodyさん:03/10/12 02:51 ID:???
>>33もあれだな。
クラックの危険があるから通常は対策していると言ってるので
指摘される理由がわからんな

48 :nobodyさん:03/10/12 03:08 ID:mzy4uQ15
セッションが使えるケータイってありますか?
ちなみに、J-PHONE J-SH05ではダメみたいです。

49 :nobodyさん:03/10/12 03:14 ID:hB6ZK8LU
>>48
セッションの仕組み一度自分で作ってみたらどう?と思ったよ

50 :nobodyさん:03/10/14 21:07 ID:/RUyf6Fs
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です。

51 :nobodyさん:03/10/14 21:11 ID:/RUyf6Fs
訂正:session_switchingの2行目

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

52 :nobodyさん:03/11/13 18:52 ID:???
生きてるか?w

53 :nobodyさん:03/11/19 18:30 ID:???
ハイ

54 :nobodyさん:04/01/08 05:26 ID:K/SrUI+S
アゲ

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

邪 道 か な ?

55 :nobodyさん:04/01/09 19:32 ID:???
良いんでない? 俺もそうするときがあるよ。

56 :ななしくん:04/01/27 22:58 ID:vdgC7W+O
セッション使ったプログラムかいてたんだけどさ、
使い方があまりにも簡単すぎて($_SESSIONとクッキー使った場合)
こっちは身構えてるので、逆に解説とかがわかりにくかった(藁

57 :nobodyさん:04/01/28 03:07 ID:IiAYAwD1
>>56
確かにセッション使うのは楽だけど、
動作原理はしっかり理解する必要があるよ。


58 :ななしくん:04/01/28 06:10 ID:???
>>57
様々な解説書サイトなどはそういう意図で、原理を説明されてるんだとは思います。
なんか、「どう使うか!!!」がなかなかわからなかったんですよ(藁

59 :nobodyさん:04/01/28 08:42 ID:???
オイラも初めてセッションを使い始めた時は、>>58と同じような感じだったなぁ。

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

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

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

61 :nobodyさん:04/02/01 18:12 ID:LMIdhuo4
>>54
どうやってクライアントを認識しているのか教えてほしいage

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

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

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


63 :nobodyさん:04/02/12 16:36 ID:???
>>62
いいんじゃない?
URLにセッションIDとか渡すのって普通だと思う。

64 :nobodyさん:04/02/14 08:52 ID:???
俺はPHPじゃなくてJSPだが、静的ページも全部JSPだよ(商用)。
PHPでも同じようなことしてるひといるでしょう。

65 :nobodyさん:04/02/14 17:19 ID:X1Wwd0H+
$_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

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


67 :nobodyさん:04/02/17 21:52 ID:???
できるけどGETでのセッション管理なんで認証とかにはつかっちゃ駄目

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

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

69 :nobodyさん:04/02/19 21:15 ID:???
>>68cookieなしで amazon 使えるの?

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

71 :nobodyさん:04/03/04 23:25 ID:???
session_startした後にPOSTしたページに
戻るボタンで戻ったら有効期限切れってなるのは
どう言う解決法があるのですか?

72 :nobodyさん:04/03/07 22:46 ID:Nzwf/rJi
ホシュホシュ

73 :nobodyさん:04/03/09 22:32 ID:???
おそレスですけど、
昔から、通販業者系はサーバサイドのセッション管理が標準だね。


74 :nobodyさん:04/03/18 02:35 ID:5cjOT2D0
セッションですか?!
私にお任せあれ!!!!!



75 :nobodyさん:04/03/18 05:54 ID:zQ2yHGPu
>>71
session.cookie_lifetime integer

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

76 :nobodyさん:04/03/18 09:33 ID:SVbaZ9qT
ブラウザを閉じても1時間は有効であるように、
ini_set( 'session.cookie_lifetime' ,’3600’ );と記述しました。
書き方がおかしいでしょうか?
この書き方では、設定変更は出来ないようです。

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

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


77 :nobodyさん:04/03/18 10:37 ID:???
>>76
こっちのスレの方が相応しいけど、マルチポストいくないっ

78 :nobodyさん:04/03/18 10:53 ID:SVbaZ9qT
>>77
一言添えればよかったですね。
ちょっとこちらで質問させてください。

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

80 :nobodyさん:04/03/18 14:49 ID:SVbaZ9qT
ini_set( 'session.cookie_lifetime' ,’3600’ );と
記述して、セッションIDが追加されなくはなります。

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



81 :nobodyさん:04/03/19 15:09 ID:???
鯖を数日動かしてると、
セッションが不安定にならない?
漏れの鯖は三日くらいでセッションがプチプチ切れるようになる。
apacheを再起動すると治るけど、
コレってPHPの設定がおかしいからかな?


82 :nobodyさん:04/03/19 17:48 ID:???
>>81
PHP のバージョンと OS は何?
Linux で PHP 4.2.x を使っていた頃に同じ状態で苦労したことがあるけど。

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

83 :nobodyさん:04/03/19 22:04 ID:???
>>82
child pid ***** exit signal Segmentation Fault

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

84 :82:04/03/20 00:30 ID:???
>>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 が出そうだけど。

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

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

86 :84:04/03/20 10:55 ID:???
>>85
PHP 4.2.x の頃に、パフォーマンス的に有利ということだったので、

session.save_handler = mm

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

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

87 :nobodyさん:04/03/20 12:40 ID:???
いまfiles指定して動かしてみたところ、
特に処理速度にも問題ないし、とりあえず大丈夫
まあ今後>>81の症状がでるかどうかまだ分かりませんが・・・

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

88 :87:04/03/20 13:11 ID:???
自分で書いてて思ったんですが、
apacheがちょくちょく落ちるのってかなりやばいよなあ(汗)
OSのレベルからアップグレードを考えるいい機会かもしれない

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

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

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

90 :nobodyさん:04/03/20 15:55 ID:???
>>86
mm ってなんですか?
当方セッション情報を MySQL に入れるハンドら作って動かそうとしているのですが、
既存のがあるんなら使っちゃおっかな〜

91 :nobodyさん:04/03/20 16:33 ID:???
>>90
maji mukatsuku

92 :86:04/03/20 20:56 ID:???
>>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 を起動。

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

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

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

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

94 :nobodyさん:04/04/02 20:40 ID:???

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

なんででしょうか?


95 :nobodyさん:04/04/02 20:46 ID:???
>>94
すんません!いきなり判明しました・・・
1行目を空白にしていたのが原因でした。

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

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

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


96 :nobodyさん:04/04/04 21:49 ID:zccZUASs
IE6でクッキー機能をOFFにしているのにセッションが使えてしまう。
PHPのSIDもOFFにしているのに・・・
なぜ?

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

97 :nobodyさん:04/04/04 22:30 ID:???
>>96
見逃してるだけだよ。
セッションが使えているなら、cookieかURIパラメータの中に必ず埋め込まれている。

98 :nobodyさん:04/04/04 23:29 ID:???
>>96
勘違いしてるだけだな。

99 :nobodyさん:04/04/04 23:53 ID:???
>>96
コンテンツの中に埋め込む場合もあるけどね。

100 :90:04/04/05 01:55 ID:???
セッションが使えていると勘違いしているに200$$

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

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

102 :nobodyさん:04/04/05 23:45 ID:???
テストに使用してるブラウザは?
IEでプライバシーポリシーうんにゃらで2chからのクッキー食べてくれないとか・・

103 :nobodyさん:04/04/05 23:55 ID:???
Localだから

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

105 :96:04/04/05 23:58 ID:EigS3bMU
>>103
www

106 :nobodyさん:04/04/06 00:01 ID:lpi6f7xm
今やったらセッション使えなかったよ
なんやねんな

107 :nobodyさん:04/04/06 00:34 ID:???
>>104
IEだけで動作チェックするのは間違い。

108 :nobodyさん:04/04/06 02:28 ID:???
IEだけでしか使わない社内用とかならあり
んでも、Mozilla使った方が開発はしやすいぽ

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

110 :107:04/04/08 00:30 ID:???
そうだね〜
XMLはIEの方が良い!
Mozillaのデバックコンソールってもう一声どうにかならんかなぁ
あとあと、CSSで幅の定義を1どっとずれて描画するのもどーにかならんかなぁ
はうっ!セッション関係無いし

111 :108:04/04/08 00:31 ID:???
>>110 ごめん名前間違えたw

112 :nobodyさん:04/04/14 12:42 ID:???

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








 ようやく気が付いた。


113 :nobodyさん:04/04/14 14:05 ID:vcn3L4Wo
>>112
セッションなんて言うからよく分からないんだよな。

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


114 :教えてください・・・:04/05/16 22:13 ID:dL8RQ1Kh
以下の環境を構築しています。
<環境>
サーバA:192.168.11.1 WinXP-Apache1.3.29+PHP4.3.4 
サーバB:192.168.11.2 同上

やりたいことは、
@サーバAのLOGIN.PHPでログイン(=>LOGINFLG=ONを$_SESSIONに設定する)
AサーバBのxxxx.php($_SESSION[LOGINFLG」を見る)にアクセスする
 ->xxxx.phpが、$_SESSION[LOGINFLG」=ONを見て、PHPの参照許可を出す

という、セッション情報をサーバ間で持ち回るということをしたいんです。

条件として、
・セッションクッキーを使わない。
・Windows上(=mmが使えない)ということで、session.save_handler = filesを使う。
という状況なんですが、どうやれば、セッション情報の共有はできるんでしょうか・・

お教えください。。。



115 :nobodyさん:04/05/16 22:43 ID:???
>114
セッションという機能がどういう風に実現されてるか、
またはどういう風にすれば実現出来るか考えてみれ

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


116 :nobodyさん:04/05/17 18:19 ID:???
>114
DBは使わないの?
方法によっては簡単に出来るのに。

117 :nobodyさん:04/05/17 23:43 ID:???
session.save_pathを指定しておいて、fsockopenするとか?

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


118 :nobodyさん:04/05/19 00:08 ID:???
つーかJavaみたいにphp5ではクラスにセッション情報を保持できるようになるんでしょうか?

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

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

120 :nobodyさん:04/05/21 14:11 ID:???
>>119
セッションはサーバーサイドでデータを保持するのが最大の特徴

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


121 :nobodyさん:04/05/21 23:41 ID:???
>>120
何かまとまってないぞ(笑)

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

ぶっちゃけそれだけ。

122 :nobodyさん:04/06/01 20:28 ID:???
>>121
書いているうちに訳分かんなくなっちゃったw
最初の1行だけで済ませばよかったかな


123 :nobodyさん:04/06/01 22:09 ID:???
>>119
サーバ側で生成したサーバ側でしか利用しない値は、
わざわざhiddenで引き回したりしない。つか、してはいけない。
セキュリティホールにもなりうるし。

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

124 :nobodyさん:04/06/02 16:13 ID:???
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です。

125 :nobodyさん:04/06/03 15:13 ID:???
バグと言うか、仕様じゃないの?

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

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

126 :nobodyさん:04/08/20 09:10 ID:rKFIPCr5
CGIに、PHPとPerlがあるんだけど、セッション管理は問題無くできるよね。
バージョンとか微妙なところで制限事項があるのかな?

127 :nobodyさん:04/08/20 15:48 ID:???
はてさて、cookieに限定したセッションの話かしらん

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

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

129 :nobodyさん:04/08/24 16:45 ID:mVJd0HpM
>128
history.backで戻ってセッション切れちゃうのは仕方ないね。
戻り先のページが別ページなら普通にリンク貼ればOKだと思うけど。。

130 :nobodyさん:04/08/24 16:52 ID:???
結論
セッション(゚听)イラネ

131 :nobodyさん:04/09/02 15:49 ID:???
言われただけの情報で結論出してセンスねえな〜、想像力ゼロか?
それでカッコイイと思ってんのか?キモイ奴だな。

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

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

132 :nobodyさん:04/09/03 00:37 ID:???
>>59
亀レスだけど、目から鱗。今日悩んでいたことが氷解した。
解説書に書いてあることが間違ってたよヽ(`Д´)ノ
とにかく、一言言わせてくれ。どうもありがとう。


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


134 :nobodyさん:04/09/03 10:05 ID:???
>>133
セッションに接続元のIPを記録しておいて
if ($_SESSON['ip'] != $_SERVER['REMOTE_ADDR']) {
die 'あぼーん';
}

135 :nobodyさん:04/09/03 10:14 ID:???
>>134
携帯サイトでクライアントをIPで判断できないでしょ?
キャリア側のプロキシのIPだらけになるのでは?
PCサイトの場合でもIPでの判断だと、NATの内側のクライアントは一纏めにしちゃうの?


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

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

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

137 :nobodyさん:04/09/05 23:33 ID:5TcSHTQS
age

138 :nobodyさん:04/09/06 14:10 ID:???
>>133
まず前提からして間違ってる。

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

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


139 :nobodyさん:04/09/27 20:49:22 ID:???
結局、全てをSSLで通信しないとセッションハイジャックは防げないということでFA?


140 :nobodyさん:04/09/28 01:10:51 ID:???
あてずっぽう

141 :nobodyさん:04/09/28 17:26:54 ID:???
      は、

142 :nobodyさん:04/09/28 18:58:14 ID:???
              防げ

143 :nobodyさん:04/09/29 14:00:46 ID:Gp3joNGA
お上(経産省-産総研)はすべてのページをhttpsにしてcookieにsecure属性を付けるか
もしくはhttp用のcookieとhttps用のcookieの二つを発行しろと言ってるね。

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

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

144 :nobodyさん:04/10/06 22:15:29 ID:???
基本的なことでスマンがセッションって何?

145 :nobodyさん:04/10/07 21:46:09 ID:eGrZpUzk
セッションってどこに保存されるの?

146 :nobodyさん:04/10/07 22:01:55 ID:???
tmp

147 :nobodyさん:04/10/07 22:05:54 ID:???
session.save_path

148 :nobodyさん:04/10/07 22:28:49 ID:???
サーバー側に保存されるんだよね?
セキュリティ的にはどうなんだろう?

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

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

151 :nobodyさん:04/10/07 23:27:27 ID:???
む、難しいな orz

152 :nobodyさん:04/10/07 23:33:22 ID:???
大丈夫、実際そこまでちゃんと気ぃ使ってるサイトなんてほとんどないからw

153 :nobodyさん:04/10/08 00:39:22 ID:???
>>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

154 :nobodyさん:04/10/08 00:56:47 ID:???
素で知らんかった。マジありがとう。

155 :nobodyさん:04/10/08 01:37:35 ID:???
>>153
setcookieの最後の引数で指定でもいい?
この場合setするcookieのkeyによってセキュア属性のあるなしになるのかな?

156 :nobodyさん:04/10/08 11:59:28 ID:???
>>155
setcookie() だと最後の引数で指定すれば個別に secure フラグありとなしで
複数の Cookie を設定できる。例えば、以下のような感じで。

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

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

157 :nobodyさん:04/10/08 14:14:20 ID:???
>>143
>もしくはhttp用のcookieとhttps用のcookieの二つを発行しろと言ってるね。
に関してはsetcookieの引数で分けるのが良さげかな。

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

158 :nobodyさん:04/11/05 23:35:57 ID:onIpwNyM
ヒロシです

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

ヒロシです

159 :nobodyさん:04/11/07 18:16:49 ID:???
>>158
データの内容とアクセス頻度(規模)などによって一概にどっちが良いかは言えないし、
「良い」の基準が決まっていないとレスのしようもないんじゃない?

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

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


160 :nobodyさん:04/11/07 21:42:34 ID:???
ヒロシです

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

ヒロシです

161 :nobodyさん:04/11/09 18:20:01 ID:aEAOTgZ1
アンケートページのフォームのValue値をセッションに入れて各ページ間で持ち回りってアブない?



162 :nobodyさん:04/11/12 12:40:22 ID:2kt36js1
PHPでセッションを使って管理ページに入りページの更新やメール配信などをしています。
使用人数は10人です。
OSは基本的にwindowsでバージョンはXPや98など様々です。

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

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

163 :nobodyさん:04/11/12 13:38:08 ID:???
Perlのセッションについて語るすれはどこですか?

164 :nobodyさん:04/11/12 14:19:13 ID:???
>>162
これが参考になるんじゃないかな
http://www.asahi-net.or.jp/~wv7y-kmr/memo/php_security.html#PHP_Session_GC

165 :nobodyさん:04/11/16 15:55:39 ID:???
このスレだけでご飯一杯食べれました。

166 :nobodyさん:04/11/16 16:34:38 ID:???
食前酒みたいなスレやなw

167 :nobodyさん:04/11/17 21:13:10 ID:K1rG9sHP
ヤフーのセッション管理の仕組みって、どうなってるんでしょうか。
ページ移動するたびにDBにアクセスしてCookieと照合してます?

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

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

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

170 :nobodyさん:04/11/21 01:16:45 ID:???
>>169
どうも混乱しているようにしか見えないのだが…
HTTPクライアント作ってるって時点で「板違い」

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


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

172 :nobodyさん:04/11/24 06:52:52 ID:???
>>169
セッションクッキーで通じるから別にいいけど
確かに用語の使い方がいろいろ不明な点があって
日本語として文が構築されてない

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


174 :nobodyさん:04/11/24 14:09:50 ID:???
>>173
やばくはないと思うが
それじゃセッションIDを使う意味があまりなくね?
セッションIDの発行方法にもよるけど
PHPのセッション関数使ってるなら大丈夫じゃないの?

175 :173:04/11/24 15:43:40 ID:???
>>174
レスありがとうございます

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

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

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

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

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

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

177 :nobodyさん:04/11/26 20:15:19 ID:5ndPRR48
PHPセッションを生成した段階で、接続元IPを保持すれば、少なくとも
全く異なるネットワーク&端末からの接続は排除できる。
(NAT環境とか一部のCATV環境からのアクセスはどうしようもないけど)。

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

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


178 :173:04/11/26 20:37:10 ID:???
>>176
やっぱりサーバ負荷は一番気になるとこですね。
たいへん参考になりました。
ありがとうございました。

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

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

気のせい?

180 :nobodyさん:04/11/27 07:24:52 ID:GhxEggFV
>>179
IPで認証するの?

181 :nobodyさん:04/11/27 13:53:20 ID:???
>>179
そういう仕組みですから
みんなそれを前提につくってるんだよ

182 :nobodyさん:04/11/27 14:23:13 ID:???
>>179
今更何を言ってるんだ?

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

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

184 :nobodyさん:04/11/28 17:21:57 ID:???
>>183
FTPとtelnet/SSHはステートレスなプロトコルではないので
セッション管理自体要らんと思う

185 :nobodyさん:04/11/28 23:38:51 ID:???
$_SESSIONに"cid"っていう名前で登録しちゃいけないの?
他の変数は無事なのに、これだけたまに消えるんだけど…

186 :nobodyさん:04/11/29 12:38:23 ID:???
>>184

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

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

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

187 :nobodyさん:04/11/29 14:14:13 ID:???
>>186
それじゃインターネットに繋がってるだけで送受信できないし
ACK返す前に変わるとかそんなシステムあるの?

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

188 :nobodyさん:04/11/29 16:37:42 ID:???
>>187
セッション汁!?

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

189 :nobodyさん:04/11/29 22:17:54 ID:???
>>188
その回答は>>178だけが知っている。
「毎回IPアドレスが変わる環境」の“毎回”って何よ?

190 :nobodyさん:04/11/30 01:20:22 ID:???
ttp://yougo.ascii24.com/gh/79/007983.html
黙って読め

191 :nobodyさん:04/11/30 09:58:03 ID:???
>>189
もしかして
「ダイアルアップする度の間違いだろ」
とか思ってないよね?w

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

193 :nobodyさん:04/11/30 14:41:16 ID:???
>>192
セッションが切れてない間は
IPアドレスが変わらないって言いたいの?

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

194 :nobodyさん:04/11/30 21:15:35 ID:???
>>193
さっさと話を終わらせてくれって言いたいの?

ならそう言えよ

195 :nobodyさん:04/11/30 22:03:43 ID:???
>>193
逆でしょ?
「IPアドレスが変わっても(サービスのために)セッションを切らない」
為の仕組みが「PHPセッション」な訳ですよ。

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



196 :nobodyさん:04/11/30 22:54:22 ID:???
>>195
激しく同意!

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

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

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

197 :nobodyさん:04/12/01 11:09:14 ID:???
どれがだれの発言なんだか
全くわからん
1人の自演だったらすごいけど

198 :nobodyさん:04/12/01 15:47:55 ID:???
ここにはオレとオマイしかいませんよ?

199 :nobodyさん:04/12/01 17:02:20 ID:???
>>198
よかった、一人じゃなかったんだ

200 :nobodyさん:04/12/01 19:13:52 ID:???
少なくとも3人いるな(w

201 :nobodyさん:04/12/01 22:34:09 ID:???
俺もいるよ
仲間はずれにしないでくれ

202 :nobodyさん:04/12/02 09:00:03 ID:???
じゃぁ3人ってことね

203 :nobodyさん:04/12/02 09:43:08 ID:???
4人目。

204 :nobodyさん:04/12/02 21:26:45 ID:pa/YvkmO
点呼とか死ぬほどウゼーしさ、キモイから消えてくんね?

205 :nobodyさん:04/12/03 00:38:38 ID:???
>>204
そんな無意味なこと書く前に>>178の後半に突っ込み入れるなり
フォロー入れるなりしてみろよ。出来なきゃすっこんでろ。

206 :nobodyさん:04/12/03 03:27:54 ID:???
なんでそこで>>178が出てくるんだか

207 :nobodyさん:04/12/03 03:43:36 ID:???
>>206
>>205==>>178

208 :nobodyさん:04/12/03 12:41:20 ID:???
結構入れ食いだと聞いたんですが、
ここでいいんですか?

209 :nobodyさん:04/12/03 14:49:15 ID:w3rfsX9n
かみ合わない会話が人格攻撃に発展したスレはココですか?

210 :nobodyさん:04/12/03 16:43:06 ID:???
おまいらセッション使う時、ハンドラはファイル使ってますか?
それともDBハンドラ書いてます?

漏れはDBハンドラ使ってるけど。


211 :nobodyさん:04/12/04 09:33:25 ID:???
>>210
バランシングしている複数のwebサーバでセッションを共有したいので
セッション情報はバックエンドのDBに入れてDBハンドラ使いまくりです。

212 :nobodyさん:04/12/04 10:21:05 ID:???
俺はNFSでファイル共有してます。
物理的にバックエンドDBサーバと同じところにあるので
DBで共有しても良いのだが。特に意味は無いがファイルで。

213 :178:04/12/04 12:27:40 ID:???
>>205
なにか間違ってる?

214 :nobodyさん:04/12/04 14:45:51 ID:???
>178 別に間違ってないと思うよ。
>183 とか >186 とかで訳分からん事言ってから話がおかしくなったみたいねえ。

215 :nobodyさん:04/12/04 21:59:42 ID:???
なるほど...

216 :210:04/12/08 02:26:30 ID:???
>>211
漏れと用途が一緒だ。。

>>212
一度NFSでと考えたけど、オーバーヘッドでかくないですか?

DBハンドラでも大してかわらんかも。。。
ベンチはかってないから分からないけど。。


217 :みきすけ:05/01/18 09:30:28 ID:fy32GETL
どうやってセッション管理すんの!!

218 :みきお:05/01/18 10:19:23 ID:fy32GETL
みきすけさんへ
マニュアルを見てください。

219 :nobodyさん:05/01/18 10:49:26 ID:???
>>217-218
新手の自演?


220 :nobodyさん:05/01/22 12:37:17 ID:???
コントじゃろ。

221 :みきすけ:05/01/23 13:52:25 ID:VKXvKdgM
この前の書き込みはすいませんでした。
掲示板とか書き込むの初めてなので失礼なことをしてしました。
今、授業でPostgreSQLとPHPを用いてでセッション管理と
ユーザ認証をするプログラムを書かなければならなくて本から
ユーザ認証のプログラムをパクッたんですが、変更しなければ
ならない箇所があるらしく、さっぱり分かりません。
ログイン後の画面のURLを直接入力してもログインしていない状態
ではエラーがでて、そこにとべないようにようにするには
プログラムに何て書けばよいのでしょうか?
理解度が足りず、意味が通じないような質問になってすみません。

222 :nobodyさん:05/01/23 13:58:56 ID:???
その授業とやらには、先生やら生徒やらはおらんのかのぅ。

223 :nobodyさん:05/01/23 14:16:17 ID:???
>>221
パクった本をまずはよく読むこと。
"課題"なんだから、意味判らんままにコードを流用すんな。

つか、見るのはどんな先生かしらんが、
PHPぐらいなら出版物の量も少ないので
コードのパクりかたが、あからさまだとばれるよ。

224 :nobodyさん:05/01/23 16:25:22 ID:???
俺もPHPじゃないけど課題出た時に
めんどくさくて書籍のサンプル丸写ししたんだが、先生にばれた。

しかし、先生が机に叩き付けた本は出版社も著者も全然違う人だった。
うーん。

225 :nobodyさん:05/01/23 17:00:25 ID:???
コードは知らんが、解説は本も別の本からのパクリが入ってることもある。
かといって別の本や資料を全然参考にもしてない記述は、
アレ?と思うような変な(適正とは言いがたい)内容のものも、ちらほら

226 :nobodyさん:05/01/23 18:54:00 ID:???
>>224
そう言うのは変数名くらい変えとかないと。
あと、インデント幅とかカッコの付け方とか
コメントを適当に付けたりして誤魔化すと完璧。

227 :nobodyさん:05/02/04 13:02:28 ID:vme7g+zP
まじ役にたたねぇ。
まともな回答一つもないし。
結局そんなもんか。



228 :nobodyさん:05/02/04 15:44:32 ID:???
つーかPHP読めないとその他の言語に移ると絶望的だぞ
これほど簡単な言語はない。arrayの取り扱いを
始めたみたときは正直チンポの先から汁がちょっと出た。ちょっとだけね

229 :nobodyさん:05/02/15 18:16:00 ID:???
携帯でtopページ以外をブックマークや直リン禁止にするという処理も
phpとセッション管理でできるのかな?

230 :nobodyさん:05/02/15 18:17:02 ID:???
でも具体的にそういうスクリプト配ってる所ってないよね。
需要は充分すぎる程あると思うんだけど…

231 :nobodyさん:05/02/15 23:46:53 ID:???
>需要は充分すぎる程あると思うんだけど…

そんなケツの穴の小さいこと考えてんのお前だけだよ(ガハハ

232 :nobodyさん:05/02/17 12:47:08 ID:???
>>229
topページなんか見たくないんです

233 :nobodyさん:05/02/17 13:14:28 ID:???
>>229-230
救えない阿呆

234 :nobodyさん:05/02/17 18:17:56 ID:???
具体的の使い方が違いますよ。

235 :nobodyさん:05/02/17 18:39:57 ID:???
このスレってなんのためにあんの?

236 :nobodyさん:05/02/17 18:44:58 ID:???
>>1のことをプッて笑うスレですよ?
>>3書いたのオレだ。懐かすぃ

237 :nobodyさん:05/02/17 20:07:35 ID:???
>>236
プッ

238 :nobodyさん:05/02/20 15:45:27 ID:HD8VrkSM
セッションってhiddenによるデータの持ちまわしや
URLにクエリ文字列を埋め込む方法等とどのように使い分ければいい?

239 :nobodyさん:05/02/20 18:02:46 ID:6EZLRG8p
ページの変遷すべてにformからsubmitで跳びたくなければURLで引き回しなさい

240 :nobodyさん:05/02/20 18:26:29 ID:???
>>238は、
POST・GETの話じゃなくて、セッション使用とページ毎に全データ渡しの話の希ガス
オイラは特に使い分けはしてない。その時の気分次第

241 :nobodyさん:05/02/20 18:39:53 ID:6EZLRG8p
>>229
セッション切れてたらTOPページにリダイレクトするとかで良いんじゃね?

242 :238:05/02/21 02:23:56 ID:???
つーかあれか。ページIDのようにボタンを押すたびに変わるような
ものはhiddenやクエリーで持ち、ログインIDやパスワードのような
ずっと持ちまわすようなものはセッションというような使い分けかな?
と自己レス。

243 :nobodyさん:05/02/22 00:15:50 ID:???
藻巻いらPHPの知識とかどこで仕入れてくんの?

244 :nobodyさん:05/02/22 07:48:53 ID:???
知識そのものじゃなく仕入れ方まで聞くのかよっ

245 :nobodyさん:05/02/22 12:43:47 ID:???
>>243
魚河岸で。

246 :nobodyさん:05/02/22 18:43:15 ID:???
俺はPerl⇒PHPときたが、Perlの場合は既存のスクリプトが腐るほどあったんでそれを参考にしながら覚えて
PHPはマニュアルが充実してるんで、殆どそれ見ながら覚えたヨ!

247 :nobodyさん:05/02/23 08:55:22 ID:mE2XQAit
あげー

248 :nobodyさん:05/02/24 17:29:34 ID:???
PHPは簡単だよ。・・・そう、知的障害児が道路を横断するのと同じぐらい

249 :nobodyさん:05/02/24 19:49:22 ID:???
何を伝えたい例えなのか全然わがんね

250 :nobodyさん:05/02/24 21:38:01 ID:???
>>248
貴様の息子/娘が知的障害児で産まれるように強く願ってます

251 :nobodyさん:05/02/24 23:25:30 ID:???
ぶっちゃけPHPなんかリファレンス本を1日読めば次の日から
「PHPできます」って面接で言っちゃって大丈夫。
俺はそうした。余裕でしょこんな雑魚言語。

252 :nobodyさん:05/02/24 23:33:01 ID:???
「できます」なんて指標は、客観的でないのでちっともあてに出来ない。
つうてもJava5年とか書かれてるスキルシートも全然あてにはならんが。

253 :nobodyさん:05/02/24 23:33:24 ID:???
>>251
wラタ
よっぽど酷い会社なんだな

254 :nobodyさん:05/02/25 01:10:45 ID:???
ワロタ

255 :251:05/02/25 23:52:19 ID:???
笑い事じゃなくて、PHPを習得するのに3日以上かかるようじゃ
正直プログラマとしてのセンスを疑うね。

256 :nobodyさん:05/02/25 23:54:11 ID:4WDXXuTL
習得ってどの程度を言うのでしょうね

257 :nobodyさん:05/02/25 23:59:29 ID:???
けいじばんつくれるぐらい!

258 :nobodyさん:05/02/26 10:15:19 ID:???
>>251
そんなんで企業に入れるのか
やばくねぇかそこw

259 :nobodyさん:05/02/26 10:30:38 ID:???
山田系かも

260 :251:05/02/26 22:58:19 ID:???
お前等ってPHPを習得するのに1ヶ月とかかけるわけ?能無しか?
ちなみに俺は会社に入ったわけじゃなくて個人事業主として
業務委託されてるだけだけどな。

261 :nobodyさん:05/02/26 23:20:36 ID:???
習得ってどの程度を言うのでしょうね
セッションの話まだー?チンチン

262 :nobodyさん:05/02/27 01:15:18 ID:???
セッションへんすうにだいにゅうできるぐらい!

263 :nobodyさん:05/02/27 21:56:58 ID:???
>>261
普通に業務をこなせるくらいだろ?
馬鹿かお前?

264 :nobodyさん:05/03/01 22:07:03 ID:???
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>';
?>


265 :nobodyさん@264:05/03/01 22:08:48 ID:B0aTXW7C
(追加)
OSとPHPは
Apache/1.3.28 (Win32)
PHP/4.3.10 です。


266 :nobodyさん@264:05/03/01 22:20:47 ID:???
1969 12 31 23:57:00
と出るのは、$_SESSION['time'] がNULLのままだからでしょうね・・・

php.ini では
session.auto_start = Off
session.use_trans_sid = On
なんですが、他に設定するところなどがあるでしょうか?


267 :nobodyさん:05/03/02 12:42:44 ID:???
まずは最初のページへアクセスした際に
php.iniで設定したsession.save_pathに
保存されているかを確認してみましょう。

268 :nobodyさん:05/03/02 12:45:20 ID:???
あと、PHP will not create this directory structure automatically.
と書いてあるので、例えばsession.save_path = "C:\tmp"だったら事前に
tmpフォルダを作っておかないといけない。

269 :nobodyさん@264:05/03/02 22:07:46 ID:???
>>267 >>268
お世話になります。

何故か php.ini で session.save_path = c:\php\sessiondata になってました・・・
(いつの間に???)

いろいろなページを参考にしていじっている内に、こうなってしまった様です。
一応、phpの下にsessiondataを作って動くようになりました。
基本的にはc:\tmpですよね・・・

お手数をお掛けしました。m(_ _)m


270 :nobodyさん:05/03/19 13:08:11 ID:oXb2sDzY
セッション変数て、PHPデフォのファイルで管理すんのとDB使うのとぶっちゃけどっちが
早いの?軽いの?

271 :nobodyさん:05/03/19 13:36:06 ID:???
どっちが速いかはようわからんっちゅーか、どーでもええし、どーせ大差ないとは思うんだけど
ユーザが増えたときにファイルだとinodeの制限を受けてエラー発生てのもあり得ますから。
だから大規模サイトならDB以外ありえない。

272 :nobodyさん:05/03/19 18:33:39 ID:???
>>270
大規模の場合はバランサーはさんだりでめんどいからDBセッション多用する。

273 :nobodyさん:05/03/19 20:43:56 ID:???
270じゃないけど参考になった

274 :nobodyさん:2005/04/21(木) 22:24:22 ID:zxQ/ZLfo
session_regenerate_id();を使うとc:\tmpにsess_***・・・・・・・が残りまくります。
そこで、不要になったセッションファイルを削除しようと思います。
で、下記のようにしてみましたが、全然消えません・・・


session_start();

$session_id = session_id();//セッションIDのバックアップ
session_regenerate_id();//セッションID変更
unlink ("c:\\tmp\\sess_".$session_id);//以前のセッションIDのファイルを削除


ちなみに、
unlink("c:\\tmp\\sess_セッション番号の現物")を使うと確かに消えてくれます。

なんなんでしょか?これ?



275 :nobodyさん:2005/04/22(金) 13:42:40 ID:???
>>274
セッションのタイムアウトくれば勝手に消えていくとは思うんだが。

276 :nobodyさん:2005/04/22(金) 15:46:10 ID:???
ガベージコレクション

277 :274:2005/04/22(金) 20:12:55 ID:???
>>275
>>276
まぁ、そうなんですけどねぇ・・・



278 :nobodyさん:2005/04/23(土) 16:09:07 ID:???
>>274
ファイルがいやならDBセッションでもつかえば?

279 :nobodyさん:2005/06/23(木) 00:30:15 ID:???
マジでハマっているんで、誰か教えて。
セッション管理を MySQL + PHP で考えていています。

$_SESSION['hoge'] = $hoge;

とかやった直後は、ハンドラで定義した関数が呼び出されて、
指定したテーブルに $hoge の内容をシリアライズしたような
文字列が格納されているのですが、その後に別の画面へ refresh で
遷移させた後、$_SESSION['hoge'] の値を参照すると何も入っていません。

テーブルを確認すると、直前まで入っていた文字列がブランクになっています。

ちなみに、全ての画面の先頭で session_set_save_handler() と
session_start() を行っています。
これが悪いんでしょうか?


280 :nobodyさん:2005/06/23(木) 02:17:26 ID:???
>>274
PHP 5.1.0なら自動で削除されるよ。

281 :nobodyさん:2005/06/23(木) 09:36:51 ID:???
>>279
ユーが定義したセッション保存関数を晒さない限りは何ともいえん。

282 :279:2005/06/23(木) 21:30:07 ID:jMq3kGLZ
>>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;
 }


283 :279:2005/06/23(木) 21:30:37 ID:jMq3kGLZ
 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 "";
  }
 }


284 :279:2005/06/23(木) 21:35:17 ID:jMq3kGLZ
 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;
 }

285 :279:2005/06/23(木) 21:36:08 ID:jMq3kGLZ
 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;
 }
}

よろしくお願いします。

286 :nobodyさん:2005/06/24(金) 02:44:53 ID:???
>>279
なぜ保存関数が全部クラスにまとめられてるの?
session_set_save_handlerのサンプルでは単なる関数の集まりになってるけど、その辺大丈夫?
あとrefreshして表示されるアドレスのホスト名はおなじだよね?

287 :nobodyさん:2005/07/20(水) 06:09:06 ID:???
URLにPHPSESSIDを出したくないのですが、どうすればよいのでしょうか?


288 :nobodyさん:2005/07/20(水) 13:11:14 ID:SCPYU6yF
>>287
session.use_trans_sid
session.use_cookies

289 :nobodyさん:2005/07/21(木) 12:17:04 ID:wgpYmPTZ
>>288
session.use_cookies = 1
session.use_trans_sid = 1

クッキーが使えるときはクッキーを使って渡し、
クッキーが使えないときはURLにパラメータを付けて渡す・・・ってことですよね。

ブラウザ側のクッキーは使える設定です。
が、全てURLにパラメータが付いてきます。
ちなみに、
session.use_trans_sid = 0
にするとページが変わる毎に新規にセッションIDが作られ、セッションが保持されていません。

なんなんでしょか?これ。



290 :nobodyさん:2005/07/21(木) 14:59:56 ID:wgpYmPTZ
>>289
自己解決しました・・・

php.iniの中のsession.cookie_path =が
session.cookie_path = /tmp
になっていました・・・(何でだろ・・・???著しく不明。

session.cookie_path = /
で問題無く動きました。


291 :nobodyさん:2005/07/23(土) 03:28:54 ID:???
!?

292 :nobodyさん:2005/07/25(月) 06:19:23 ID:???
>>290
!?

((((;゚Д゚))))ブルブル

  。 。
  / / ポーン!
( Д )


環境はwindowsですか?
Linuxならある意味凄いと思う。

293 :nobodyさん:2005/08/16(火) 14:15:34 ID:OHYrGECG
オマイラ教えてください。m(_ _;)m

実はセッションファイルの置き場をtmpfsで作ろうと思います。
しかしながら、単純にtmpfsで/tmpを作って重ねてしまうと、既に入っている各種のファイルを使えなくなるため鯖の動作がおかしくなります。
んで、Apache+phpのセッションファイル専用に/tmp2を作ろうと思います。
が、php.iniのsession.save_pathを/tmp2にして再起動し、セッションが働くように動作させても、/tmpの方にセッションファイルが書き込まれて行きます。
/tmp2のパーミッションを777にしても同じです。
php.iniのsession.save_pathの設定が無視されているようです。

これはどういうことなのでしょうか?
教えて下さい。



294 :nobodyさん:2005/08/16(火) 14:43:15 ID:???
>>293
わかった
先頭に;がついたままでコメントになってる

295 :nobodyさん:2005/08/16(火) 15:08:20 ID:???
>>294
ち・ちがう・・・orz







そこまでアホやないっつぅの (`・ω・´)


296 :nobodyさん:2005/08/16(火) 16:05:05 ID:???
>>295
じゃあスクリプトで
ini_set('session.save_path', '/tmp');
とかやってる
わけないよね
ていうか
ini_set('session.save_path', '/tmp2');
としたらどうなる。

297 :nobodyさん:2005/08/16(火) 17:06:52 ID:???
>>296
どうもです。m(__;)m

session_start();の前でやるってやつでしょ。
その手も考えたんですけど、それ以前に「なんでこ〜なるの???」状態です。
php.iniの記載が無視されているんですよ。
別のphp.iniを読みに行っているのか?と。(そんなことは無いと思うが・・・)


最後の手段はini_set('session.save_path','/tmp2');ですね。


298 :nobodyさん:2005/08/16(火) 17:19:48 ID:???
>>297
そのphp.iniが読み込まれてることは
確認した?

299 :nobodyさん:2005/08/16(火) 18:10:31 ID:???
>>298
他に無いですから・・・
(ZENDのツールがクサイのですが・・・)

尚、ini_set('session.save_path','/tmp2');では動くことを確認しました。

しかし、このini_set()で作ったセッションファイルも、
しかるべき確率で掃除してくれるんでしょうかね?
まぁ、暫く見ていれば分かる話なので観察しますよ・・・orz

お手数をお掛けしました。ありがとうございました。 (´・ω・`)ノ~~~



300 :nobodyさん@299:2005/08/16(火) 19:06:15 ID:???
あっ!ちゃんと掃除してくれますよ!

ini_set('session.save_path','/hoge');で作られたセッションファイルも消してくれるんですね。
1440秒経ったら100分の1の確率で掃除してくれます。

これで行きますよ。

(´^ω^`)ノ~~~~


301 :nobodyさん:2005/08/27(土) 22:03:36 ID:???
解決したの?

302 :nobodyさん:2005/09/10(土) 06:23:44 ID:???
298の段階で止まってる

303 :nobodyさん:2005/11/01(火) 21:44:14 ID:F+HZoSiJ
サーバサイド側のセッション管理をした場合、例えばフォームを
行き来する場合はどうなるのでしょうか。

hiddenでセッションIDを持ち歩く必要性があるという解釈でよいの
でしょうか。

304 :nobodyさん:2005/11/03(木) 02:42:33 ID:8uhVEs5z
*** すべてのPHPユーザーに告ぐ ***

http://www.hardened-php.net/advisory_202005.79.html
http://www.hardened-php.net/globals-problem
http://blog.ohgaki.net/index.php/yohgaki/2005/11/02/phpa_rc_fei_a_oa_oa_fa_sa_le_acsa_oe_afp

PHPに深刻な脆弱性がある事が発表されました。今まで見つかったPHPの脆弱性の中でも「最悪」の脆弱性です。全てのPHPユーザは今すぐ対処を行う必要があります。

305 :nobodyさん:2006/01/24(火) 11:00:18 ID:1bRZq7Cs
AGE

306 :nobodyさん:2006/02/08(水) 19:28:12 ID:???
セッションを使うと必ずサーバー上の/tmpにファイルが作られブラウザを閉じるとファイルが残ってしまうのだけど
これを残さないようにすることってできるのかな?


307 :nobodyさん:2006/02/08(水) 20:13:42 ID:???
>>306
セッションファイルはちゃんとガーベージコレクトされる筈だが。
ガーベージコレクトのタイミングやゴミとみなされるまでの時間を見直したら?

308 :nobodyさん:2006/02/12(日) 22:08:23 ID:8opibPhp
>>306
セッションハンドラをいじればDBにだって保存できるぞ。

309 :nobodyさん:2006/02/13(月) 07:03:19 ID:???
>>303
>hiddenでセッションIDを持ち歩く

すごく無意味&恐ろしいこと言ってるな・・・

310 :nobodyさん:2006/02/13(月) 20:01:20 ID:???
>>309
何が無意味でどう恐ろしいの?
俺も似たようなことやってるので教えて欲しい。


311 :nobodyさん:2006/02/13(月) 22:54:37 ID:???
>>310
まんま続けてろ。
探してそのうち遊びに行ってやるw

312 :nobodyさん:2006/02/15(水) 12:02:34 ID:???
>>こういう人って知ってて教えてやらないの?
それとも知ったかぶりしてるの?


313 :nobodyさん:2006/02/15(水) 12:05:15 ID:???
ごめ。>>311ね。


314 :nobodyさん:2006/02/15(水) 13:19:08 ID:???
session.use_trans_sidがOnの状態にしてるのと変わんないよ>hidden
そりゃcookieでSIDを持たせた方が、安全性は高まるけど
そうではなくGETとか選択してるのは、理由があってやってるんだろ?

315 :nobodyさん:2006/02/15(水) 14:53:21 ID:???
cookie使えない携帯用とか

316 :nobodyさん:2006/02/27(月) 21:51:57 ID:UfqSpQ0b
セッション管理ってよくわからないんですけど
要するにパスワードかなんかでふるいにかけても
URLで「login=ok」みたいに渡しちゃってたら誰でも入れてこれは困ったな
見たいになるのを防ぐものなんですか?

317 :nobodyさん:2006/02/28(火) 01:15:27 ID:FEcOQ9wP
hiddenも普通に使う。要件による。当たり前。

318 :nobodyさん:2006/02/28(火) 08:22:56 ID:???
>>316
>「login=ok」みたいに渡しちゃって
ということを普通は最初からしないので、何とも。
セッションはその名のとおり、C/S間のやり取りが
継続しているということを実現するための仕組み。

かといって特に新しいことも、物凄く高度なことでもなく
かつてPHPの標準のセッション機能が無い頃は、各々が
ごく当たり前に独自にセッション機能を作ってやってたもんだよ。
(PHPlibとかあったけど)
だから今でも、何も難しく考えることはない。ただあるものを使えばいい。

319 :nobodyさん:2006/03/12(日) 22:04:26 ID:???
クッキーなんで偽造出来るんだけどね。
セッション乗っ取れば認証回避出来るよ。

320 :nobodyさん:2006/03/14(火) 02:05:53 ID:???
セッション生成場所にF5アタックされたら
めちゃくちゃセッション作ってくれるとおもうんだけど
貴殿らどういう対策してる?

321 :nobodyさん:2006/03/14(火) 03:11:17 ID:???
>>320
セッション生成場所に限らずF5アタックは嫌なので
httpdより前にブロックしてる。

322 :nobodyさん:2006/03/14(火) 03:56:20 ID:???
>>320
F5アタックなら全部同じセッションになるんでないの?

323 :nobodyさん:2006/03/14(火) 21:59:30 ID:???
>>321
ううむ、やっぱそのレベルで防がないとだめかー
スクリプトレベルで防ぐのはあんまり賢くないかな
たとえば何件いったら新規セッションを一時発行しなくするとかね

>>322
クッキー拒否だと新規セッションにならない?

324 :nobodyさん:2006/03/15(水) 02:07:44 ID:???
クッキー切ってる香具師にはセッションを発行しなきゃいい

325 :nobodyさん:2006/03/15(水) 12:33:20 ID:aJbbMre9
>>321
httpdより前でブロックって
何を使ったらできるの?

326 :nobodyさん:2006/03/15(水) 12:41:21 ID:???
>>325
ルータじゃないの

327 :nobodyさん:2006/03/16(木) 00:21:52 ID:???
企業ではセキュリティ上クッキー食べなくさせてる所も多いので、そう言う客も失う覚悟だな。
httpd自身(libwrappr)とか鯖のIP処理レベルとか、本命のファイヤーウォールとか。
ちなみにルータで処理させるとルータの負荷が騰がって、他の通信にも影響が出るから辞めるべき。

mod_php弄って特定IPからのアクセスにRSTパケット返しちゃうってのも、F5連打廚にはいいカモな。

328 :321:2006/03/16(木) 01:53:28 ID:???
>>325
自分が使ってるのはiptablesだから、そこの中で。
つかhttpだけじゃなくて、sshやftpへのブルートフォースアタックがかなり多いので、
それらもまとめて弾いてる。Apacheでやるなら、mod_dosevasiveみたいなまんまの奴や
帯域を絞るモジュールなど色々あるよ。

phpで対処するってのは、自分で手を出せるところの範囲が狭くて
どうしようもない時の残された方法かと。F5アタックならphpでなくても
負荷のかかるコンテンツならどこを狙っても良いわけだし。
レンタルサーバなら、収容している他のユーザが対処してないなら意味無いしね。

329 :nobodyさん:2006/03/19(日) 01:37:13 ID:???
セッションをDBに保管する方法は幾つかあるかと思いますが
皆さんのところは何を使ってますか?
とりあえずうちは「session_pgsql」を使ってますが他になにかいいのないですかねぇ。


330 :nobodyさん:2006/03/19(日) 17:39:22 ID:???
自作ハンドラなのらー

331 :nobodyさん:2006/03/19(日) 19:47:54 ID:???
全くのスクラッチと言うかオリジナル?
何からパクりましたか?

332 :nobodyさん:2006/03/20(月) 20:33:13 ID:???
Cookie必須にできないのでhiddenで引き回してるんだけど、
IPとブラウザのUA(吐かない場合あり)チェックだけだと
例えば社内LANとかでのハイジャックの危険性は残ったままだよね?
何かいい方法ないですか?

333 :nobodyさん:2006/03/22(水) 05:13:46 ID:???
>>332
社内LANってやつからWAN(サーバ)へのアクセスがプロキシ経由やNAT経由ならね。


334 :nobodyさん:2006/03/29(水) 12:18:47 ID:???
>>332
普通にIPが変わることもあるよ

335 :nobodyさん:2006/03/32(土) 12:40:07 ID:/aohY8EP
<?
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();
      }
    }
  }


336 :nobodyさん:2006/03/32(土) 12:41:53 ID:/aohY8EP
  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]);
    }
  }
}
?>


337 :nobodyさん:2006/04/02(日) 02:53:22 ID:???
http://labs.cybozu.co.jp/cbl_rememberme/

338 :nobodyさん:2006/04/13(木) 10:40:48 ID:YOyrE4Lu
携帯のランキングでセッションハイジャックしたいんですが、携帯のIPでの接続のみ
セッション発行してるみたいで、PCではセッションを採取できません。
特定のセッションが欲しいのではなく発行されているセッションであればOKです。
セッションの有効期限は3分?ランキングアウトPhpでセッション破棄しています。
何か有効な方法があれば教えてください。

339 :nobodyさん:2006/04/13(木) 11:45:21 ID:???
>>338
シネバイイトオモウヨ

340 :nobodyさん:2006/04/13(木) 12:41:30 ID:???
>>338
ツーホーしときますね

341 :nobodyさん:2006/04/13(木) 15:44:28 ID:???
DoCoMoの社員になってDoCoMo鯖からソケット使ってセッション取るとか(w
まぁ昔のRanklink改造した奴なんか簡単にセッションハイジャック出来たが、
セッション管理をファイルでやっててそのファイルがあるディレクトリに穴でもない限りは無理やね。


342 :nobodyさん:2006/04/29(土) 20:43:42 ID:???
いまさらだけど、PHPとセッションは関係ないじゃん。
関数の話がしたいならPHPスレじゃね?

343 :nobodyさん:2006/05/11(木) 17:30:38 ID:???
君は何を言ってるんだね。

344 :nobodyさん:2006/05/11(木) 20:40:30 ID:VDpWubyB
うわ。。
10日以上前の書き込みにレスしちまった。。

ヤケクソage

345 :nobodyさん:2006/05/12(金) 18:45:44 ID:???
君は何を言ってるんだね。

346 :nobodyさん:2006/05/12(金) 23:27:13 ID:???
10日くらい間空けろよ。







なんか期待しちまうじゃないかorz

347 :nobodyさん:2006/05/15(月) 01:15:16 ID:???
でも力任せでセッションID生成して送りつければいつかは突破できそうだけどな。
そのまえに鯖が異常に重くなってあぼんするだろうけど(w

348 :nobodyさん:2006/05/17(水) 22:20:27 ID:???
次のスレタイはこうだね。
PHPじゃないとセッションつかえないと思ってる香具師の数→

349 :nobodyさん:2006/05/19(金) 19:09:45 ID:???
ちょっと質問ですが、WebアプリでセッションにクライアントIPアドレス
を入れるという実装って普通しますか?

IPアドレスなんて変わることが多いからそんなことしないかと思っていたの
ですが




350 :nobodyさん:2006/05/19(金) 19:18:14 ID:???
結論としてはやめておいた方が良い。
再利用しているところが多いし、同じIPアドレスを使ってるPCだって結構ある。

351 :nobodyさん:2006/05/19(金) 19:22:28 ID:???
再利用というのは、DHCPから配られるIPアドレスという意味でいいですか?

あと同じIPアドレスを使っているというのは、NATのことでしょうか?
それくらいしか思いつかなかった。

352 :nobodyさん:2006/05/19(金) 19:22:52 ID:oMRPSSzC
データが通信途中全て第三者に取得されていると言う前提で、
SSLを使わないでデータを安全にやりとりする方法ってありますか?
JavaScriptとPHPでRSA暗号使ってやりとりしようと思ったのですが、
もっとスマートで対応するブラウザが多い方法ってありますか?
どなたかご存じの方教えていただけると嬉しいです。

353 :nobodyさん:2006/05/19(金) 20:14:41 ID:???
>>351
NATもproxyも。

354 :nobodyさん:2006/05/19(金) 21:39:58 ID:???
大企業やCATVとかでファイヤーウォール噛ませててインターネットからは一つのIPに見えてるってネットワークは有る。

RSAで簡単にやるのがSSLなんだけどね。わざわざSSL使わずにどうにかするほうが面倒で難しい。

355 :352:2006/05/19(金) 21:59:02 ID:???
SSLに対応しないブラウザの為に、、と考えていたんですが、
きょうびJavaScriptに対応しないブラウザよりSSLに対応しないブラウザの歩が珍しいかな。。orz

356 :nobodyさん:2006/05/19(金) 22:45:38 ID:???
>>350
俺は「一応の保険」みたいな感じでやってるなー
もちろん単なる簡単な保険程度の扱いだけど。


357 :nobodyさん:2006/05/19(金) 22:52:14 ID:???
>>350
作る「もの」によるかな?
シビアなチェックが要求されるものならIPチェックには頼らないが、セッションハイジャックされたところで
そんなに大したもんでもない程度のものなら、IPチェックすらしてないw
IPチェック程度を実装する事もある
みたいな。

358 :nobodyさん:2006/05/19(金) 23:02:07 ID:???
>>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

359 :nobodyさん:2006/05/20(土) 10:09:53 ID:???
セッションハイジャックを防ぐ手法一つとしての存在するのは理解できるのですが、
実際にどんな場合に利用してます?

個人的には無意味かなぁと思っていたのですが

保険的に利用する場合ってIPチェックして違った場合、ログを残すとかそんな感じですか?


360 :nobodyさん:2006/05/20(土) 12:50:03 ID:???
>>359
>>358


361 :nobodyさん:2006/05/21(日) 17:21:39 ID:???
セッションを使ったログイン・システムを作ったのですが、
ログイン後、操作をしない(通信をしない)時間が数分続くと、
勝手にログアウトしてしまいます。

ブラウザを閉じたわけでもないですし、session.gc_maxlifetimeは1440あります。
明示的にログアウト処理をしない限りログイン状態が続くようにしたいのですが、
どこの設定をいじれば良いのでしょうか・・・。

362 :nobodyさん:2006/05/21(日) 19:04:53 ID:???
>>358
そこ読んだけど
IPチェックはあまり意味ないって言ってる気がするが?

363 :nobodyさん:2006/05/21(日) 22:09:56 ID:???
>>362
そう。あんまり意味無い。
でも、全く意味が無いってわけでも無い。
つまり、それ程シビアなチェックを必要とされないものなら、この程度でも良いかもね程度に考えておけばと。

とにかくだな。
あくまで1つの手段としてこんなのもあるよって話しなので、気に入らないのなら別の方法を実装すれば良いだけの話。
頭で色々考えるのも良いが、まずは先に物を作って実際に動かした方が余程勉強になるかと。


364 :nobodyさん:2006/05/21(日) 22:13:15 ID:???
>>363
↓書き方悪かったな。
まずは先に物を作って実際に動かした方が余程勉強になるかと。
↑っていうのは、自分でセッションを使う簡易的なサイトでも作ってみて、それを自分でセッションハイジャック出来るかどうか試してみたら良いよって感じかな。
ハイジャックできてしまったら、それを防ぐにはどうすれば良いかを考えて改良し、また自分でハイジャックを試す。
そんな感じで完成度を上げていくと良いかなって思う。


365 :nobodyさん:2006/05/22(月) 10:41:52 ID:???
IPチェックだけは意味が無いね。
他との併用でしょ。セコムのシール貼ってるだけに近い。実際の防犯にはちゃんと対策が必要。


元々HTTPはステートレス。
セッションを使って無理矢理ステートフルに見せかけてるだけ。
NATとかkeepalive切ってる場合も有るから、鯖でがんばっても無理が有ることが多い。

366 :361:2006/05/22(月) 19:04:58 ID:???
放置されてるところを見ると、くだ質に行くべきでしたね。。。 行ってきます。

367 :nobodyさん:2006/05/23(火) 11:47:58 ID:8StU5eTg
質問させてください

セッションIDでログイン状態を判断するっていうのは
最初ログインしたときに
サーバ側のDBなどでセッションIDとログインしたユーザを
紐づけて管理するってことですよね?

それとは別に、ログイン時に
ログインIDとパスワードをクッキーに書き込んで
認証が必要なページでは毎回クッキーで判定しようと思うのですが
どんなリスクがあるのでしょう?
もちろんパスワードはMD5などの不可逆な変換を行い
クッキーもSSLのページのみで受け渡しします。



368 :nobodyさん:2006/05/23(火) 14:17:16 ID:???
クッキーがPCに残るから、それを第三者に取られたとき危うい。
セッションIDなら一度ログアウトしてしまえば大丈夫だけど、
それだとログアウトしてもクッキーさえ持っていれば再度ログインできる。

369 :367:2006/05/23(火) 15:03:01 ID:???
>>368
すみません、クッキーと書きましたが
ブラウザを閉じたら消えるやつで
いわゆるセッションと同じようなもののことでした。

でもブラウザの実装によっては
一時的でもクライアントに保存されるため
リスクが高いということでしょうか。



370 :nobodyさん:2006/05/23(火) 20:46:03 ID:???
>>369
強いて言うなら、その方法だと、XSSでクッキーを盗まれたときに、
パスワードを変更しない限り、その情報が使えてしまうけど、
XSS心配したらセッションも使えないし、
リスクという点では大差ないと思う。

セッションには、
・PHPに初めから実装されていて、手軽に使える
・ブラウザを閉じるまでは、以前の情報を継続して使える
という利点があるけど、単にログイン状態を保存しておくだけだったら、>>367の方法でも良いんじゃないかな。

371 :nobodyさん:2006/05/23(火) 23:07:03 ID:???
>>369
永続的なパスワードは一時的であれクッキーに保存するべきではない。
XSSでコッソリ取られた日には目も当てられない。


372 :nobodyさん:2006/05/23(火) 23:17:59 ID:???
>>371
パスワードそのままじゃない
って言ってるよ

373 :nobodyさん:2006/05/24(水) 15:21:01 ID:8TTcDRX+
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


374 :368:2006/05/24(水) 15:58:59 ID:???
>>372
よくよめ。
>>371
確かに。XSSの事忘れてた。。

つーか、わざわざパス記録すんなよ。メリット無いだろ。
セッションならXSSで取られてもIPで再度チェックすれば大体防げる。

375 :nobodyさん:2006/05/24(水) 17:26:05 ID:???
IPでチェックって言ってる人は
IPが変わる環境のクライアントは切り捨ててるの?

376 :368:2006/05/24(水) 17:35:05 ID:???
可変範囲考えて実装すれば何も問題ない。
ホスト名が取得出来るんだったら、末尾から数えて二つめのドットまでマッチングとかな。
自分はもうちょっと複雑に可変範囲決定してるが、方法はいくらでもあると思われ。

377 :nobodyさん:2006/05/24(水) 18:12:48 ID:???
>>375
携帯サイトのことを言っているのならIPチェック自体がナンセンス
通常のネットワーク環境を前提にしているとしたらIPが変わった時点でセッションが切れて当然

378 :nobodyさん:2006/05/24(水) 18:15:10 ID:???
自分はIP変わった時点ではログアウトさせて無いなぁ。。
苦情来ない?実際自分も不便だと思うからneverにしてる。
クリティカルなやりとりに入る場合は再入力させてるけど。

379 :nobodyさん:2006/05/24(水) 18:15:50 ID:???
>>376
.co.jp ??

>>377
そうなんだ
知らなかった

380 :386:2006/05/24(水) 18:21:45 ID:???
>>379
いや、so-net.netとか。.ne.jpとかは末尾ドット二つじゃ足りなくて三つ遡ってマッチしなきゃならんが。

ヤフやらはてなやらアマゾンはそんな実装だな。>>378
関係ないけど、ヤフの会員登録(HTTP)は生でパス流してる。

381 :nobodyさん:2006/05/24(水) 18:22:17 ID:???
>>378
それ「セッション」じゃないし…

382 :386:2006/05/24(水) 18:23:41 ID:???
更に関係ないけど、ヤフのログインてHTTPが標準なのは勘弁して欲しい。
チャレンジレスポンスだけど、途中に割り込まれたらっつーのもあるし、今時HTTPって。。

383 :nobodyさん:2006/05/24(水) 18:27:30 ID:???
>>381
所謂セッション管理についてのスレだから一行動としてのセッションで捉えなくて良いと思ふ、
つか、今時そんな短時間でログアウトさせてる方が珍しい、金融機関除いて

384 :nobodyさん:2006/05/24(水) 18:32:26 ID:???
>>381
なにがセッションじゃないんだ?

385 :nobodyさん:2006/05/24(水) 18:43:29 ID:???
確かにログアウトまでの時間については悩ましいところ。
セキュリティ的には短い方が望ましいが、長い方が明らかに便利。
あ、良いこと考えた。

386 :386:2006/05/24(水) 18:46:32 ID:???
httpsのリンクをお気に入りに登録させ、毎回ログインさせれば良いじゃん、とか考えたけど、
直接PCを操作される場合のリスクを考えてナカタ。何か良い方法無いですか?

387 :nobodyさん:2006/05/24(水) 19:33:32 ID:???
>>386
質問したいなら
要点をまとめてからにしてくれ

388 :nobodyさん:2006/05/24(水) 23:16:27 ID:vQsxJJUN
$_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)が入っています。

どうしてこのようになるのか分かりません。
どなたか教えていただけないでしょうか。

また期待値を得るためにはどうしたら良いでしょうか?

389 :nobodyさん:2006/05/24(水) 23:54:13 ID:???
>>388
とりあえずAとBのソースを書いてみろ。

390 :388:2006/05/25(木) 00:15:44 ID:wZM3F4wk
>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']);//←ここで値が更新されず、前の値がでることがある。



?>


391 :nobodyさん:2006/05/25(木) 00:57:00 ID:???
>>390
別に問題なく動作したが。。。

動作がおかしいときは、ブラウザがキャッシュから表示してるのだと思う。
session_cache_limiterを弄ったりしてなければ、あまり起きないはずだが、
どうしても以前の情報を表示したくないのなら、
input.phpにランダムなクエリーをつけるか、POSTでアクセスするかかな。

392 :nobodyさん:2006/05/25(木) 00:59:45 ID:???
>>390
それから、本当にキャッシュから表示してるのか確かめたければ、
input.phpに現在時刻の表示とかを入れると良いよ。

393 :388:2006/05/25(木) 08:20:59 ID:???
>>390

どうもありがとうございます。

>input.phpに現在時刻の表示とかを入れると良いよ。
私もこれは試したのですが、
時刻は現在時刻を表示してるのですが
$_SESSIONの値は変わらずといった状態でした。

設定をもう一度見直してみます。
お世話になりました。

394 :nobodyさん:2006/05/25(木) 08:36:41 ID:???
373で質問させてもらいましたが
もしかしたらここの主旨とずれていたかもしれません。
質問用スレッドにて質問させて頂きます。
どうもすみませんでした

395 :nobodyさん:2006/05/25(木) 16:05:42 ID:???
質問ですがユーザ認証の仕組みは
みなさんは自作されてるのでしょうか?
PEAR::Authを使ってるのですが
このスレを読んで心配になりました。
PEAR::Authのログインしたときのクッキーの送受信を
セキュアな接続のときに限定することはできないですよね?


396 :nobodyさん:2006/05/26(金) 22:50:44 ID:???
どうやってセキュアな接続って判定するの?

ブラウザのキャッシュとは限らんよ。
ブラウザに到達するまでに色んな所でキャッシュする装置が挟まってることは良くある。
ファイヤーウォールとか、キャッシュサーバとか、プロクシとか。

397 :nobodyさん:2006/05/26(金) 23:14:34 ID:???
>>396
SSLのことだろ?

398 :nobodyさん:2006/05/28(日) 10:58:28 ID:???
そういえばmixiって、一度ログインしたら、明示的にログアウトしない限り
ずっとログイン状態が続いてるよね。

あれってどうやって実現してるんだろう?(&セキュリティ的に大丈夫か??)

399 :nobodyさん:2006/05/28(日) 11:25:26 ID:???
ソースでも見たら?
一時期流出してたしどこか有るでしょ。

400 :nobodyさん:2006/05/28(日) 14:17:29 ID:???
>>398
たしかにネットカフェとかでmixiにログインして
そのままログアウトし忘れてそのまま帰っちゃうヤツとか多そうで危ないな。

401 :nobodyさん:2006/05/28(日) 22:38:46 ID:???
それは自業自得だからしょうがない。
ネカフェでミクシなんてあり得ないでしょ。

個人情報漏れまくりだ。

402 :nobodyさん:2006/05/28(日) 23:06:01 ID:???
いやぁ、mixiだからこそ十分ありうるぞ。
だってPCに詳しくない女性とかライトユーザが超多いから。

403 :nobodyさん:2006/05/28(日) 23:26:26 ID:???
。。。
「次回から自動的にログイン」のチェックを入れてログインしないと、そんな事にはならないでしょ。
当たり前の実装が普通にしてあったぞ。

404 :nobodyさん:2006/05/29(月) 00:00:21 ID:???
>>403
ハァ??
「次回から自動的にログイン」にチェックを入れなくても
ログインが継続される仕様になってるから>>398のような疑問が出るわけだが。

今、俺が実際に実験してみたところ、「次回から自動的にログイン」をチェックせずに
ログインした状態でパソコンを再起動してもログインが継続されていた。
すなわちネカフェなどでの使用は超危険。

405 :403:2006/05/29(月) 00:11:26 ID:???
それは不思議だな。俺の環境では普通にブラウザ閉じた時点でログアウト。XP SP2+IE6
http://mixi.jp/help.pl#10dこうも書いてあるし、バグレポ送ったらイインジャマイカ。

正直、そんなバグあったら界隈で大騒ぎされているとおもうが。。

406 :nobodyさん:2006/05/29(月) 00:34:08 ID:???
送られてくるCookieを見ると、次回から自動的にログインに
チェック無し
→有効期限無し=セッション限り
チェック有り
→有効期限2011年5月28日

再起動後もログインが継続されるとすると、ブラウザ側に問題があるが、
そういうブラウザがあるなら気をつけた方が良いな。

407 :406:2006/05/29(月) 00:35:03 ID:???
↑はmixiの話です。

408 :nobodyさん:2006/05/29(月) 00:40:42 ID:???
2ちゃんねる系ブログが続々と閉鎖・炎上!
現在進行形で祭り中

資料4(最新版) http://myon.blog.shinobi.jp/Entry/4/

409 :nobodyさん:2006/05/29(月) 08:11:43 ID:???
セッションに詳しくないミクシ住人が、「次回から自動的にログイン」のチェックの危険性なんて理解できる訳ないじゃん。
便利だからって理由で「次回から自動的にログイン」にチェック入れてるでしょ。例え不特定多数が使うPCでも。

410 :nobodyさん:2006/05/29(月) 10:09:07 ID:???
そもそも外ならたいてい携帯使うんじゃない?

411 :nobodyさん:2006/05/29(月) 19:46:17 ID:???
>>402
俺もIE6なんだが、、、バグだろうか??
「自動ログイン」にチェック入れなくても、
ブラウザ閉じようがPC再起動しようが、ログイン状態が継続されてるよorz

みんなそうだと思ってたら、俺だけなのか・・・

412 :nobodyさん:2006/05/29(月) 19:47:17 ID:???

ごめ、>>402じゃなくて>>405へのレス。

413 :nobodyさん:2006/05/29(月) 21:43:17 ID:???
今、自分mixiのクッキーを調べてみた。
「自動ログイン」のチェック無しでログインすると
「BF_SETTING」って項目とデータ7行。

「自動ログインあり」だと、「BF_SETTING」に加えて、
「BF_SESSION」と「BF_STAMP」ってのが追加されるみたいだね。

414 :nobodyさん:2006/05/29(月) 23:14:23 ID:???
>>411
チェック外しても昔送ったクッキーを生かしたままにしてあるとか?

415 :nobodyさん:2006/05/29(月) 23:26:21 ID:???
>>414
少なくとも、ログイン画面を見ているときはクッキーが切れてる。

416 :nobodyさん:2006/05/30(火) 01:55:58 ID:???
>>414
どうやって生かしたままにするの??

417 :nobodyさん:2006/05/30(火) 08:23:17 ID:???
むしろログアウト判定のクッキー喰わせてる訳か。ダサイ設計だ。
ログアウトしてるのに、クッキー消したら認証突破できるんじゃね?

418 :nobodyさん:2006/05/30(火) 09:43:25 ID:???
>>417
ん? 何を見当違いのこと言ってんだ?
「ログアウト判定のクッキー喰わせてる」って、何を根拠に言ってんだか・・・

419 :nobodyさん:2006/05/30(火) 10:56:22 ID:???
>>417
ログアウトは、有効期限切れのクッキーを送ってる。
つまり、クッキーを削除するのに通常使われる方法だぞ。

420 :nobodyさん:2006/05/30(火) 19:30:57 ID:???
>>419
だよね。

421 :nobodyさん:2006/05/30(火) 20:39:32 ID:???
D A Y O N E

422 :nobodyさん:2006/05/30(火) 22:36:56 ID:???
SO YA NA

423 :nobodyさん:2006/05/31(水) 12:02:25 ID:???
DA YO NA

424 :nobodyさん:2006/05/31(水) 12:57:55 ID:???
O YO NE

425 :nobodyさん:2006/05/31(水) 14:17:24 ID:???
O YO YO

426 :nobodyさん:2006/05/31(水) 15:24:58 ID:???
「だよねー」はねーよ だ!

427 :nobodyさん:2006/05/31(水) 16:23:12 ID:???
バーローwwwwwwwwwwww


428 :nobodyさん:2006/05/31(水) 22:07:23 ID:???
    _, ._
  ( ・ω・)  
  ○={=}〇,
   |:::::::::\, ', ´
.wwし w`(.@)wwww


429 :nobodyさん:2006/07/01(土) 04:01:59 ID:???
あるwebアプリの開発を引き継いでるんだけど、検索結果とか一覧で同じ表示形式(ページングとカラムごとのソート機能付き)を共通で使いたい。
なおかつ、結果と、ソート状態、何ページ目は、他のページを開いても戻って来た時保持したい。
いちいちGETやPOSTからsqlクエリを毎度生成するのはめんどくさ過ぎるから、
検索条件が投げられた時点でsql文をつくって、まるごとセッションにぶち込む。URLにGETに含めるのは現在何ページ目、ソート対象、ソート方向、表示件数だけにしてしおうかと思ってるけど、こういうのはありなのかな?

430 :nobodyさん:2006/07/01(土) 08:44:44 ID:???
>>429
2枚ウインドウを開いて違う検索しようとしたら、一方の検索条件が両方に適用されて
まともに使えないサイトがあった。
ウインドウ毎に区別されるようにしてね

431 :nobodyさん:2006/07/01(土) 10:15:18 ID:???
>>430
暫く前の@type(転職サイト)がそう。最悪の使い心地だった。
今は他社同種のと同程度には改良されてるけど。

432 :nobodyさん:2006/07/01(土) 16:27:38 ID:???
>>430-431
なるほど。そういう弊害もあるのか。
いい事聞いた。ありがと。
やはり自分で想定できることってかぎられてるんだなと。
だったら新たに窓を開いたら窓ごとに別のセッションネームをつけてsql文を格納すればよさそうですね。
表示部分の関数がsql文をわたす設計で、結果からのリンクはすべてget渡しなんで、関数内でsql文を生成するとおそろしく面倒なことになりそうだ。

433 :432:2006/07/04(火) 11:39:42 ID:???
使い回ししやすいように関数化して、ダブらないように独自のセッションネームを吐くようにしてるけど、けっこう苦戦中。
でもこれが完成したらすげー楽になるかも。

434 :nobodyさん:2006/07/04(火) 19:13:45 ID:???
ガンガレ

435 :432:2006/07/04(火) 22:41:35 ID:???
だめだ。検索掛けるときにgetで投げるときもあれば、postでやるときもあるし、selectのonchangeつかって同時にget投げるときもある。
全ての入力を統合するのは、やっぱり無理っぽいかも。もう限界に近づいて来たというのに、ひどい状態になってしまったorz
コメントアウトだらけで自分でもわけわからん、

436 :nobodyさん:2006/07/05(水) 03:10:54 ID:???
一方ロシアはSQLをその都度生成していた

437 :nobodyさん:2006/07/05(水) 08:45:55 ID:???
おそロシア

438 :nobodyさん:2006/07/11(火) 09:18:37 ID:3lRF8+ba
会員制サイトのログイン状態の保持にセッションを使ってるのですが
アイドル状態が続くとセッションが切れてしまうのを
回避する方法を考えています。

・ サーバでのセッション保持期間を長くする
・ セッションでなくクッキーなどによる管理に変更する

これ以外になにかいい方法があったら教えてください

439 :nobodyさん:2006/07/11(火) 09:21:58 ID:???
>>438
普通に考えたらクッキーだよな。

面白い方法だと、例えば幅無しのフレーム作って、そっちのフレームの中を<META>タグで
何秒か置きに更新させて、その中でセッションを更新させてやるとか。
↑まぁこんな事やる意味が分からないけどね(w

440 :438:2006/07/11(火) 13:01:04 ID:???
>>439
フレームはちょっと考えてました。
あとはFlashとかで定期的に通信するとか。
でも最後の手段と考えてます。

クッキーの場合は、パスワードも暗号化したクッキーとして
クライアントに返して
毎回そのクッキーで認証するって感じでしょうか?


441 :nobodyさん:2006/07/11(火) 14:00:39 ID:???
>>440
「毎回」の意味が不明だけど。
認証に通ったらワンタイムパスワードを発行。

442 :nobodyさん:2006/07/11(火) 14:59:31 ID:???
セッション保持はメモり喰うし、メモリリークが発生しやすい。
クッキーやワンタイムパスワードは総当たり攻撃で突破される。

そもそもHTTPなんてステートレスなプロトコルでセッションが切れるのは仕様。
SOAPとかCORBAとか他のプロトコル使ったら?

443 :nobodyさん:2006/07/12(水) 02:04:51 ID:???
>>438
>アイドル状態が続くとセッションが切れてしまう

session.cookie_lifetimeが「0」なら、
ブラウザを閉じない限りセッションも切れないだろ。
しかもそれってデフォルト設定だし。

444 :nobodyさん:2006/07/12(水) 10:11:09 ID:???
>>443
サーバ側は削除されるだろ?

445 :nobodyさん:2006/07/12(水) 13:24:04 ID:???
>>444
削除されないよ。
実際自分のとこで動かしてるスクリプトは、
一度ログインしたらブラウザ閉じるまで何日でもログイン状態(=セッション)続いてるし。

446 :nobodyさん:2006/07/12(水) 13:41:31 ID:???
ブラウザがセッション切る場合もあるし、間に入ったNATやプロクシが切る場合も有る。

何日もログインできるってメモリリークしまくりに気づいてないだけじゃ?

447 :nobodyさん:2006/07/12(水) 15:45:38 ID:???
>>446
お前が>>442で書いてることは間違い。
セッションはファイル(またはDB)で管理されるものであり、
メモリとは直接関係ない。したがってメモリリークなど起きない。

悔しかったら具体的にどういう根拠でメモリリークが発生するか書いてみたまえw

448 :nobodyさん:2006/07/12(水) 23:04:56 ID:???
>>445
他にアクセスがなければ削除されないでしょ

自分しか使わないシステム?

449 :nobodyさん:2006/07/13(木) 09:31:31 ID:???
PHPのデフォのセッションの場合、
セッション管理はセッションIDをベースファイルネームにしたファイルベースで行われてて、
セッションIDに対応したファイルがあるかないかだけの話だと思うのだけど、
そこに一体どういう原理でメモリリークが発生するの????


450 :nobodyさん:2006/07/13(木) 13:03:32 ID:???
>>448
ガーベッジコレクションの動作についてよく勉強したまえ。
gcは、「ガーベッジ」となっていないものまでは回収しない。

451 :nobodyさん:2006/07/13(木) 13:36:25 ID:???
>>442
>セッション保持はメモり喰うし、メモリリークが発生しやすい

アタマ大丈夫??

452 :あい:2006/07/13(木) 15:17:21 ID:se0YFGaK
sessionについて教えてください!

453 :nobodyさん:2006/07/13(木) 19:25:58 ID:???
総当たり攻撃で突破できる弱いユーザ管理です。

ファイルでもDBでもセッションが多数に成ればその分だけメモリの使用量が増えて、解放されないメモリが増えるよ。
事実上メモりリークしてメモリの再活用や再割当が出来なくなる。回収しないのではなくて回収できないメモリが増えていくのがメモリリーク。


454 :nobodyさん:2006/07/13(木) 20:38:13 ID:???
セッションの保持にメモリが使用されるのはコンパイルオプション付けたときだけだろ。
メモリを使用したときでも、きちんと解放がセッション保持のプロセスに含まれてるしメモリリークするとは考えられないが。

455 :nobodyさん:2006/07/13(木) 22:45:45 ID:???
>>453
>ファイルでもDBでもセッションが多数に成ればその分だけメモリの使用量が増えて

↑こいつキチガイだなwww

なんでセッションファイルの数が多いとメモリ使用量が増えるんだよw
そしたらセッション以外にもスクリプト自身とか、さまざまファイルが
多ければ多いほどメモリリークが発生する…って理屈になるなww

456 :nobodyさん:2006/07/14(金) 10:42:22 ID:???
ファイルハンドルでメモリ喰うから。プログラムやったこと無いの?

457 :nobodyさん:2006/07/14(金) 11:06:20 ID:???
>>456
だから食わねぇっつーの。
そんなに自説を主張したかったらソース出せソースを。
誰がどこでそんな珍説を広めてんだ?

458 :nobodyさん:2006/07/14(金) 11:42:37 ID:???
>>456はおそらく、C言語を中途半端にかじったヤツである悪寒。

で、PHPの自動メモリ解放機能とかを知らずに、
最近覚えた「メモリリーク」という言葉を連呼したくてたまらない厨房なのでは??

まあ、何にせよセッション・ファイルとメモリリークとは関係ない話なんだけどね。

459 :nobodyさん:2006/07/14(金) 16:28:29 ID:???
馬鹿だなあ。
10万セッションのサイトでは、10万セッション分のファイルハンドルが必要なんだよ。
十分メモり喰うし、長時間セッション使ってるとメモリリークも起きる。

460 :nobodyさん:2006/07/14(金) 18:25:44 ID:???
>>459
10万セッションも必要なサイトの管理者はこんなスレ来ねぇよバカ。

っていうか10万セッションもあったらファイルハンドラじゃ無理があるからDB使うし、
そもそもサーバ1台じゃなくて複数台に分散するんだよクズ。

461 :nobodyさん:2006/07/14(金) 23:07:11 ID:???
愛のメモリリーク

462 :nobodyさん:2006/07/14(金) 23:48:16 ID:???
っていうか10万セッションをファイル使って、
しかも負荷分散しないでやってたら(やれるとしたら)、
そもそもメモリリーク以前にもっと別の問題が起きると
思うけどなww

463 :nobodyさん:2006/07/15(土) 00:26:38 ID:???
>>459
もう少し勉強したら自分がキチガイなこと言ってるって分かるよ。

464 :nobodyさん:2006/07/15(土) 01:04:45 ID:???
>>459は、まれにみるバ(以下略

465 :nobodyさん:2006/07/16(日) 09:00:01 ID:???
>>459はセッション処理の為に開かれたファイルは、そのまま開かれているものとして語っているみたいだな。
恥さらしもその辺にしとけよ(w


466 :nobodyさん:2006/07/16(日) 10:37:13 ID:???
つまりセッションは大規模サイトでは無理ってことですね。

467 :nobodyさん:2006/07/16(日) 13:34:14 ID:???
>>466
だから何を見当違いのことを言ってんだ、おまいは。
もしやおまいは>>459>>456か??

468 :nobodyさん:2006/07/17(月) 04:55:48 ID:???
phpで10万セッション自体があり得ない。
その前にメモリ喰いまくりで太ったアパッチごとkillされる。

469 :nobodyさん:2006/07/17(月) 09:19:18 ID:???
〃∩ ∧ ∧
⊂⌒( ・ω・)  はいはいわろすわろす
 `ヽ_っ⌒/⌒c
    ⌒ ⌒

470 :nobodyさん:2006/07/18(火) 01:12:16 ID:???
大丈夫。リナクスの場合は10万セッションも接続北来た瞬間再起動するから(w
2003鯖を使ってる漏れは勝ち組。

471 :nobodyさん:2006/07/18(火) 10:40:48 ID:???
>>465がトドメという感じだが、流石にもう食い下がってはこないか??

472 :nobodyさん:2006/07/18(火) 13:45:02 ID:???
しっかし、「セッションでメモリリーク」なんて珍説、はじめて聞いたよww

473 :nobodyさん:2006/07/18(火) 14:14:20 ID:???
メモリリークしないって思い込みって、バグは無いって思い込みで出荷しちゃったシンドラエレベータの殺人プログラマ並みに馬鹿だな。
人氏んでるんやで。プログラムぐらいまともに組め。

474 :nobodyさん:2006/07/18(火) 15:06:36 ID:???
詭弁の見本市みたいになってきたな。

475 :nobodyさん:2006/07/18(火) 17:17:25 ID:???
>>473
だからメモリリークが発生するというのなら、
具体的な根拠や発生機序を示せよ。

476 :nobodyさん:2006/07/19(水) 03:06:06 ID:???
港区のエレベータで死亡事故。
上昇直前に開ボタンを押すとメモリリークが発生して死亡事故が起きる。

477 :nobodyさん:2006/07/19(水) 03:15:59 ID:???
メモリリークするって思い込みって、バグは無いって思い込みで出荷しちゃったシンドラエレベータの殺人プログラマ並みに馬鹿だな。
人氏んでるんやで。プログラムぐらいまともに組め。

478 :nobodyさん:2006/07/19(水) 03:18:08 ID:???
セッションといえばWeb製作板の携帯スレで暴れてた馬鹿が居たが、同一人物っぽい香りがするな(w


479 :nobodyさん:2006/07/19(水) 09:14:38 ID:???
> メモリリークが発生して死亡事故が起きる。
おめでたい思考回路ですね。

480 :nobodyさん:2006/07/19(水) 09:24:01 ID:???
他人に何を言われても引き下がらない
とても漢らしい生き方だと思いました

481 :nobodyさん:2006/07/19(水) 11:23:40 ID:???
往生際が悪い の間違いだろ(w

482 :nobodyさん:2006/07/19(水) 14:01:34 ID:???
メモリリークは発生するってことでおk?

483 :nobodyさん:2006/07/19(水) 15:31:59 ID:???
テポドン2の発射もメモリリークが原因! とか言い出しかねないなwww

484 :nobodyさん:2006/07/19(水) 16:58:02 ID:???
ハワイまで到達できなかったのはメモリリークでしょ。

485 :nobodyさん:2006/07/20(木) 01:22:24 ID:???
セッションによるメモリリークの存在を強硬に主張しているが、
いまだに具体例や証拠が一切出されていないのが笑えるw

486 :nobodyさん:2006/07/20(木) 10:56:20 ID:???
メモリリークの存在を必死に否定しているが、10万セッション達成の具体例や証拠が一切出されていないのが笑える。

487 :nobodyさん:2006/07/20(木) 12:56:36 ID:???
今なら言える。




必死だな(w

488 :nobodyさん:2006/07/21(金) 06:32:39 ID:???
>>486=バカ

ヒント;>>460,>>462,>>468

489 :nobodyさん:2006/07/21(金) 23:44:57 ID:???
メモリリークの意味を知らないか、PHPがステートレスだと言うこと自体知らないんだろ。

490 :nobodyさん:2006/07/23(日) 01:17:39 ID:???
メモリリーク厨のオモシロ回答まだぁ〜〜??ww

491 :nobodyさん:2006/07/26(水) 12:00:14 ID:???
>>444-450
これってどういうこと?
ブラウザが閉じられるまでgcが発生しないようになんて
できないよね?
そんな方法があるなら知りたい。

gc_maxlifetimeを1年ぐらいに設定するとかはなしでw


492 :nobodyさん:2006/07/27(木) 09:05:35 ID:???
>>491
ない
445が間違えてるだけ

493 :nobodyさん:2006/07/28(金) 07:54:27 ID:???
>>491-492
んなこたぁないだろう。
そしたら「ブラウザ閉じない限りはずっとログインし続けたまま」の
システムを作ることが不可能になるじゃんか。

494 :nobodyさん:2006/07/28(金) 08:04:14 ID:???
つーか、session.gc_maxlifetimeって、
一体どのタイミングからカウントされた秒数なの?

最初のアクセスか、それとも最後のアクセスか・・・

495 :nobodyさん:2006/07/28(金) 08:42:49 ID:???
>>493
不可能だし

>>494
まず試せ

496 :nobodyさん:2006/07/28(金) 09:24:42 ID:???
>>494-495
まずググれ。
が,正解かと。

497 :nobodyさん:2006/07/28(金) 14:19:59 ID:???
>>495
不可能じゃないよ。
だってmixiとか、ブラウザ閉じなければ何日でもずっと
ログイン状態が継続してるし。

498 :nobodyさん:2006/07/28(金) 16:48:36 ID:???
>>497
それ、セッションじゃなくて、クッキーにユーザー名とか保存してるだけじゃ無いの?
セッション何日も維持するなんて、セキュリティ上あり得んよ。

クッキーに何を保存してるか、見てみれば?

499 :nobodyさん:2006/07/28(金) 18:55:06 ID:???
mixiはブラウザ閉じても次アクセスすればログイン状態では?
ちなみにクッキーは3個。すべてセッションオンリーはNO、有効期限は5年。

クッキーにユーザー名とか保存はしてない。直接の値が書き込まれているのは表示設定のみ。
ていうかそっちの方がセキュリティ上問題あるだろう

500 :nobodyさん:2006/07/28(金) 20:37:40 ID:???
>>498
mixiのクッキーにはユーザー名(メアド)は書いてないよ。

>>499
>セッションオンリーはNO
↑これどういう意味??

>mixiはブラウザ閉じても次アクセスすればログイン状態では?
「次回から自動ログインする」にチェックを入れてログインしたなら、ね。

501 :nobodyさん:2006/07/28(金) 21:47:39 ID:???
>>500
>セッションオンリー
ブラウザを終了したらクッキーを破棄するかどうか(これがオンだと有効期限は設定されない)

「次回から自動ログインする」にチェックしたらセッションオンリー=オフで有効期限5年のクッキー
チェックしなかったらセッションオンリー=オンのクッキー
という使い分けみたいですね。

502 :nobodyさん:2006/07/28(金) 22:13:32 ID:???
>>501
あれっ、mixiのクッキー内にそんなデータあった??
俺見てみたけど、見当たらないぞ・・・

っていうか「BF_STAMP」って何を指してるんだろう? BFが何の略なのかも気になる。

503 :nobodyさん:2006/07/28(金) 23:41:45 ID:???
>>501
言いたいことは分からないでもないが
セッションオンリー
って言葉はどうなの?

>>502
独自のセッションを実装してるみたいだね
ワンタイムパスワードみたいなのを3つくらい返してる
mixiって同じIDで別の端末からも利用できるの?
できるんならサーバ側の情報管理はたいへんそうだな


504 :nobodyさん:2006/07/29(土) 02:55:05 ID:???
>>503
たしかにワンタイムパスワードみたいなのがあるね。
でも何回かログインとログアウトを繰り返してみたところ、
そのワンタイムパスワードみたいなのは変化しなかった。
ってことは「ワンタイム」じゃない!?

505 :nobodyさん:2006/07/29(土) 09:11:18 ID:???
>>504
ってことはmd5とかで変換しただけのものを
クッキーに保存して毎回アクセスするたびに認証してるだけだね
セッションじゃないじゃん

一番確実な方法だと思うが
セキュリティ的にはhttpsでもないしだめだと思う


506 :nobodyさん:2006/07/29(土) 11:57:07 ID:???
気になったからみてみた>mixi

BF_SESSION
が 999_jidjaijdiojaidjhifjaj1399
みたいになってて先頭の数字が会員IDで後ろは
会員に対するランダムな文字列
(ってことで会員IDもかかれてるよ)

BF_STAMP
がパスワードになにかしたもの。
(パスワードを変更すると変化する)

BF_LOCAL_SESSION
が一時的なセッション管理用っぽい。

認証はCOOKIE(BF_SESSIONとSTAMP)で管理して
一時的なセッション情報(すぐに消えてもいいもの)を
BF_LOCAL_SESSIONのほうでやってると思われ。

ちなみに BF_ がなんの略かは分からない。


507 :nobodyさん:2006/07/29(土) 12:17:15 ID:???
BFはmixiのコアライブラリBoofyのことやろね。
以前フロントエンドのソースコード流出で話題になってた。

508 :nobodyさん:2006/07/29(土) 13:13:55 ID:???
mixiは招待無しで参加できないの?

509 :nobodyさん:2006/07/29(土) 13:30:05 ID:???
無理

510 :nobodyさん:2006/07/29(土) 13:37:05 ID:???
そこをなんとか

511 :nobodyさん:2006/07/29(土) 15:33:58 ID:???
>>506が神に一歩近づきました。

mixiはDBもロードバランスしてたりするから、
セッション管理とかもやたら複雑なんだろうなぁ。。。

もっと小規模のSNSだったなら、そこまで複雑なCOOKIEにならないで済むのかな?
たとえばOpenPNEとか。使ったことないけど。

512 :nobodyさん:2006/07/29(土) 22:34:06 ID:???
>>511
> >>506が神に一歩近づきました。
> mixiはDBもロードバランスしてたりするから、
> セッション管理とかもやたら複雑なんだろうなぁ。。。
レイヤ7スイッチなら関係なし

513 :nobodyさん:2006/07/29(土) 23:50:54 ID:???
通常完全ランダムなハッシュを一つクッキーに入れるのが一番良いんだと思うんだけど、
なんかmixiは色々と入れてるんだね。しかも会員情報と関係する物を。

514 :nobodyさん:2006/07/30(日) 00:07:51 ID:???
>>513
完全ランダムなハッシュ?
どうやって認証するの?
セッション使うってこと?


515 :513:2006/07/30(日) 00:19:58 ID:???
ログイン時にランダムなハッシュをクッキーとして渡して、鯖側でユーザと結びつけて管理。
いや、別に変わった事言ったわけではないっす。セキュリティを確保する為の問題はそこからだよね。。

516 :nobodyさん:2006/07/30(日) 10:32:58 ID:???
っていうか普通そうすると思うが

517 :nobodyさん:2006/07/30(日) 12:19:56 ID:???
その普通が出来ていないサイトがなんと多いことか・・・
man in the middleを考えるならSecure発行も必須だな。

518 :nobodyさん:2006/07/30(日) 14:03:10 ID:???
>>515
> ログイン時にランダムなハッシュをクッキーとして渡して、鯖側でユーザと結びつけて管理。

sessionと何が違うんだ?

519 :nobodyさん:2006/07/30(日) 14:28:40 ID:???
セッションを語るスレなのにPHPに標準実装されてるセッションをただ"セッション"というのは紛らわシス
ブラウザをIEの同義語で使うのと同レベル

520 :nobodyさん:2006/07/30(日) 16:57:26 ID:???
>>518
sessionid 以外にハッシュを渡して
認証済みチェックをやるってことだろ

>>519
???

521 :nobodyさん:2006/07/30(日) 17:04:19 ID:???
セッションを実装するには、何もPHPで標準で用意されてるセッションを使わなくてもいいよ
って事が言いたいのでは?違うか??

522 :nobodyさん:2006/07/31(月) 03:14:10 ID:???
>>520
PHPのセッション関数によって発行されたセッションIDをクッキーに渡すんじゃダメなの?
>>518も書いてるが、セッションIDとは別にわざわざハッシュ値を用意する意味がよく分からない。

523 :nobodyさん:2006/07/31(月) 04:58:39 ID:???
CookieをSecureにすると負荷で死ぬから、うちでは自前でセッションハイジャック対策やってるんだが、
そうなると確かにsessionは使えないな。常にSSL使える環境なら標準のでいいんじゃね?

524 :nobodyさん:2006/07/31(月) 15:31:17 ID:???
>>523
>自前でセッションハイジャック対策やってるんだが、
>そうなると確かにsessionは使えない

どうして??

525 :523:2006/07/31(月) 23:55:35 ID:???
対策としてログイン時のホストとUserAgentをセッションと結びつけてる。
これをsessionでやろうとすると結果的にハッシュが二重に保存される上に処理にロスが出る。

526 :nobodyさん:2006/08/01(火) 04:10:24 ID:???
>>525
言ってる意味がわからん。
なんか無駄に難しく考えてないか?

527 :nobodyさん:2006/08/01(火) 04:31:43 ID:???
https使わない馬鹿なんていないから大丈夫。

528 :nobodyさん:2006/08/01(火) 05:39:58 ID:???
そろそろセッションはPHPが普及する前からあるときがついてくだしあ。

529 :nobodyさん:2006/08/01(火) 07:18:30 ID:???
>>525
それを実装したいなら、セッション変数にホストとUA入れればいいじゃん。
ただし、既出のように、それだけではセッションハイジャックを完全には防げないし、
ホスト(IPアドレス)がHTTP接続ごとに変わる環境のやつが利用できなくなる罠。

530 :525:2006/08/01(火) 08:56:31 ID:???
>>529
ごめん。書き忘れてたんだけど、
複数のアクセスポイントからアクセスする人もいるから、
一つのユーザに複数のセッションを割り当てて管理してます。
その過程でIDと複数のセッションを関連づけてるんだけど、
sessionだとIDからセッションの逆引きが出来ないので。。
ちなみに、ホストが変わるのは適度にマッチングして対応しています。

ところでNonSSLでセッションハイジャックを完全に防ぐ方法ってあるかな?
無理だよね。。まぁ、SSL使えって話しなんだろうけど。

531 :nobodyさん:2006/08/01(火) 09:10:48 ID:???
>>530
SSLでも完全には防げないし

532 :525:2006/08/01(火) 09:18:07 ID:???
物理的アクセスとかウィルスはやめてください><
そういや、ny系のウィルスでCookieやらをzipにして流すのがありましたね。

533 :nobodyさん:2006/08/01(火) 10:44:03 ID:???
>>530
っていうかSSLは通信内容を暗号化するだけで、
セッションハイジャックを防ぐ手段とは関係ないわけだが。

534 :525:2006/08/01(火) 10:58:20 ID:???
いやー、そりゃねーだろー。
不安になって確認しちまったじゃんか。ぐぐればざくざく出てきますぜ。

535 :nobodyさん:2006/08/01(火) 11:28:28 ID:???
じゃそういうことで。

536 :nobodyさん:2006/08/01(火) 11:40:56 ID:???
誰か533を俺にも分かるように解説してくれ

537 :nobodyさん:2006/08/01(火) 12:04:03 ID:???
>>536
ぐぐればざくざく出てきますぜ

538 :nobodyさん:2006/08/01(火) 17:01:25 ID:???
そんなセッションな、

539 :nobodyさん:2006/08/02(水) 03:45:11 ID:???
というか、ログイン認証時以外にも常にHTTPSで通信するなんて
実用的には無理があるよな。

mixiみたいに、認証時以外はHTTPにするしかないだろ。
負荷やレスポンスなどを考えると。

540 :nobodyさん:2006/08/02(水) 04:30:58 ID:???
mixiはセッション管理的にアレだけどな。
重要な情報をやりとりするとき以外はhttpでいいんじゃね。
YahooもBiddersも楽天だってAmazonだってそうしてるし。
鯖側よりクライアントに負荷の比重を置くセキュアプロトコルが欲しいところだな。

541 :nobodyさん:2006/08/02(水) 10:40:13 ID:???
https通信時にどういうやり取りが行われてるか見ればわかると思うが、
負荷を考えるのであれば全てをhttpsでやろうとするのはナンセンスだよな。
1日10アクセスぐらいのサイトなら好きにすりゃいいけど(w

542 :nobodyさん:2006/08/02(水) 10:59:10 ID:???
会員専用以外のとこで
すべてをhttpsでやってるとこなんてあるの?


543 :nobodyさん:2006/08/02(水) 14:11:39 ID:???
ないだろw

544 :nobodyさん:2006/08/03(木) 03:05:25 ID:???
っていうかさぁ、みんな「セキュリティ、セキュリティ・・・」って念仏のように唱えてるけど、
実際にSSLを使わずに重要情報をスニファされた事件って、実例あるの?
そんなもん、いまだに聞いたことないんだが。



545 :nobodyさん:2006/08/03(木) 05:30:21 ID:???
泥棒に入られたことなくても、家に鍵かけるだろ?

546 :nobodyさん:2006/08/03(木) 09:38:22 ID:???
>>545
実際には存在しない「架空の泥棒」を生み出して大騒ぎし、
人々の恐怖心を煽って大儲けしているヤツらがいることに少しは気付こう。
だからキミらはいつまで経っても搾取され続けるんだよ。バカだから。

そんなキミらは映画『ボウリング・フォー・コロンバイン』でも見ると良い。

547 :nobodyさん:2006/08/03(木) 10:26:30 ID:???
まぁ、プロと素人の意識の差だね。
素人の趣味でやるなら好きにすりゃいい。

548 :nobodyさん:2006/08/03(木) 10:39:54 ID:???
>>547
論点のすり替え乙。

意識だのプロだの関係ない。
ただ単に想像の産物で騒いでるお前みたいなバカのことを笑ってるだけだよ。

549 :nobodyさん:2006/08/03(木) 10:52:07 ID:???
セッションでメモリリークの次はこんな話題かw
本当レベル低いよな。

550 :nobodyさん:2006/08/03(木) 18:52:15 ID:???
そもそもSSLの是非を問うスレじゃないんだが…

551 :nobodyさん:2006/08/03(木) 21:29:13 ID:???
よくある夏の風物詩

552 :nobodyさん:2006/08/04(金) 00:27:39 ID:???
>>544
会社でなら

553 :nobodyさん:2006/08/04(金) 02:33:39 ID:???
たしかにSQLインジェクションとかXSSとかが原因の事件はよくニュースになるけど、
SSLを使用しないせいでパケットスニファされた事件なんて記憶にないな。

誰か実例知ってる?

554 :nobodyさん:2006/08/04(金) 02:42:38 ID:???
過疎ってるSSLのスレがあるからそっちでやれ

SSLの使い方
http://pc8.2ch.net/test/read.cgi/php/1016169881/

555 :nobodyさん:2006/08/04(金) 03:24:34 ID:???
別に去る者追わずの個人サイトならそれでいいんじゃね。
ユーザの事考えなくても良い素人ならね。

556 :nobodyさん:2006/08/04(金) 09:33:12 ID:???
>>555
何回もクドクドとウゼェなぁ。「素人、素人」って、お前は何様なんだボケ。
つーか歯車リーマンが何を偉そうに語ってんだバカが。

悔しかったら早くスニファが原因での情報漏洩事件を挙げてみろカス。

557 :nobodyさん:2006/08/04(金) 09:45:01 ID:???
同一ネットワークでARPが届く範囲ならフニファできるけど
それ以外だと無理だとおもわれ。ルータでARPがクッションされるから。

558 :nobodyさん:2006/08/04(金) 13:38:11 ID:???
>>556
獲得できるユーザが少なくなったり評判が悪くなるって言ってるんだよ。白書読め。
キミはユーザにそう説明してれば良いんじゃない?

559 :nobodyさん:2006/08/04(金) 18:57:12 ID:???
>>558
言い訳は要らないから、早く実例出せよ。

SQLインジェクションやXSSでの被害実例は豊富にある。
だからその対策を講じるのは合理的な理由がある。

しかしSSLを使用しなかったことによるスニファでの被害実例は、少なくとも俺は知らない。
まさかお前、実際にはありもしない不安を煽って、客から高い金取ってるんじゃないだろうな?
そういうのを詐欺とかボッタクリと呼ぶんだぜ。

560 :nobodyさん:2006/08/04(金) 19:02:25 ID:???
UZEEEE
勝手にベリサインにでも電凸でもしてSSLサイトでも作ってろ
いつまでスレ違いネタ続ける気だ死ね

561 :nobodyさん:2006/08/04(金) 19:04:12 ID:???
まちげぇた
SSLサイト→SSL叩きサイト
掲示板のルールすら守れないやつが正義漢振るな
ゴミが

562 :nobodyさん:2006/08/04(金) 19:42:52 ID:???
>>559
まさかここまで言っても分からない馬鹿だとは思わなかった。
被害がある被害がないは関係ないんだよ。ユーザがそれを気にしているかどうか。SSLを使用しているかどうかをチェックするユーザがいる事実、これだけが大事。
XSS、インジェクション、それらの対策がなされているかチェックしてからサイトを使うユーザが何処にいる?
それに対しSSLのチェックは簡単で、大きくメディアにも取り上げられている。また、上にも挙げたとおりいくつかの白書に載っている統計にもユーザがそれらを判断基準にしているとの統計が出ている。
お前みたいなユーザ数を気にする必要のない素人には関係ないがな。ユーザ数獲得を目的とする"プロ"の"SSL使用"の何処が非合理なんだか。

セキュリティよりもお前は自分の馬鹿さ加減を気にした方が良いな。

563 :nobodyさん:2006/08/04(金) 19:59:46 ID:???
これ以上エサを与えんなよ
空気読まない質問に答えてやってもいい相手は小さい子供だけだ

564 :nobodyさん:2006/08/04(金) 20:56:55 ID:???
だから素人は好きにやっとけって事でFAで終了

いつまでやってんだか。。。

565 :nobodyさん:2006/08/04(金) 23:02:49 ID:???
セッションで呼び出す毎にハッシュ変更する機能付けるのってどうやってやるんだっけ?
何処かで見たような気がするんだけど思い出せん

566 :nobodyさん:2006/08/04(金) 23:14:01 ID:???
>>565
session_start();
session_regenerate_id();

こゆこと?

567 :nobodyさん:2006/08/05(土) 03:45:03 ID:???
>>562
いやぁ、スゴい論点ずらしの逃げだね。見事な負け犬っぷりだwww
お前みたいな馬鹿システム屋がいるせいで、ますますド素人の客やユーザーたちは
「SSLさえあれば安全!」みたいな間違った認識を増大させ、
もっと重要かつ事件が頻発している穴をふさぐための費用を出そうとしない。


それからユーザ数獲得云々とか、お前の論理なんてどうでもいいわけ。そんなの誰も聞いてないだろ。
そうじゃなくて「SSLが無い場合の危険度=過去に起きた被害実例」を挙げてみろよ、って言ってんの。
もしユーザからそれを質問されたらどう答えんの? あ?

お前の論理でいくと、「ユーザ数獲得を目的とするプロ」なら、上記の質問には答えて然るべきだよなぁwww

568 :nobodyさん:2006/08/05(土) 04:17:59 ID:???
ユーザは使用者、君が言ってるのはクライアント。ユーザはわざわざSSLが無いサイトを選んだりしません。
在日の君にはまず日本語を覚えて貰わないと話しにならないなぁ。
しかも、>>555に最初にレスしてきたのは君でしょ。それがルートレスになってるんだからそのレスに基づいて話すのは当たり前。論点をずらさないで欲しいね。

まぁ、君の質問にも答えてあげると、情報の盗聴というごくごく受動的な行為は被害を受けたと認識する事は出来ないってこと。
被害実例?気づいてないんだから少ないのは当たり前。普段と何ら変わりないのにどうやって気づく?個人情報漏洩した企業の"情報の悪用は確認できない。"という言い訳と同じ。
その前に君はなぜベリサインなどの企業が成り立っているか考えるべき。受動的攻撃の検知に疎いのは良いとして、こちらは世間一般で分かる常識だ。
"間違った認識をする奴がいるから"ベリサインは成り立つ。そんなはずがないだろう。もう少し謙虚に生きた方が多くのことを学べるよ。

569 :nobodyさん:2006/08/05(土) 05:07:23 ID:???
長文は読む気も書く気もしないので。

ま、クレジットカード番号送るのに、SSLも使ってないサイトを使いますか?って事だ。
で、素人は好きにやっとけって事でFAで終了。他所いってやってくれ。

570 :nobodyさん:2006/08/05(土) 05:29:11 ID:???
きっと考えが営業的なんだと思うよ。
お金を投入して、それに見合う効果があるのかどうかという話。

観測できない被害は、あったとしても気づいていなければ、会計的に被害額を算出不能なので被害に遭ってないのとのと同じ。
また、その観測できない被害を被るのは、多くの場合サイトの運営側でなく利用者の側なので被害を受けるとみなさないとする向きもあるかと思う。
そういう考え方は賛同はできないけれど、「あり」な考えかたの一つだと思う。

利用者から安全でないと思われ、最初から利用を控えられるということによる損失。
情報流出の被害が発覚した場合の信用失墜による損失。
こういったものを軽く見積りすぎているように思います。

もちろん、被害が発覚して問題になったときの対応にかかるコストも含めて、事後対応のほうがコストが安いと思うならそれもありです。通常はかなり高くつくようですけど。


571 :nobodyさん:2006/08/05(土) 05:40:23 ID:???
一言で書けば価値観の違い。
ボッタクリと思うのなら使わなければ良い話。
価値観の押し付けウザ。長文ウザ。


で、素人は好きにやっとけって事でFAで終了。
頼むから他所いってやってくれ。

572 :nobodyさん:2006/08/05(土) 10:11:11 ID:???
セミが鳴き始めたようだな

573 :nobodyさん:2006/08/05(土) 10:21:38 ID:???
ガキは市民プールで遊んでろ。

574 :nobodyさん:2006/08/05(土) 10:57:40 ID:???
>>571
お前が一番ウザいということに早く気付けよチンカスくん。
>>568で自ら長文書いてるし。お前ウザいんだよ。5回くらい氏ねやボッタクリ屋。

575 :nobodyさん:2006/08/05(土) 10:58:39 ID:???
それともう言い訳は聞き飽きたから、
早く「SSL不使用によるクレジットカード番号流出」の実例を挙げろ。

言い訳や、捨てゼリフによる逃げはもう飽きたからいいよ。

576 :nobodyさん:2006/08/05(土) 13:13:10 ID:???
>>574
ん?長文書いてる奴は俺じゃないぞ??
SSL不使用によるクレジットカード番号流出?そんなのシラネーヨw

ま、クレジットカード番号送るのに、SSLも使ってないサイトを使いますか?って事だ。
価値観の押し付けウザ。長文ウザ。
で、素人は好きにやっとけって事でFAで終了。他所いってやってくれ。


577 :nobodyさん:2006/08/05(土) 13:15:13 ID:???
クレジットカード番号送るのに、SSLも使ってないサイト
↑で金を取る方がボッタクリだと思った。

あと>>575の人コテハンにしてくれ。アボンしとくから。

578 :nobodyさん:2006/08/05(土) 17:48:27 ID:???
>>542
>会員専用以外のとこですべてをhttpsでやってるとこなんてあるの?
あった
http://portal.askul.co.jp/

579 :nobodyさん:2006/08/06(日) 00:13:53 ID:???
>>578
準会員制みたいなもんですね
微妙だけど

580 :nobodyさん:2006/08/06(日) 20:38:27 ID:???
>>576
だから逃げるなって、チンカス。
「クレジットカード番号送るのに、SSLも使ってないサイトを使いますか」って、
お前の主張なんか誰も聞いてないんだよ。早くSSLを使わなければ問題が起きるという実例を示せ。

「価値観の押し付けウザ」 ← これをそっくり熨斗でもつけてチンカスに返却しましょう。

581 :nobodyさん:2006/08/06(日) 21:10:38 ID:???
何かのレポートの宿題か?
自分でやれ

582 :nobodyさん:2006/08/07(月) 06:22:05 ID:???
たかだかSSLの設定が出来ない香具師が騒いでいるだけ。
SSLあり/なしの両方で運用できるように書いときゃいいだけなのに。


583 :nobodyさん:2006/08/07(月) 09:25:34 ID:???
>>582
論点のズレた認識乙。

>SSLあり/なしの両方で運用できるように
実際の運用に当たってはそんなの当たり前だろボケカス。
そもそも、話の流れはそういうことを言ってるんじゃないだろうが。
SSL無しの場合の被害実例を早く挙げてみろって言ってんだよ。
いつまで逃げてんだチンカス。

584 :nobodyさん:2006/08/07(月) 09:36:34 ID:???
単位はあきらめろ

585 :nobodyさん:2006/08/07(月) 09:47:08 ID:???
「SSLを使わなければ問題が起きるという実例を示せ」って、
お前の主張なんか誰も聞いてないんだよ。
早く「クレジットカード番号送るのに、SSLも使ってないサイトを使いますか」に回答しろ。

586 :nobodyさん:2006/08/07(月) 09:48:54 ID:???
>>580ってweb製作板の「携帯端末用のWeb制作」で暴れていた馬鹿と同じやつだな。
結局GETが何かすら分かってなかったというオチで逃げ去った馬鹿。
放置推奨。

587 :nobodyさん:2006/08/07(月) 09:55:59 ID:???
>577に一票

588 :nobodyさん:2006/08/07(月) 10:00:44 ID:???
>583
結局こいつは何がいいたいの?w
誰か説明して

589 :nobodyさん:2006/08/07(月) 17:37:02 ID:???
皆さんドコモ向けのセッションってsession.use_trans_sidでやってますか?

590 :nobodyさん:2006/08/07(月) 18:48:37 ID:???
>>589
面倒な時はそうしてる

591 :nobodyさん:2006/08/08(火) 10:14:27 ID:???
>>584-588
悔し紛れのジサクジエン乙。
でもお前ジエンし杉だから、ほどほどにな。

で、早くその逃げの人生を止めろよ。
答えに窮する事実を突きつけられたからって、発狂しちゃいかんよキミwww

592 :nobodyさん:2006/08/08(火) 12:37:31 ID:???
>>591
移動しろ話はそれからだ

セキュリティ初心者質問スレッドpart73
http://pc8.2ch.net/test/read.cgi/sec/1154835858/

593 :nobodyさん:2006/08/10(木) 08:32:10 ID:???
そうして>>592は「答えられない質問」から逃げ通すことに成功した。
その後彼は一生逃げ続けるヘタレな人生を送るのであった。
めでたしめでたし。

594 :nobodyさん:2006/08/10(木) 12:30:02 ID:???
( ゚д゚ )

595 :nobodyさん:2006/08/10(木) 18:09:09 ID:???
質問への返答よりもスレ違いな場所で質問する事のが重要ってことか
死ねばいいのに

596 :nobodyさん:2006/09/30(土) 23:07:37 ID:ev1i2goA
unset($_SESSION)してしまった場合の対処法おしえてくださいっ!
結構探したけどみつかんないです。。。

597 :nobodyさん:2006/10/01(日) 01:06:19 ID:???
>>596
// unset($_SESSION)
でオケ

598 :596:2006/10/01(日) 06:04:12 ID:u4OUdACZ
>>597
レスありがとー。

ということは session 機能がいきなり動かなくなったのは
これが原因じゃないのね。

>unset($_SESSION)によって 全ての$_SESSIONを初期化してはいけません。 $_SESSIONスーパーグローバル変数を用いた セッション変数の登録ができなくなってしまうからです。
これの意味勘違いしてました。

599 :nobodyさん:2006/10/01(日) 09:31:39 ID:???
そもそもネットで個人情報やカードの番号入力する時点でセキュリティが低い。
セッションやSSLに関係なく、個人情報は漏れてるし。
ベリサインも個人情報の流出までは保証してないよ。

600 :nobodyさん:2006/10/01(日) 09:37:01 ID:???
そんなときのPマーク

601 :nobodyさん:2006/10/01(日) 17:44:25 ID:???
SSLは相手の組織の実在証明も大きい

602 :nobodyさん:2006/10/01(日) 23:27:52 ID:???
実在証明の証明書ならね。実在証明無しの証明書も有るし。
PマークもISMSも認証に合格しましたってだけで、漏れない保証は無い。
現場では平気でシュレッダーせずに捨ててたりするし。

603 :nobodyさん:2006/10/02(月) 04:25:34 ID:???
まぁ、SSL通っていてもマーチャントがカード情報を持つようなのは
俺はちょっと引くな。よっぽど大きな企業じゃなければ。
できれば、実績のあるカード決済代行会社を通してる所を使いたい。

604 :nobodyさん:2006/10/02(月) 13:04:11 ID:???
で、実績のあるカード決済代行会社って具体的にどこ?

605 :nobodyさん:2006/10/04(水) 01:35:01 ID:???
ZEROとか?
エロ系サイトでよく見かける大手ww

606 :nobodyさん:2006/10/04(水) 02:11:06 ID:???
10%とか手数料で持ってかれそう(w

607 :nobodyさん:2006/10/04(水) 15:21:52 ID:???
その分価格に上乗せしとけばよい。

608 :nobodyさん:2006/10/05(木) 01:47:13 ID:???
価格転嫁は駄目ってVISAとか指導してたはず。

609 :nobodyさん:2006/10/05(木) 06:55:51 ID:???
むろん、「手数料分を上乗せしてます」なんてわざわざ言うわけないだろバカ。

610 :nobodyさん:2006/10/06(金) 15:39:05 ID:???
すれ違いだろバカ。

611 :nobodyさん:2006/10/17(火) 09:40:53 ID:fxomtaVS
んで結局、「SSLを使わなかったばかりに問題が起きたという実例」ってあるの?
みんな結局、これをしとけば自分もユーザーも安心ってな気持ちでSSLを使用してるんかな?

612 :nobodyさん:2006/10/17(火) 09:56:15 ID:???
>>611
なんでセッションスレで?

613 :nobodyさん:2006/10/17(火) 13:02:42 ID:???
>>611
シラネ

金貰って仕事やってると、クレジットカード決済にSSL使ってません…なんて鼻で笑われるのは事実だが。

SSLを使う一番の理由は、問題が起きる起きないという事よりも、利用者に与える安心感(サイトイメージ)を得る為。
一般人はSSLが何かなんて全く分かってない。
だけど、ベリサインがどうので高度なセキュアをかましてると謳うと、かえってSSLが何かすら
全く分かってない素人には、安心感を与える事が出来る。
SSLを使う理由なんてそんなもん。つまりあなたの仰るとおり。

個人の趣味でやるのなら好きにやればいいし、
金貰ってやるならそれに意味があるかどうかなんて考える必要性は全くない。

614 :nobodyさん:2006/10/18(水) 03:54:01 ID:???
安心感なんて気持ち程度だけどね。
ssl対応でも個人情報ただ漏れの鯖なんていくらでもある。

615 :nobodyさん:2006/10/18(水) 20:34:34 ID:???
やばい、yahooショッピングにセキュリティホール見つけたんだけど
ここで公開するべき?それとも電話かけておしえてあげるべき?
それともメール発射するべき?


616 :nobodyさん:2006/10/18(水) 20:59:58 ID:???
>>615
サイトのセキュリティホールもIPAへの届出でOK
http://www.ipa.go.jp/security/vuln/

617 :nobodyさん:2006/10/18(水) 21:02:15 ID:???
とりあえずここには書くな

618 :nobodyさん:2006/10/18(水) 21:16:28 ID:0wCu4Tq1
やばい、yahooショッピングでアナルホール見つけたんだけど
ここで公開するべき?それとも電話かけておしおきしてあげるべき?
それともホールに発射するべき?

619 :nobodyさん:2006/10/19(木) 02:53:05 ID:???
>>614
そんなの一般人にとっては分からない事だしどうでもいい。

個人の趣味でやるのなら好きにやればいいし、
金貰ってやるならそれに意味があるかどうかなんて考える必要性は全くない。
そこんとこの差が理解できない奴が多すぎ。

620 :nobodyさん:2006/10/19(木) 06:22:53 ID:???
俺はルータにしてたLinuxマシンに、
パケットスニッファを仕込まれた経験がある。

621 :nobodyさん:2006/10/19(木) 17:10:15 ID:???
>>619
日本語でOK

622 :nobodyさん:2006/10/21(土) 10:06:06 ID:???
rootkitとか仕込まれると、怪しいファイルを消してもroot権取られたままで踏み台にされるらしいね。

623 :nobodyさん:2006/10/22(日) 15:52:50 ID:???
Ajax系画面遷移無しの非同期通信で、ポストゲットを使わずにセッションの値を変えられないだろうかぁ〜?
ポストゲットすると変数いじれるし… ボタンを押したイベント時に、セッションの値を代入したいんだよなぁ。
そんなセキュリティーを求められてるんだが… 一日いろいろ試したけど、ポストゲット使う以外の方法が見つからなかった;;
エロイ人教えて;;

624 :nobodyさん:2006/10/22(日) 17:02:58 ID:???
ポストイット使う

625 :nobodyさん:2006/10/22(日) 19:27:10 ID:???
4.4.0でsession_regenerate_id(true)すると古いセッションIDって消してくれます?

626 :nobodyさん:2006/10/23(月) 18:03:43 ID:???
>>625
trueで消せるのは5.1で有効になったから4系では消えない。

627 :nobodyさん:2006/10/26(木) 06:12:34 ID:F7p++raS
PerlとPHPで、sessionの共有は可能でしょうか?

Perlモジュールは CGI::Session を使おうかと思ってます。

SessionIDが同じならPerlとPHPでsessionの共有はできるものでしょうか。

「sessionの共有」する方法をご存知の方、いらっしゃいますか?

628 :nobodyさん:2006/10/26(木) 06:20:20 ID:???
できるできないじゃなくて、
簡単なコードかいて試せば数分でわかることじゃん。
そんな時間ももったいなくて使いたくないのか?

629 :nobodyさん:2006/10/26(木) 06:50:16 ID:???
>>628
ごもっとも。
でも
共有鯖で、Perl用のSessionが組み込まれていないので試しようがない。
モジュールの追加は申請中だけど、いつになるか判らない。 
自宅鯖は、崩壊中。

判んないないら黙っててね。煽るのは止めてね。

630 :nobodyさん:2006/10/26(木) 08:56:57 ID:???
>判んないないら黙っててね。煽るのは止めてね。
何様だ

631 :nobodyさん:2006/10/26(木) 09:04:21 ID:???
どう考えても質問よりテスト環境整えるのが先だろ

632 :nobodyさん:2006/10/26(木) 10:07:07 ID:???
(゜m゜*)プッ
厨に厨が喧嘩売ってんじゃねーよ。質問スレだ、煽る前に答えてやれ。

・PerlとPHPなどでは SessionIDが同じでも、共有はできない。
 CGI::Sessionで、PerlはSessionが使えるけど、それはCGI::Sessionだけで使える。

PHP::Sessionなら出来るらしいが、私は知らない
http://perldoc.jp/docs/modules/PHP-Session-0.15/lib/PHP/Session.pod

633 :nobodyさん:2006/10/26(木) 10:44:28 ID:???
>質問スレだ、煽る前に答えてやれ。
あれが煽りに見える時点でアレだし、この理屈はおかしい

634 :nobodyさん:2006/10/26(木) 11:03:23 ID:???
>>627
俺はperlから離れてはや数年経つしCGI::Sessionは使った事ないが、
PHPに標準実装されてるセッション管理法はファイルベースで、
指定ディレクトリの中にセッションIDを含んだファイル名を使って管理している。

つまり、perlでもそのファイルと全く同じものを使ってセッションを実装するなら、
共有は出来る。それが出来ないなら、自前のセッション管理法にすればいい。

635 :nobodyさん:2006/10/26(木) 11:05:50 ID:upDRXWKA
ログインフォームからログインしてセッションでtime()使ってタイムアウトさせるようにしたんですけど、
今のままだとログイン後に設定した時間が来たらタイムアウトされます。

何かしら操作したら情報をリセットするようなことってできますでしょうか・・・。


636 :nobodyさん:2006/10/26(木) 12:07:11 ID:dpAXN0uK
>>634
そうなんだけど、PHPのセッションハンドラって指定できなかったっけ?
デフォルトはファイル管理だと思うけど(サーバー設定次第)DB管理にもできるし。
DB管理にしちゃえばPerlの共有前提なら楽チンだと思った。
まぁ、いずれにしよ、モジュール任せの実装じゃ共有は難しいね。


637 :nobodyさん:2006/10/26(木) 13:56:19 ID:???
>>636
出来るよ。
session_set_save_handler()使うのが楽。

>まぁ、いずれにしよ、モジュール任せの実装じゃ共有は難しいね。
そういう事。

>>635
PHPのデフォのセッション使ってるなら、タイムアウトの指定が出来るから確認してみ。

638 :nobodyさん:2006/10/26(木) 18:24:54 ID:???
php5.2でセッション使ってる人の感想聞きたいのですが、
php5.1とくらべて何か変わったところありますか?

639 :nobodyさん:2006/10/26(木) 23:01:05 ID:???
ない

640 :nobodyさん:2006/10/26(木) 23:29:44 ID:???
そろそろ5.2がインデックスにでてくるころじゃね。
でもなんでベータ版ってわかりずらいところにおいてあるんだろう。


641 :nobodyさん:2006/10/27(金) 16:29:50 ID:qVqOzfjK
>>637
ありがとうございました。解決しました。

642 :nobodyさん:2006/10/29(日) 07:44:54 ID:???
馬鹿がダウンロードしないようにでしょ。
バカ避け。
馬鹿は安定板を使うべき。

セッションが簡単に共有できたら、レン鯖なんてセッション取られまくりだ(w
つ他人のセッション

643 :nobodyさん:2006/11/03(金) 13:21:11 ID:QUVcMJYR
そもそも、セッションIDがばれたら何が怖いんですか?
どこをどうされてログインされるんですか?

こないだセッションIDというヤツを他人に知られたんですけど、
何をされるんですか?

644 :nobodyさん:2006/11/03(金) 14:19:12 ID:???
ググって自分なりに調べたらまたきなさい。
あげんなバカ

645 :nobodyさん:2006/11/03(金) 14:37:00 ID:???
>>643
初級ネット
http://pc8.2ch.net/hack/


646 :nobodyさん:2006/11/04(土) 01:54:01 ID:toBPKG6d
セッションの有効期限なのですが

session_cache_expire(1440); //12時間
session_start();

セッションが必要なページ全てに書いているのですが
途中で切れています 12時間持ったことが今までないのですが、
なにか注意点はありますか?

647 :nobodyさん:2006/11/04(土) 04:42:40 ID:???
その関数はHTTPのキャッシュコントロールで
セッションの有効期限とは関係ないと思うけど

648 :nobodyさん:2006/11/06(月) 03:28:19 ID:???
質問者ではないけど、キャッシュコントロールと有効期限とは別物なんですか?
ちょっと気になったもので。

649 :nobodyさん:2006/11/06(月) 04:45:28 ID:???
>>648日本語でOK

650 :nobodyさん:2006/11/06(月) 08:25:11 ID:???
1440分って24時間だけど

651 :nobodyさん:2006/11/06(月) 08:28:14 ID:???
session_cache_expire(12*60); //12時間
にしたらよかったのに

652 :nobodyさん:2006/11/07(火) 10:39:00 ID:???
>>646
セッションの有効期限は
session.gc_maxlifetime
session.cookie_lifetime
前者はサーバ側でのセッション保持期間、
後者はクライアント側でのセッションID保持期間。

>>647
キャッシュが有効だとサーバ側で予測できない遷移が起こってしまう。
セッション中ではその予測できない遷移によって、セッション変数に不整合が生じるなど、
悪影響がでる可能性が増大する。
そのため、セッション中におけるキャッシュの制御を、
通常のキャッシュ制御とは別にセッション関連の設計者・プログラマにゆだねる必要がある。
session_cache_expireはそのための関数であって、セッションの有効期限とは無関係。

653 :nobodyさん:2006/11/07(火) 11:19:04 ID:???
ナイス解説

654 :nobodyさん:2006/11/08(水) 10:02:01 ID:???
>>652
サーバー側の設計が分からないためか、イマイチすっきりと分からない。

655 :nobodyさん:2006/11/08(水) 16:21:52 ID:???
>>652
phpinfo()

656 :nobodyさん:2006/11/11(土) 14:18:54 ID:OcR85OjN
session_regenerate_id使うとSet-Cookieが2度送られるのな。
それのせいで、IE6のCookieがたまに誤動作を起こして、
旧SESSION_IDを送ってしまうのはバグ?

657 :nobodyさん:2006/11/11(土) 15:23:10 ID:???
>>656
ちゃんとマニュアル読んでればわかる話。
あと10回session_regenerate_idについてマニュアルを読み返してみろ

658 :nobodyさん:2006/11/17(金) 05:48:06 ID:???
IEってサービスパックでも挙動が変わる問題ブラウザだからな。
IE7対応できてる香具師居る?

セッション中のキャッシュってメモり喰いまくって腹膨れてるから、早めに解放しないとリソース枯渇して鯖ごと落ちるだけだぞ。

他人のセッションが取れたら、他人のカードで買い物しまくれるよな(w
ミクシだと、他人の垢使いまくり(w

659 :nobodyさん:2006/11/17(金) 10:54:31 ID:???
またそのネタか

660 :nobodyさん:2006/11/18(土) 22:05:59 ID:vrteR2uu
>>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にこの指定をいれておけばいいでしょうか?

お手数だと思いますがよろしくお願いいたします


661 :660:2006/11/18(土) 22:10:53 ID:???
何度もすいません

セッション保持期間なのですが、値を読んだときからという認識であってますでしょうか
値を更新した時からではないですよね?

662 :nobodyさん:2006/11/20(月) 23:48:22 ID:???
マニュアル読めば分かると思うが

663 :nobodyさん:2006/11/23(木) 00:27:15 ID:???
世の中、暇人や言語マニアばっかじゃないから、いちいちマニュアルなんか読んでらんないんだよ。
答える気がないんだったら、ウザイから黙ってろよ。

664 :nobodyさん:2006/11/23(木) 00:38:15 ID:???
プログラマでマニアじゃないのは致命的と釣られてみよう

665 :nobodyさん:2006/11/23(木) 00:47:02 ID:???
いや、662は答えだが?

666 :nobodyさん:2006/11/23(木) 03:09:43 ID:???
>>664
単なるマニアは致命的。プログラマーという仕事に向いてない。
しかも、プログラムする人間が職業プログラマーだけという閉塞した思考回路も致命的。
世の中には本来の目的とは別に、仕方なくプログラムを組まなきゃならん人間がいるのだ。

>>665
文盲乙!

667 :nobodyさん:2006/11/23(木) 03:25:50 ID:???
なぜそう答えられたのか自分のレスと読み比べてみたらw

668 :nobodyさん:2006/11/23(木) 04:47:38 ID:???
>>667
コミュニケーション能力のない奴、乙!

669 :nobodyさん:2006/11/23(木) 05:05:59 ID:???
> 暇人や言語マニアばっかじゃないから、いちいちマニュアルなんか読んでらんないんだよ

指をくわえて答が返ってくるのを待つほど暇じゃない人のためのマニュアルだし
ソース読んで仕様を舐めまわすマニアじゃないから使い方だけ知るためにマニュアルを参照するんだよ
応用が利くという複利もあるしね。現実に>>661はこのケースだったわけだ

さて、日本語がよめてコミュニケーション能力のある奴ならなんて答えるんだろうねw

670 :nobodyさん:2006/11/23(木) 09:38:54 ID:???
マニュアルの該当部分をここに書けってか死ねばいいのに
答えが書いてある場所を示されただけでも良いほうだろ
ここはサポセンか?
釣り宣言していいから去れ

671 :nobodyさん:2006/11/23(木) 11:01:40 ID:???
1.登録→2.確認(セッション保存)→3.完了(セッションからDB登録)
って流れでセッション使うのは皆どういうやり方してるの?
以降、登録画面用セッションデータをSDと、登録・確認・完了は1・2・3で記述

一.SD1件方式
1で既存SDがあればクリアする?2で上書きする?
2でSD保存
3で登録後にSD消去
つまり、登録確認画面を開いたまま、別ウインドウで登録処理を同時にやると最初の画面は正常動作しない

二.SDn件方式
1で何もしない
2でSD増加し保存
3で登録後にSD消去
つまり、確認画面を開かれる度にSDが増加し、完了までいかなければゴミSDが無限に増加していく

どちらも問題点があるんだが、みんなセッション使ってるみたいだし
問題点のないスマートなやり方ってあるの?

672 :nobodyさん:2006/11/24(金) 04:02:25 ID:???
>>669
日本語が不自由な奴、乙

>>670
マニュアルの該当部分でもコピペすればいいだろ。コピペの仕方なら初心者板で聞いて来い

673 :nobodyさん:2006/11/24(金) 04:17:04 ID:???
>>672
マニュアルを読めばいいじゃん?

674 :nobodyさん:2006/11/24(金) 05:01:48 ID:???
>>672
必死だな

675 :nobodyさん:2006/11/24(金) 13:47:32 ID:???
>>671

俺はSD(ってセッションデータ?)1件方式だな。
登録画面を開いたときに、一意になるようなキーをセッションデータにセットして、
その値をhiddenで確認まで持ちまわる。
3で画面から渡されたキーと、セッション内のキーを比較して同じなら登録。
違ってたらやり直せと。
大体この程度で許されるんじゃない?甘い?


676 :nobodyさん:2006/11/25(土) 11:11:23 ID:???
他人のセッションって奪えるの?

677 :nobodyさん:2006/11/25(土) 13:33:52 ID:???
もちろん
単純にセッションIDだけで管理するなら、理論上は総当りで奪えるよ
現実的にどうだかはトリップ解析の総当りを見れば分かる
セッションIDが特定できる場合は言わなくても分かるな?

678 :nobodyさん:2006/11/26(日) 12:14:04 ID:???
なんだ実際に試してないのか
空論で語られてもな

> 単純にセッションIDだけで管理
そりゃそうだ

679 :nobodyさん:2006/11/26(日) 12:47:44 ID:???
お前バカ?

680 :nobodyさん:2006/11/26(日) 20:48:13 ID:???
物理的にネット上のIPを奪ってセッションIDを盗み見られたら終わりだね。

681 :nobodyさん:2006/11/26(日) 21:11:02 ID:???
こいつこそ馬鹿

682 :nobodyさん:2006/11/27(月) 09:31:58 ID:???
たしかソフトあるだろ?

683 :nobodyさん:2006/11/30(木) 04:38:29 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


684 :nobodyさん:2006/12/01(金) 11:08:38 ID:???
>>683
マイクロ秒単位の現在時刻 + ユーザーのリモートアドレス + combined-LCG(線形合同法自体は、疑似乱数生成方法としてはセキュアな方法ではない。) が種となっている。

それで充分。

/dev/urandom を乱数の種に使うように設定しよう。

自己満足の世界

良い意味でも悪い意味でも、PHP程度のスクリプト言語に何を求めているの?
と逆に問いただしたいものだ。

685 :nobodyさん:2006/12/02(土) 10:07:44 ID:???
はげどう

686 :nobodyさん:2006/12/02(土) 10:33:56 ID:???
>>684
> 良い意味でも悪い意味でも、PHP程度のスクリプト言語に何を求めているの?

php程度って…、そのphpは銀行のシステムや証券会社のシステムでも使われてるよね?
まぁ大抵はaspだろうけどさ。

687 :nobodyさん:2006/12/02(土) 10:44:13 ID:???
むしろPHPを使うのはこの程度の奴らかって思うけどな

688 :nobodyさん:2006/12/02(土) 11:02:10 ID:???
>>684
> 良い意味でも悪い意味でも、PHP程度のスクリプト言語に何を求めているの?

session.entropy_file という設定があるからには、
PHPはそういう利用法も想定していると推測できるでしょ?

偉そうな阿呆の書き込みを見ると疲れるな・・。

689 :nobodyさん:2006/12/02(土) 14:38:37 ID:???
だよな
1.設定が用意されている
2.PHPはLinux以外のOSも対象にしているのでデフォルトは違う
脳みそのある人間ならこう考えるのが普通だと思う俺の視点では
>>>「phpらしい駄目っぷりだ。」
こいつ痛すぎるだろw

で、設定変更すればよりセキュアな環境を提供できるにも関わらず
自己満足などと言い切るのは、とてもプロだとは思えないな

690 :nobodyさん:2006/12/02(土) 15:36:09 ID:???
> 2.PHPはLinux以外のOSも対象にしているのでデフォルトは違う

そういや、Windows はセキュアな擬似乱数発生器持ってないのかなー
Unix の /dev/urandom みたいなやつ

乱数発生は本来プログラミング言語レベルじゃなくて、OSがやるべき話
ハードウェアのノイズを取得するのはOSがやるのが一番効率いいし


ちなみに、乱数の安全性ってのは馬鹿にできない話だよ

「ハッカーズ その侵入の手口 奴らは常識の斜め上を行く」 にもあるように、
それでラスベガスのカジノでぼろもうけしたやつもいるしさ、オンラインゲーム(MMO)なんかでも
時間種乱数のせいでクラックされてゲームバランス崩れた例もある




>>689
> で、設定変更すればよりセキュアな環境を提供できるにも関わらず
> 自己満足などと言い切るのは、とてもプロだとは思えないな

激しく同意

691 :nobodyさん:2006/12/04(月) 10:59:25 ID:???
いや、自己満足だろ。
クライアントから見て理解できない部分へのこだわりっていうのは、所詮は自己満足。
自己満足と分かった上でやるかやらないかだけだ。



つか、素人のくせにプロ面して語るのが激しくウザい。

692 :nobodyさん:2006/12/04(月) 13:55:31 ID:???
俺はsmartyで挫折してcakephpでも挫折した男だけど、プロ意識は持ってます。

693 :nobodyさん:2006/12/04(月) 17:55:48 ID:???
うちにはフロがありません。

694 :nobodyさん:2006/12/04(月) 20:01:21 ID:???
そろそろ、セッション=PHPじゃないって気が付こうぜ。

つーか、単発スレ使ってるなよ。

695 :nobodyさん:2006/12/04(月) 22:48:19 ID:???
>>691
自分の事かw

696 :nobodyさん:2006/12/04(月) 23:03:51 ID:???
マ板でや(ry

697 :nobodyさん:2006/12/06(水) 03:46:50 ID:???
携帯でセッション持たせようとするときって、どうやってる?

698 :nobodyさん:2006/12/06(水) 11:20:50 ID:???
>>697
携帯から取得できる一意キーを元に、アプリ側でセッションを作成してる。

699 :nobodyさん:2006/12/07(木) 06:09:04 ID:???
>>698
レスありがとうございます。
それはPOSTの時にしか使えないと思いますが、GETでも必要な場合にはどうしていますか?

700 :nobodyさん:2006/12/07(木) 16:25:12 ID:???
>>699
キャリアによるわ。
au だと EZ番号 (サブスクライバID) を常に送信するのがデフォルトだし。

個体識別番号を常に送信するのはプライバシー上問題あるが、セッションCookieにすら対応していない
糞キャリアドキュモの場合には、URIにセッションIDいれるというセッション固定攻撃の被害を受ける可能性のある
脆弱な実装しかできない。



701 :nobodyさん:2006/12/08(金) 07:34:22 ID:???
>>700
レスありがとうございます。
なるほど。ある程度覚悟してましたが、やっぱり面倒臭そうですね。

702 :nobodyさん:2006/12/20(水) 23:22:08 ID:???
そもそもプロならphpなんて使ってないだろ。
やっつけ仕事向けのVB感覚が売りなのに、しっかり業務としてインターネットに公開している企業は痛い。
金無いのかよと(w

あと、/dev/urandumは本当に乱数かどうか検証したのか?
疑似乱数って実装は、ありがちだぞ。リナックスは変に妥協してたりするし。




で、クッキー無しでセッションを安全に使う方法ってあるの?
クッキーなんて偽造できるし、セッションIDぐらい総当たりで突破できるし。

703 :nobodyさん:2006/12/21(木) 00:07:20 ID:???
セッションに何を求めてんの?
安全にしたいならSSL+ワンタイムパスででも武装しろよ

704 :nobodyさん:2006/12/21(木) 00:52:48 ID:???
>>702
俺、そのPHPで今年は年収2000万超えたけどねw
金あるところにはあるもんだ。いくらでも需要ある。

705 :nobodyさん:2006/12/21(木) 10:30:45 ID:???
>>702みたいな変なプライド持ってる開発者に限って、
ものを作らせるとインターフェースが糞で使い物にならない事が多いw

706 :nobodyさん:2006/12/21(木) 20:07:53 ID:???
>>702

> あと、/dev/urandumは本当に乱数かどうか検証したのか?
> 疑似乱数って実装は、ありがちだぞ。リナックスは変に妥協してたりするし。

コード見ればわかるだろ
複数のハードウェアのノイズをもとに生産している乱数であって線形合同法とか時刻などは一切使ってない


707 :nobodyさん:2006/12/21(木) 21:45:57 ID:???
>>702は周りが全く見えないバカの見本

708 :nobodyさん:2006/12/22(金) 01:56:52 ID:???
全てのWEBアプリをCで書く人が居ると聞いて飛んできました

709 :nobodyさん:2006/12/22(金) 02:52:42 ID:???
おまいらのOSってphpで動いてるのか?

2000万のサイトってどこだよ。
個人情報対策できてるかどうかチェックしてやるよ。

ハードウェアのノイズって割と周期的だが。

710 :nobodyさん:2006/12/22(金) 03:04:32 ID:Gi2E4i2d
さらしage

711 :nobodyさん:2006/12/22(金) 04:34:25 ID:???
O OSが
P PHPで
U 動いているので


712 :nobodyさん:2006/12/22(金) 09:28:01 ID:???
>>702
>そもそもプロならphpなんて使ってないだろ。

・・・

713 :nobodyさん:2006/12/22(金) 10:55:14 ID:???
>>702の知識のなさがうかがえますね。

714 :nobodyさん:2006/12/22(金) 13:48:00 ID:???
今日の迷言

おまいらのOSってphpで動いてるのか?

さて、次はどんな事書いて笑わせてくれるのでしょうか。この人は

715 :nobodyさん:2006/12/22(金) 13:51:42 ID:???
>>709
>2000万のサイトってどこだよ。
質問の意味が分からんしw
俺は個人で小さな会社経営してて、小回りの効く分色んな仕事をとってこれるってだけだよ。
会社経営者なら分かると思うが、この仕事は経費作るの大変でさ、売り上げのほとんどが利益になってしまうから、
自分や従業員の給料を歩合制にしてるんだよ。

このスレにはSOHOやってるやつとかも多いんじゃね?手挙げてみ。

716 :nobodyさん:2006/12/22(金) 13:59:19 ID:???
俺の経験上、>>702みたいな奴に限って、仕事任せると全然使いものにならないんだよなw

717 :nobodyさん:2006/12/22(金) 14:06:22 ID:???
>>715

718 :nobodyさん:2006/12/22(金) 14:30:02 ID:???
>702
>あと、/dev/urandumは本当に乱数かどうか検証したのか?

「本当に乱数か」
「本当に乱数か」
「本当に乱数か」
「本当に乱数か」
「本当に乱数か」
「本当に乱数か」
「本当に乱数か」

あまりにも酷い無知加減ですね

719 :nobodyさん:2006/12/22(金) 14:33:03 ID:???
>>702には乱数の定義から教えないと駄目って事だな

720 :nobodyさん:2006/12/22(金) 23:50:54 ID:???
> あと、/dev/urandumは本当に乱数かどうか検証したのか?
> 疑似乱数って実装は、ありがちだぞ。リナックスは変に妥協してたりするし。

何度見ても笑えるw
/dev/urandun はセキュアな擬似乱数生成器だ。

擬似乱数じゃない乱数なんてPCで生成するのは不可能だから
もし、生成できるソフトがあるんだったら教えてくれ

絶対ないけどな

721 :nobodyさん:2006/12/23(土) 01:32:20 ID:???
702の人気に嫉妬

722 :nobodyさん:2006/12/23(土) 02:08:07 ID:???
疑似乱数でなければ、セッションの意味ないだろ。乱数じゃないし。
総当たりされたら終わりだ

phpで稼いでるのってウェブデザだろ? プロじゃないし。

723 :nobodyさん:2006/12/23(土) 09:47:05 ID:???
稼いでいるのをプロって言うんじゃないのか?

724 :nobodyさん:2006/12/23(土) 11:59:28 ID:???
どうでもいいけど>>702はVBの業務アプリケーションの多さを知らないのか?
C/S廃れてからは流石にあんまし見ないけどさ。

ちなみに今業務で使ってるのもPHPです。お手軽さが売りです。
本当にどうもありがとうございました。

725 :nobodyさん:2006/12/23(土) 17:39:18 ID:???
VB.NETなんてインターネットに公開してたらすぐやられるけどな(w
phpサイトも個人情報漏れまくりだ。セッションも乗っ取り放題。

726 :nobodyさん:2006/12/23(土) 20:26:47 ID:???
言語の話と関係ないじゃないかwwww

727 :nobodyさん:2006/12/23(土) 20:33:04 ID:ul/tR+zH
VB.NETの話と違うんじゃない
バック側の管理でVB使ってるところは沢山見たことあるぞ
非.NET時代のASPでも言語はVBが使われてたりしたけどな

728 :nobodyさん:2006/12/24(日) 01:45:11 ID:???
言語が何であろうが、それで金稼げば一応はプロ。
年収1000万以下の奴はカスだが。
どんなに素晴らしい能力があっても、ウンチクたれるだけで金稼げ無い奴は素人。

729 :nobodyさん:2006/12/24(日) 04:23:20 ID:???
プログラムやHTML書けるけど、人と話せない引きこもりって居るよな。
買い叩かれて氏ねば良い。

730 :nobodyさん:2006/12/24(日) 19:13:32 ID:???
めりーくりきんとん!

731 :nobodyさん:2006/12/25(月) 12:02:27 ID:???
>>728
そういうことはまずは就職してからな。
みんなニートの妄想に付き合う程暇じゃないと思うよ

732 :nobodyさん:2006/12/25(月) 13:45:11 ID:???
就職も糞も俺は会社経営者ですが(w

733 :nobodyさん:2006/12/25(月) 13:54:35 ID:???
夢見るニート君

734 :nobodyさん:2006/12/26(火) 10:03:04 ID:???
>>732
それは新しいニートの逃げ文句ですか?

735 :nobodyさん:2006/12/27(水) 20:31:17 ID:???
社員1人なんだろ

736 :nobodyさん:2006/12/27(水) 21:08:54 ID:uxVmAwI9
あの、お忙しいところ、質問があります。
インターネットオプションで、クッキーの設定を行っているのですが、
クッキーが巧いこと、保存されません。

具体的には、プライバシー設定の詳細で
「自動Cookie処理を上書きする」のチェックをon,off両方を試し、
onの場合、どちらも受け入れるを選択、常にセッションCookieを許可するのon,offの
全てのパターンで試しました。

しかし、Cookieが保存されませんでした。
こういうことってあるのでしょうか?解決方法を教えていただける方いませんか?



737 :nobodyさん:2006/12/27(水) 21:42:31 ID:???

serversideでちゃんとクッキーが発行されているのか?

738 :nobodyさん:2006/12/28(木) 10:08:55 ID:hZGMKlHK
別のクライアントブラウザからは、クッキーの発行が確認できました。


739 :nobodyさん:2006/12/28(木) 11:15:38 ID:???
ブラウザのセキュリティーレベルの設定等で受け入れられない状態とか

740 :nobodyさん:2006/12/29(金) 04:46:01 ID:???
世の中にはクッキー非対応の環境も有るし。
ひたいおうでもうごくようにしとけ。

741 :nobodyさん:2007/02/14(水) 01:24:48 ID:???
session.gc_maxlifetimeってデフォルトが24分(1440秒)なのは、実装した人の勘違い?
ちゃんと意味があるの?
というのは、session.cache_expireが180分(3時間)になってても、実際は24分で切れちゃうでしょ?
この辺を論理的に説明できる偉い人の登場を期待アゲ

742 :nobodyさん:2007/02/14(水) 01:28:14 ID:GOP4vaea
ごめん、sageた・・・

ついでに、このガーベージコレクションだけど、
/htdocs/を1440秒
/htdocs/admin/を3600秒に.htaccessなんかで変更した場合、(set_iniでもいいけど)
変更したディレクトリはちゃんと時間が反映されるんでしょうか?
(自分で試せば分かるだろって?そうですね・・・試してみます)

743 :nobodyさん:2007/02/14(水) 01:35:37 ID:GOP4vaea
>>741の補足です。
なんで1440秒が勘違いかと思ったかというと、session.cache_expireが分指定だから、
session.gc_maxlifetimeも分指定の値になっているのかと。
つまり、GCは24時間毎に行う指定になっている?
でも、24時間って長すぎるよなぁ・・・
(つうか、この場合のGCってデフラグと同意だろうから、24時間サイクルじゃ頻繁すぎるのかなぁ?)

744 :nobodyさん:2007/02/14(水) 02:30:17 ID:???
>>741
とりあえず>>652あたりを読んでから論理的な質問よろ。

745 :nobodyさん:2007/02/14(水) 02:30:58 ID:???
>>741
まず、じぶんの環境ぐらいかけ。
話はそれからだ。

746 :nobodyさん:2007/02/14(水) 03:13:21 ID:GOP4vaea
今のところ、説明できる人は登場していないらしい

747 :nobodyさん:2007/02/14(水) 03:24:00 ID:???
>>746
死ぬまでに登場するといいですね。

748 :nobodyさん:2007/02/14(水) 03:28:14 ID:???
またおまえか。つかれてんじゃないの?

749 :nobodyさん:2007/02/14(水) 09:53:54 ID:???
疲れてる?
憑かれてる?
突かれてる?
吐かれてる?

750 :nobodyさん:2007/02/15(木) 23:28:35 ID:???
>>746
「キャッシュ」がなんなのか理解してるか?
理解してるなら>652で十分な回答になるはずなんだが。

>>744
自分のレスを参照されてうれしかった。ありがとう。

751 :nobodyさん:2007/02/17(土) 06:19:47 ID:M1RBozDN
>>750
君はその知識で実際に運用して、推測通りにセッションを
コントロールできてるか?伺いたいものだ。
例えば、セッション24時間にしょうとして、実現できているか?
できていないはずだ。自分で推測することは科学といわない
普遍的な(と思われる)手段で反証して確かめることが「科学的」なんだよ。

それと、デフォルトのmaxlifetimeが1440秒ということについての
ご意見をお伺いしたいのだが?

752 :nobodyさん:2007/02/17(土) 10:34:49 ID:???
>>751
それは自然科学の考えだろ。
今相手にしているのは人工物で仕様が示されている。ソースコードもある。
デバッグを行う人間ならまだしも、利用者がその挙動確認をするために演繹を行うのは甚だ筋違いだ。

>それと、デフォルトのmaxlifetimeが1440秒ということについての
>ご意見をお伺いしたいのだが?
http://www.zend.com/lists/php-dev/200201/msg00239.html

753 :752:2007/02/17(土) 10:36:45 ID:???
×演繹を行うのは甚だ筋違いだ。
○演繹や帰納に基づく実験を〜

186 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)