07/03/13 20:09:42
ログインユーザをセッションＩＤと一緒に、ＤＢなりファイルに書き出しとけばいいんじゃないの。
同一ユーザ名ログインの時には、それに対応するセッションＩＤが残ってるかどうかチェックして
なきゃそれでＯＫ。
でも同一ユーザ名・パスワードの複数保持なんていうのがそもそもセキュリティ的にラフすぎ。
773:nobodyさん
07/03/14 09:34:15
>>772
ありがとうございます。
何かの拍子に ID/PW が漏れた場合、
同時にアクセスされたら漏洩発覚！としたかったんです。
774:nobodyさん
07/03/14 09:44:37
>>773
そんなのWWWでやるシステムじゃない
775:nobodyさん
07/03/14 12:37:17
どうやってログアウトをシステム側で察知するかだな。
操作ミスなり回線不良なりでCookieあぼーんすると
直ぐにログインできないってことになる。
776:nobodyさん
07/03/14 12:59:55
つかブラウザ二個起動した時点で終了
777:nobodyさん
07/03/14 14:20:57
>>774
ネットバンクとかで無いか？
778:nobodyさん
07/03/14 14:35:20
>>777
>>776
779:nobodyさん
07/03/14 14:41:52
>>778
意味ワカラン
780:nobodyさん
07/03/14 14:43:11
分かった
781:nobodyさん
07/03/14 14:46:43
>>776
同じIPならセーフとかは？
782:nobodyさん
07/03/14 14:57:05
>>781
ルータ経由はどうすんの。
783:nobodyさん
07/03/14 19:03:09
やっぱり難しいさね。
ストリーミングサイトだったら通信継続してるから
感知して第二ユーザはキック出来るけど、そうじゃなきゃ>>775のような
ケースでクレーム来るほうが怖いからなあ。
784:nobodyさん
07/03/14 19:07:01
ログイン画面で固定のキーを与えるのどうだろう。
785:nobodyさん
07/03/14 19:12:34
トークン使う
786:nobodyさん
07/03/14 19:21:48
明示的なログアウト送信がない限り全部一緒の問題を抱える
787:nobodyさん
07/03/14 23:04:39
まあセッションクッキーのexpire時間を金融サイトみたいに１０分とか短く設定しておいて、
１０分以内に通信無きゃ強制ログアウトっていうのが許されるサイトなら問題が少なくなる。
最大１０分の再ログインラグが出るけどね。
788:nobodyさん
07/03/15 00:52:45
昔やったサイトというかWebアプリでは
・ユーザは出来るだけ明示的にログアウトするようお願いする
・メインウィンドウがクローズされる時にログアウトのURLを叩くJavaScriptを仕込んでおく
・最終アクセスを全ユーザの全アクションで記録しておいて、ログアウトなしのユーザがログインしようとしたら最終アクセスが10分以内の場合は弾く
イントラ用のアプリケーションだったから負荷とかも考慮した上でここまでやったけど
一般向けのWebサイトじゃどこまでやるかは難しい判断だろうなぁ
789:nobodyさん
07/03/15 09:27:34
>>787
それは、パスワード漏洩時の対策にはならんのではないか。
まあそもそもの話として同時アクセス＝漏洩なのかというか、常時使うシステムでもない限り使う時間がぶつかることがあるのか疑問。
漏洩するとしたら、内部からユーザ情報持ちだしとか、パソコンに付箋紙貼ってある時だと思うんだが、
したら不正利用する人が夜中とかに使えばまあ、システム上はほとんど不正利用にならないだろうし。
>>788
ログアウトするようにお願いするったって
不特定多数のコンピュータリテラシーがまちまちなユーザじゃ無理。
メインウィンドウをクローズしないかもしれないし。
夢を見すぎじゃないかと。
ユーザに過去のログイン・ログアウト情報を提示して、変だったら通報してもらうほうがいいんじゃねえの。
過去にどういう行動をしたのか知ってるのは本人しかいないわけだし。
790:nobodyさん
07/03/15 10:01:20
>>789
世の中には「テメエにしか分からないこと」を
自動的に論理矛盾なくプログラム側で判断しろ、
という輩もいるわけでｗｗｗ
791:nobodyさん
07/03/15 11:54:09
生体認証かな
792:nobodyさん
07/03/15 12:14:00
>>789
お願いするだけじゃ無理なのが解ってるから2番目・3番目の仕組を入れてるわけで
無理じゃなけりゃJavaScriptだの全アクセス記録だの不要だろｗ
あと「イントラ用」って書いたんで不特定多数ではない時の話だってのも読み取ってほしいところ
>>791
ログインには使えるけどログアウトしてくれるかどうかは別問題だねそれはｗ
PCの不意のハングアップまで考慮しようとすると
それこそJavaScriptか何かでサーバとハートビート交換しまくって
途切れたらログアウト処理にするとかまでやらないと難しいだろうなぁ
793:nobodyさん
07/03/15 12:35:50
>>792
目的が漏洩対策ならいいんじゃない？＜生体認証
794:nobodyさん
07/03/15 13:00:52
>>792
と言われても、話の元の人はイントラ用とは言ってないわけだし、実際採用されたらどうかなあと思うわけで。
結局のところ、普通に当たり前のことをやっとけばいいと思うよ、としか言えないな。
一応法整備されたからパスワードだけかけておけばノーガードでもいんじゃねという話もある。
795:nobodyさん
07/03/15 13:58:14
>>787
＞それは、パスワード漏洩時の対策にはならんのではないか。
元ネタが同時ログインをキックしたいということだけであって、どこに問題がある？
796:nobodyさん
07/03/15 14:21:29
>>795
>>773
> 何かの拍子に ID/PW が漏れた場合、
> 同時にアクセスされたら漏洩発覚！としたかったんです。
>>771だけ見ればそんなもんかって感じだが。
797:nobodyさん
07/03/15 15:40:15
同時アクセス「ゆえに」漏洩発覚というロジックはむちゃくちゃだから
どうでもいいじゃん。同時アクセスキックできる方法だけ話してればいい。
798:711
07/03/15 17:59:45
元質問者です。
両方再ログイン促すので十分です。
それで漏洩か運用で分かると思うので。
なんだかいろいろと考えることが多いのですね ^^;
どこかにいい実装例はないでしょうか。
( コードがあると嬉しいです )
799:nobodyさん
07/03/15 18:50:39
>>798
仮に漏洩してたとして、同時アクセスと思える範疇でアクセスがある、漏洩と判断できる確率って少ないんじゃね。
あれこれ仕掛けてユーザビリティ低下でクレームが発生するほうが高そうに思えるのだが。
まぁどこまでコストをかけるかは措いといて、
>>775で「どうやってログアウトを...」って書いたけど、Cometならできるかもしんない。
Cometシステムを構築したことどころか、lingrさえしたことないので、
どこまで実用的に漏洩を察知できるシステムができるどうかは知らんが。
これでも、ユーザが会社でブラウザを開いたまま帰宅、自宅でログイン出来ねーって言うかもな。
800:nobodyさん
07/03/15 21:24:01 fuFXgue7
＞ユーザが会社でブラウザを開いたまま帰宅、自宅でログイン出来ねー
イントラ想定してしながらそうじゃないケース想定してるのが痛い
801:799
07/03/15 21:34:56
>>800
え～と、俺はイントラなんて想定しとらんが?
元質はイントラネタだったのか?
802:nobodyさん
07/03/15 21:35:01
Cometならできるかもしんないｗｗｗ
803:nobodyさん
07/03/15 22:37:02
昔、椅子に座ったらログイン、椅子から立ったらログアウト、
っていう仕組みを作ろうかとか考えたことある。
実用性が無さそうなんでやめたけど。
804:nobodyさん
07/03/15 22:44:26
あきらめたらそこでログアウトだよ
805:nobodyさん
07/03/15 23:51:51
>>801
元質はイントラじゃない
イントラ云々はおれが>>788で
「イントラだったからここまでやったけどそうでなければどれくらい手間をかけたもんかな」的に書いただけ
>>803
迂闊にトイレにも行けねーなｗ
806:nobodyさん
07/03/15 23:57:38
実際は、イントラ以外使えないというところではそんなもんだろ
807:nobodyさん
07/03/15 23:58:51 7hzpmvYO
でも同じユーザーが同時期にアクセスできないようにするってことは、魅力があるね。
なんか旨い方法ないのかな？
808:nobodyさん
07/03/16 00:07:36
IPとかUAは？
809:799
07/03/16 00:15:29
う～ん、ﾏｼﾞでCometで出来ない?
Cometって時間的にどのくらいコネクションを握ったままできるのかしらんだけど、
擬似サーバプッシュでクライアントからの返答(再リクエスト)がなければログアウト状態と判断できると思う。
保存期間なしのCookieも併用して。
Apacheにmod_cometみたいなモジュールが出てきたらいろいろ面白そうだけどなぁ。
で、PEARとはまったく関係ない話になってしまった。
810:nobodyさん
07/03/16 00:55:14
>>802が良いこと言ったな。
811:nobodyさん
07/03/16 00:56:45
プロセス単位じゃなくて、スレッド単位でコネクション維持してくれるモジュールが
無いと、すぐに鯖がパンクするな。
812:nobodyさん
07/03/16 04:10:01
後のログインを優先させれば解決
813:nobodyさん
07/03/16 07:13:07
>>812
おまえ脳みそ使ってないだろｗ
814:nobodyさん
07/03/16 09:00:07 tL5WlbtE
で無理やりPHPの話に戻すと、
URLﾘﾝｸ(hain.jp)
にFlashのSocketライブラリを利用してPHP（鯖）＋FLASH/JavaScript（客）で
通信を行うという話がのっている（socketjs→URLﾘﾝｸ(dev.dschini.org)）。
これが出来るならなんとかなるんじゃないの。
815:nobodyさん
07/03/16 09:32:57
>>814
Ajaxでいいじゃないか。
816:nobodyさん
07/03/16 15:00:47
>>807
利用できる端末を登録制にする。
登録は自分で出来るけど、登録用には別のパスワードを用意して、全てが漏れないと使えないようにする。
端末の登録が変更されると、指定したメールに通知。
たしかソニバンがこれ。
登録済み端末が操作されてしまうのは防げない。
817:nobodyさん
07/03/16 15:25:46
>>815
Ajaxは、クライアント側の制約（DHTML）がありすぎだからなあ
818:nobodyさん
07/03/16 15:27:39
>>816
「端末」の同定はどうしてるのだろう？＜ソニバン
819:nobodyさん
07/03/16 15:52:41
>>818
同じPCでブラウザ変えると別端末という認識をされた。
クッキーとかかな。
820:nobodyさん
07/03/16 16:48:41
>>798
＞元質問者です。
＞両方再ログイン促すので十分です
これ意味あるかな？
1.そもそも先にログインしている方が「正規ユーザ」とは限らない。
2仮にそうだとしても、.クラックした方が先に再ログインすることも出来る
実際は、こういう事態がおこったら、そのユーザアカウントは仮停止すべきでしょう。
821:nobodyさん
07/03/21 18:47:33 78nxSnEz
vistaでpearコマンド、CLIがntdll.dllのエラーで停止しない?
822:nobodyさん
07/03/22 14:53:02
sage
823:nobodyさん
07/03/23 14:24:37 cotQkCWi
すいません
PearでQuickFormを使ってページを作成しています。
controllerを使ってウィザード式にしたいのですが
前のページでデータベースからの検索結果（不特定多数）があり
その結果それぞれにリンクを貼りクリックするとその情報を持って
次のページに行きたいのです。
色々調べたのですがフォームボタンを使ったものしかなく
困ってます。
参考になるページなどありましたら教えてください
よろしくお願いいたします。
824:nobodyさん
07/03/23 18:09:38
それはQuickFormとかと関係ない。
a href 要素・属性で、POSTで送信したいってことでしょ？
javascriptを使えばいい。
’リンクでPOST’
とかググればすぐ
825:nobodyさん
07/03/25 05:11:07 2BiXNRYt
URLﾘﾝｸ(pear.php.net) や URLﾘﾝｸ(pear.php.net) に
アクセスしようとしてもできないのはなんで？
時間が悪いのかな？
826:nobodyさん
07/03/25 10:38:49
そうみたいよ。
今は普通にできるから。