monazilla part 2

■スレッドリストへ戻る■ 全部 1- 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 最新50

823 ：デフォルトの名無しさん ：02/01/27 04:10: がいしゅつだが
Digest認証にしとけば生パスワード流れないっしょ
824 ：見物人 ：02/01/27 04:19: 過去ログなんかいらねえ。
古いスレはとっととあぼーんしてくれ。
825 ：デフォルトの名無しさん ：02/01/27 04:25: >>824
でもさー、たまたま何日か2chを見れない日があって、
その間にお気に入りのスレがあぼーんされてたら悲しくない？
マンガの最終巻(orドラマの最終回)だけ見損なった気分。
826 ：鼬害なのでsage ：02/01/27 04:40: 過去ログ消せ消せ団って、
批判要望板とかによく出没してるね。

嫌な過去でもあるの？(w
827 ：デフォルトの名無しさん ：02/01/27 08:41: >>826
見ないからじゃないのぉ～？見ないからじゃないのぉ～？見ないからじゃないのぉ～？
見ないからじゃないのぉ～？見ないからじゃないのぉ～？見ないからじゃないのぉ～？
見ないからじゃないのぉ～？見ないからじゃないのぉ～？見ないからじゃないのぉ～？
828 ：デフォルトの名無しさん ：02/01/27 09:03: 過去ログ全消去したら２ｃｈの価値は今の半分くらいになると思う
829 ：デフォルトの名無しさん ：02/01/27 09:36: >828
もっと下がるかもね。
830 ：デフォルトの名無しさん ：02/01/27 09:39: 有料検索はじめたら、みみずんにはやめてもらうことになる、
みたいなこと平気でいえる脳味噌の持ち主じゃなきゃ、
２ちゃんは出来ないって事だよな。
831 ：デフォルトの名無しさん ：02/01/27 09:51: みみずんさんが検索だけ外せばいいのでは？
過去ログ保管庫としてもあそこは重要な場所だし、正直あの検索は
もともと使い物にならなかったし(w
832 ：デフォルトの名無しさん ：02/01/27 10:01: すっかり、政治レイヤのスレになったね‥‥
833 ：デフォルトの名無しさん ：02/01/27 10:07: そんなに過去ログって大事か？ほとんど見ないからよく分からんが。
全消去しても２ｃｈの価値が半分以下になるとは思えん・・・。
現状のスレで楽しければそれでいい。
834 ：デフォルトの名無しさん ：02/01/27 10:17: >>833
人によって利用の仕方が違うからね
過去ログが大事な人もいれば大事じゃない人もいる
835 ：デフォルトの名無しさん ：02/01/27 12:01: 俺は現在の生な情報を得るのが主な使いかただな。
そういや過去ログみることってほとんどないや。
836 ：デフォルトの名無しさん ：02/01/27 13:30: プロトコルを非公開にしてもすぐ破られそうなもんだが。。
RSA かなんかで Challenge/Response 認証すりゃいいじゃん、と
思うのはおれだけ? IDを与えられるかわりに、ローカルで
秘密鍵・公開鍵ペアをつくって公開鍵のほうを2chに登録するときに
手数料をとればいいと思うんだけど。パスはネットワーク上には
一切流れなくなるわけだし、鍵の長さだって 512ビットもあればよい。
それとも dolib 作ってる奴が厨房でできないのだろうか?
837 ：デフォルトの名無しさん ：02/01/27 13:38: 【覚え書き】
・現在のログイン処理はクリアテキストのパスワードをGETメソッドで送るという
　セキュリティのカケラもないことをしているので、プロキシには意図的に対応
　させていません。
838 ：デフォルトの名無しさん ：02/01/27 13:55: >>836
どーなんかねぇ。
もしかしたら dolib.dll 自体の方式の模索というよりは、
dolib.dll を使うにあたっての周囲の状況の模索をしているだけの
段階なのかもしれない。
839 ：デフォルトの名無しさん ：02/01/27 14:21: >>836
＞思うのはおれだけ?
↑こういう書き方をするのは、屈折した人間に多いと思うのはオラだけ？

まぁdolib 作ってる奴が厨房だと思うのならMLに入りなされ。
んで君の考える認証方法を高らかに発表しなされ。（失笑されると思うが）
レベル的には、ひろゆき程度で二つ星と。★★☆☆☆
840 ：デフォルトの名無しさん ：02/01/27 14:23: >839
ｻｸｼｬﾊｹｰﾝ（・∀・）
841 ：デフォルトの名無しさん ：02/01/27 15:35: >>839
＞＞思うのはおれだけ?
＞↑こういう書き方をするのは、屈折した人間に多いと思うのはオラだけ？
自己紹介?
842 ：デフォルトの名無しさん ：02/01/27 15:43: >>839
> んで君の考える認証方法を高らかに発表しなされ。（失笑されると思うが）

まさか今の方式が最良だとでも思ってたのか？
他のに移行するまでの繋ぎじゃなかったのか…

こいつがマジ作者なら勘弁して欲しい
843 ：836 ：02/01/27 15:57: > まぁdolib 作ってる奴が厨房だと思うのならMLに入りなされ。

べつに入ってもいいんですが…

> んで君の考える認証方法を高らかに発表しなされ。（失笑されると思うが）

>>836 の説明では不十分なんですか?
まああれだけじゃコードは書けまいが、基本的なことはわかるでしょうに。
すでにそのこと自体が何事かを物語っているように思うのだが。
もしあれが失笑されるというなら、どこがどうおかしいのか
教えていただけると助かります。マジで。
844 ：デフォルトの名無しさん ：02/01/27 16:27: >>843
はげどう
845 ：デフォルトの名無しさん ：02/01/27 16:32: サーバーの負荷さえ考えなければ、836みたいな方法はいいと思うよ。
それに、金を取ればサーバーは増強できるんだから、負荷については考えなくて良いし。

とにかく、APOPでもDESでもSSLでもRSAでもなんでもいいから、
既にある程度完成されているオープンな技術を応用して、
たびたび仕様変更しなくても良いようにしてもらえると、一ユーザとしてはうれしいな。
846 ：845 ：02/01/27 16:33: あげちまった。スマソ。
847 ：想像力なしさん ：02/01/27 19:03: >>815 >>017 >>819
現段階では、futen.cgiは、chocoサーバにあるのは、403 Forbidden になる

 >>816
それはないみたい
848 ：想像力なしさん ：02/01/27 19:06: >>845
しかし、今回は、すべてhttpもしくはhttps上でやる必要がありそうだ
849 ：デフォルトの名無しさん ：02/01/27 19:19: datに落ちる条件を教えてよってば！頼むから。
850 ：名無し ：02/01/27 19:20: >>849
1000まで逝ったり、全然書き込まれてなくて、
新しいスレがたっていくと、古い順からdat落ちじゃなかったかなぁ？
851 ：デフォルトの名無しさん ：02/01/27 20:43: >>849
初心者板か、２ｃｈのＦＡＱでも逝けや、ｺﾞﾙｧ！！！

・・・と、お決まりの煽りを入れておいて・・・と。ウザいので答える。

>>850
「最終書き込み」が古い順、ね。
鯖ごとにスレッドの数の上限が決まっていて、それを超えるとdat落ちが起こる可能性が出て来る。
今までは、600スレッドあったら500まで減らす、というやりかただったが、
最近（でもないか？）は下限を超えていれば550とかの中途半端な数でも容赦なく落ちる。
dat落ちが起こりうる条件は以上の通りだが、タイミング自体はユーザには一切知らされない。
852 ：デフォルトの名無しさん ：02/01/27 20:55: 980を超えてるスレも。>>851
853 ：デフォルトの名無しさん ：02/01/27 21:14: ネットワークが盗聴されてIDとPASSが漏れる，みたいな話を
してるけど，心配しなくてもちゃんと別のところから漏れる
って(w

いずれにしろ，2重アクセスがあって，正式なユーザから苦情
があれば，切込隊長あたりがｺﾞﾙｧするんだから，ネットワーク
レベルではダダ漏れでもそう変わりは無いと思うが．

ていうか，DLLでのIDの暗号化って結局あるのかな？
854 ：デフォルトの名無しさん ：02/01/27 21:19: >>852
980 を越えてるスレが優先的に dat に落とされて、その後に最終書き込みが
古い順で落ちてるような感じ。
855 ：デフォルトの名無しさん ：02/01/27 21:20: いや、つかDLLで隠さなきゃならん認証方法なんて
使わんで、DLL不要にしてください、ってことだろ
856 ：デフォルトの名無しさん ：02/01/27 21:27: それよりも、ヘッダが完全でないと書き込みできないのがウザい。
857 ：デフォルトの名無しさん ：02/01/27 21:31: >>853
なんか >>822の言うように他のマシンでは使えないような細工が
されそうな気がしてきたけど、やったら不満爆発だろうな…。
俺はノートPCでも2ch見てるからID二つ買えなんてことになったら嫌だし。
858 ：デフォルトの名無しさん ：02/01/27 22:41: datスレの閲覧が認証方式になったのは
毎日datを総ざらいしていくﾔｼ（企業）が居るからそいつをブロックしようって事だろ。
で、それと同時に課金をやろうとしたんだろ？

このへん
 >>541-545
859 ：デフォルトの名無しさん ：02/01/27 23:15: 金取る以上は、金払っていない人間でも見られる状況はマズイと
思ってるんでしょ。だから認証を厳しくする、と。
2ちゃんねら相手にID売ったら2秒で共有される可能性はかなり高いしね。
860 ：デフォルトの名無しさん ：02/01/27 23:44: 掲示板運営サイドがそれで(一時的にであれ)報酬を得たり、
金を出さないユーザから閲覧機会を奪ったりするという前提が
あるのであれば、有益な情報をわざわざそんな所に書こうとは
思わないんじゃないの？

少なくとも俺は書こうとは思わない。

dat読み有料化したら、それでも書こうと思えるものは、
ログ流れしても一向に構わん類のネタ、AA、ジョーク、etc.
くらいのもんだろうな。
861 ：デフォルトの名無しさん ：02/01/27 23:48: >>860
baka
862 ：デフォルトの名無しさん ：02/01/28 00:04: でも、文章は書いた本人に著作人格権や著作使用権があるのに
それを譲渡する契約もしてない相手がそれで商売するってのは
ちょっとなぁ。

こちらが書き込んだ情報に対して課金するんじゃなくて広告収入で
儲けるとかならいいんだけど。
863 ：デフォルトの名無しさん ：02/01/28 00:07: ログは無料。
検索＆ゲットする手段は有料ってことじゃ？
864 ：デフォルトの名無しさん ：02/01/28 00:17: >>863
「HTML化待ち」のログ(有料)を2ちゃん側に押さえられるのが痛いな．
便利なツールに金を払うのは個人の自由だが，情報の作為的な隠蔽を
して，枯渇感(？)をあおるのはちょっとね…．

まぁ，これが今回のオイスター作戦のキモだと思うんだがいかがだろ
うか？バッチ処理で機械にやらせるべき仕事を，あたかも人間がやっ
ているようにしているところが，どうも引っかかる．

当然，ツール利用者(ヘビーユーザー)への課金が第1の目的なんだろう
けど，ツールのダウンロード数から算出したアクティブな利用者の人数
だけでは台所をまかないきれないと踏んだのだろうか？
865 ：デフォルトの名無しさん ：02/01/28 00:19: >>862
その書き込んだ情報に「アクセスする手段」のひとつから金取るってだけで
別に著作権とかなんの関係も無いし。
866 ：デフォルトの名無しさん ：02/01/28 00:21: >>864
何にせよオイスター作戦程度では採算取れないから心配するな（ｗ
867 ：デフォルトの名無しさん ：02/01/28 00:23: HTML化待ちのdatを有料にするなら、HTML化の期間をはっきりさせてほしいよね。
dat落ちしてから2ヶ月はdat2状態で、以後はHTML化されるとか。
同じ金払って、ある板はHTML化が早くて別の板は遅いとかだと公平じゃない。
868 ：デフォルトの名無しさん ：02/01/28 00:24: >>862
匿名のメリットを活かして楽しく遊んでいるわけだから，著作人
格権に関しては放棄すべきだと思う(出来ないんだっけ?）．

それが嫌だったら書き込みの最後に，
)c( Copylight 本名
とでもかくべきでしょう．
869 ：デフォルトの名無しさん ：02/01/28 00:27: >>866
採算が取れなくなると，さらに厳しく「有益な書き込みを閲覧する
為に小額決済」とかになっちゃうよ．
870 ：デフォルトの名無しさん ：02/01/28 00:31: >>868
いずれにしても本人の証明はできないだろうから、訴えることもできないよね。
871 ：デフォルトの名無しさん ：02/01/28 00:32: ログ取りは read.cgi から、取って来たログはP2Pで
共有、の最低クライアント書こうと思ってるんだけど、
これ公開したら叩かれるんだろうなー。
872 ：デフォルトの名無しさん ：02/01/28 00:33: >>865

送信可能化権も著作権者のものですよ。
873 ：デフォルトの名無しさん ：02/01/28 00:35: >>871

召喚します。
http://pc.2ch.net/test/read.cgi/tech/1011719933/l50
874 ：デフォルトの名無しさん ：02/01/28 00:38: >>869
そうなったら2chが廃れるだけ。
875 ：デフォルトの名無しさん ：02/01/28 00:51: >>871
オレは応援する．

ただHTMLのパースはある時突然虚しくなるから気をつけろ．
876 ：デフォルトの名無しさん ：02/01/28 00:51: >>872
送信可能化権はサーバにアップロードする権利であって、既にアップロード
されているものに規制をするのはまた別の問題。
877 ：デフォルトの名無しさん ：02/01/28 01:02: なんで2chそれ自体のalternativeを作ろうと考えないのかね。
対症療法なんか、やっても虚しいだけじゃん。
878 ：デフォルトの名無しさん ：02/01/28 01:05: >871
ああ、やってくれ。
実現できたら俺はそのP2Pサーバからものすごい勢いでDOMることにするから、
せめてBフレッツで鯖はたててくれ。
879 ：836 ：02/01/28 01:08: 結局 >>839 はまともに答えられないんでしょーか。
しょうがないので、ぼくが思いついた答えを書きましょう。
>>845 も言ってますけど、もし RSA を使うとなるとサーバに
結構な負荷がかかるでしょうね。1セッションで何分も持つなら
話は別だけど、リクエスト毎に認証を行う方式だとするとかなり重くなります。
有料ユーザの数にもよるが、1分間に数百回といった頻度でやられたら
おそらく認証専用のサーバがいるかもしれません。
それと、RSA なんかを使うと実装はやっぱり手間がかかるという点。
OpenSSL 使えばいいでしょうけど、厨房には無理でしょう。

で、負荷を軽くするために別の方法はどうかというと、APOP もそれなりに
軽くていいんですが、これって最初の一回はどうにかして生パスワードを
渡さなけりゃいけないと思うので、OTP はどうでしょうか?
これについては安全性もよく研究されているし、資料もあります。
コードもそんなに難しくない。以下のところへいけばRFCもs/key実装も
手に入ります。
http://www.ietf.org/html.charters/otp-charter.html

あーおれって親切だなー。それにしても
ML ではこんな (知らないことは何でも失笑で済ませるような) 人々ばかり
なんだろうか。ますます厨房の集まりっぽく思えて仕方ないのだが。
880 ：デフォルトの名無しさん ：02/01/28 01:24: ｸｽｸｽ
881 ：デフォルトの名無しさん ：02/01/28 02:03: 書き込んだ後に、著作権が云々出るようになってる。
882 ：デフォルトの名無しさん ：02/01/28 04:36: >881
それってmonazillaツールでも見られたほうがいいような。
883 ：デフォルトの名無しさん ：02/01/28 04:46: >>882
そうだね。
ところで、著作権云々の文章自体の URL ってどっかにあるのかな。
884 ：デフォルトの名無しさん ：02/01/28 06:33: ん？出ないよ？
885 ：デフォルトの名無しさん ：02/01/28 06:49: cookie 消して試してみ。
886 ：デフォルトの名無しさん ：02/01/28 07:25: Rubyいれてみ試してみ。
887 ：これ？ ：02/01/28 07:31: 書きこみ確認

名前：名無し
E-mail：
内容：
　逝ってよし
　オマエモナー

投稿確認
・投稿された内容はコピー、保存、引用、転載等される場合があります。
・投稿に関して発生する責任は全て投稿者に帰します。

変更する場合は戻るボタンで戻って書き直して下さい。(cookieを設定するとこの画面はでなくなります。)
～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
>883
出力はbbs.cgiがやってる模様。
888 ：デフォルトの名無しさん ：02/01/28 07:48: ・投稿された内容はコピー、保存、引用、転載等される場合があります。
・投稿に関して発生する責任は全て投稿者に帰します。

これはダメでしょう・・・。

投稿された内容をコピー、保存、引用、転載等した結果、
その投稿文に関して発生した責任は、内容をコピー、保存、
引用、転載した者に帰するのが、正しい法解釈。
889 ：デフォルトの名無しさん ：02/01/28 08:16: なんか微妙な文面だけど。
たぶん上と下の文章は別の問題として書いてあるんだと思う。
順序逆にしたほうがいいのかも。

ところで、何故にCookie無効のときだけ出るんだろ…。
（Cookie無効だとIPでも記録しとくのかな）
890 ：デフォルトの名無しさん ：02/01/28 08:29: >>887
> 出力はbbs.cgiがやってる模様。
それはわかるのだが、生データをどっかから取って来れないとツール側で同意
文章を用意する事になるので文面が変わったりしたときに面倒だなあ、、、と。

>>889
cookie がある→以前投稿したことがある→すでに同意してる
ということなのかな。イマイチだと思う。
891 ：デフォルトの名無しさん ：02/01/28 08:32: >>879
他のことは知らないんで１点だけ。
APOPで生パスワードを渡すことは無いのでわ？まさにその部分を
暗号化する仕組みだと思うんだけど。APOPで問題になるのは
もっと別の点でそ。
メールそのものを暗号化する仕組みだと思ってる？
892 ：デフォルトの名無しさん ：02/01/28 08:44: >>890
でも、この程度ならまだ共通認識というか常識の範囲内の注意書きだから
特に表示する必要ないと思う。
たとえば今後2chがログで商売を始めるとして、著作権の問題をクリアする
ために「書き込んだ内容の権利は2chに帰属します」とか表示されるように
なったら問題だけど。（ただ、悪意のある書き込みにまで権利と責任を持つ
ことになるから、それはしないようなことを隊長が言ってた気がする）
893 ：デフォルトの名無しさん ：02/01/28 09:02: >>891
まさにそのとおり。
APOPは、パスワード『だけ』を暗号化するものだから、メール本文は平文そのまま。

APOPはパスワードを暗号化してサーバに送信を行う機能で、
具体的にはAPOPを使用した場合は、POPサーバに接続した場合に毎回違う文字列が表示されるので、
APOPクライアントはその文字列を受け取り、その後ろにパスワードを入れ、
それをMD5にて暗号処理し、あわせたものをはじめてサーバに送信します。
これによってネットワーク上にプレーンパスワードを吐き出さないようにしています。
894 ：デフォルトの名無しさん ：02/01/28 09:17: >>888-890,>>892 ・・・・・・・・・・・。

http://teri.2ch.net/accuse/kako/1008/10083/1008331197.html

638 名前：ひろゆき ◆L3IpNS4A 投稿日：02/01/16 14:39 ID:TGBxViBh
　　　投稿確認
　　　・投稿された内容はコピー、保存、引用、転載等される場合があります。
　　　・投稿に関して発生する責任は全て投稿者に帰します。
　　　・猪木の闘魂伝説はまだまだ続きます。

　　　ってのにする予定だったんですが、泣く泣くあきらめました。
895 ：デフォルトの名無しさん ：02/01/28 09:35: >>879
＞結局 >>839 はまともに答えられないんでしょーか。
＞しょうがないので、ぼくが思いついた答えを書きましょう。
お前がMLに参加して
「お前らは厨房だから考えつかないと思うがなぁ、俺が思うに…（云々）」
とかなんとか言っちゃってよ。いやマジでマジで。
そしたら「ガイシュツ」や「話を過去に戻すな」とか言われるだけかと。
そういうレスさえなければ、それこそ失笑されているかと思われ。
知ったか発言も程々にね。思いっきりアホな子に見えるよ。
896 ：デフォルトの名無しさん ：02/01/28 09:45: 話を過去に戻すな
DLLソースが公開されたないのは作者が
アホってことで決着はついたんだから
897 ：デフォルトの名無しさん ：02/01/28 09:47: >>895

煽ることしかできないんだったら帰れ
898 ：デフォルトの名無しさん ：02/01/28 10:11: このスレで最も問題なのは電波さんが多い事。
批判要望板からの流入かな？
899 ：デフォルトの名無しさん ：02/01/28 10:14: 苦労してMLに入ったものの、内容がぜんぜん理解できなかった厨房が
荒らしにきてるとおもわれ。

>>895 とかね(笑）
900 ：900ｹﾞﾄｰ ：02/01/28 10:31: >批判要望板からの流入かな？
人が多いのも、痛し痒しだな。
901 ：デフォルトの名無しさん ：02/01/28 11:20: ↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
アホっす！アホっす！（ﾌﾟﾌﾟ
真性のアホっす！！！
真性のアホが現れたっす！（ﾜﾗ
大変っす！こんなアホ見たことないっす！（爆
驚きっす！驚愕っす！愕然っす！呆然っす！大ニュースっす！
このスレッドにこんなアホがカキコするなんて驚きっす！
こんなアホ2ch始って以来っす！
信じられないっす！（笑
ビックリっす！お笑いっす！
人間国宝級のアホっす！世界遺産級のアホっす！（藁
アホの坂田もビックリっす！ジミー大西もビックリっす！
えらいことっす！大変っす！騒然っす！
アホっす！アホっす！
真性のアホっす！！！
アンビリーバボーっす！アメージィングっす！ファンタスティックっす！
みんなを呼んでくるっす！他の板のみんなも呼んでくるっす！
902 ：デフォルトの名無しさん ：02/01/28 11:37: 一瞬、901に一行一行「そういうことにしたい」とか
「そんなに怖がらなくてもー」とか日下部式の
レスが思い浮かんだ。俺もかなり重傷だな。
903 ：デフォルトの名無しさん ：02/01/28 12:53: >902
void void(void);
904 ：デフォルトの名無しさん ：02/01/28 13:17: >879
OTPでやる場合、アカウントを共有されないしくみを考えてくれ。
つまり、セッションが続いてる間（明示的なセッション終了か、一定時間）、サーバ
が発行したキーと対象IPアドレスを結びつける仕組み。
サーバ側にキーとIPアドレスを結びつけたDBおく場合は、２ｃｈのすべてのサーバ
で、そのDBを同期させることも忘れないように。レンタルサーバなので、勝手に
MySQL入れるとかいうのは無し。

>891
879が言ってる最初の一回ってのは生パスワードをユーザーに知らせるときの
こと。メールで知らせるにしても、そのメールを送るときには生パスがネットに流れる。
発行を受けるユーザーはPGPの使用を強制して、ユーザーの公開鍵で暗号化して
メールで送ればいいが、そこまでする必要もないだろう。どこかで妥協が必要だと思う。
905 ：デフォルトの名無しさん ：02/01/28 13:24: >>904
最初の１回、生パスワードをユーザに知らせるときは
SSLなウェブページに表示してやるんじゃダメなの？
もともと、ID申し込みページはSSLなページでしょ？
906 ：904 ：02/01/28 17:55: 確かに、パスワードの配布はそれでよさそう。
でも、パスワードなくしました、再発行してくださいが多くなりそうだ。

>904の前半はユーザーのIPアドレスを2chkey（全サーバで共通）で暗号化
したものをSessionIDにしてユーザーにchallengeとして渡し、あとは、
APOPみたいにSessionIDをユーザーのPCでuserkeyで暗号化して
2ch鯖にresponseとして返せばいいような気がした。
IPアドレスが同じ限りセッションが無期限に有効なのが難点だが、
SessionIDを作るときにタイムスタンプも種にして暗号化すればよさそう。

と思ったが、IPが変わって認証要求がきたときに古いSessionIDを無効化できんな。
だめだ。
907 ：デフォルトの名無しさん ：02/01/28 19:47: >>906
> IPアドレスが同じ限りセッションが無期限に有効なのが難点だが、
串を共有してる時も問題だ。
908 ：デフォルトの名無しさん ：02/01/28 20:39: >>906
パスワード無くしたら、もう一回金払って再発行にすりゃいいじゃん。
そんなの、無くした自分の責任でしょ。

で、IDは、64.71.145.43-20020128-203156みたな感じでIPアドレスと発行年月日そのものにすれば、
第三者への配布も抑止できるのではと。
もし、ID/PASSを配布されても、誰が配布したか追っていけるしね。

公開プロキシは、たいてい、SSLを通さないようになっていると思うし、
プロバイダの都合でプロキシ必須の場合は、SSLが通るようになっている代わりに、ちゃんとログ取っているだろう。

BitCashもWebMoneyも、オンライン販売しているから、支払方法はそれを使ってもらうとして
SSLを使えるブラウザのない環境とか、SSLを通さない社内LANとかって、結構あるもの？
909 ：かぽえら ：02/01/28 22:27: で、dat落ちの基準（書き込みが1週間止まったら落ち）とか、
datからhtml化までの期間とか、明示するんだよね？

まぁ、年額3000円程度ならすらっとID取ると思うけどね。
910 ：デフォルトの名無しさん ：02/01/28 22:39: 関係者様

金額の問題でない。支払いの方法を工夫して欲しい。
ローソンロッピーをキボンヌ。

極端な例：ドルやペソで送金すれっつーシェアウェア。
911 ：８４９ ：02/01/28 23:20: >850 >851 >852 >854
亀だが、ありがと。
要するにメインテナンスをまめにしる！ってことですね。
912 ：デフォルトの名無しさん ：02/01/28 23:43: 支払いはひろゆきに手渡し．
913 ：デフォルトの名無しさん ：02/01/28 23:47: >>909
金とるのにルールが無きゃ、そりゃ契約違反となるべ？
914 ：879 ：02/01/29 06:55: >>904
SessionID に開始時間を埋めこんでおいて、
1時間ぐらいたったら再度セッション確立を要求するってのは
単純すぎるかしらん。

最初に、これまでに出てきたことをまとめておこう:

　a. ユーザの認証情報 (SSLで登録) はサーバ間で共有されている。
　b. でも、動的に変化する情報を複数のサーバで共有はできない。
　　→ サーバ側ではセッション管理はできない。
　c. したがって、SessionID 自体がセッションに関する情報をすべて
　　　含んでいなければならない。
　　→ 最低限、ユーザの IP とセッション開始時刻は必要。
　d. valid な SessionID を生成できるのはサーバだけでなければならない
　　　(第三者は偽装不可能)。
　　→ サーバしか知らない鍵で、なんらかの暗号化を行う必要がある。
　e. valid な SessionID を受けとれるのは登録したユ－ザだけでなければならない
　　　(第三者は利用不可能)。
　　→ ユーザしか知らない鍵で、なんらかの暗号化を行う必要がある。

以上のことを考えると、最初にサーバからユーザに送られる
SessionID はサーバとユーザ両方の鍵をつかって2重に暗号化する必要がある。
915 ：879 ：02/01/29 06:57: ユーザの ID、IPアドレスをそれぞれ User, Addr とすると、
プロトコルは以下のようになる:

セッション確立:
　1. client:
　　　　User を送信。
　2. server:
UserPubKey = lookup(User)
　　　　SessionID = encrypt(ServerPrivKey, {random(), time(), Addr})
　　　　Challenge = encrypt(UserPubKey, SessionID) を送信。
　3. client:
　　　　SessionID = decrypt(UserPrivKey, Challenge)
　　　　を得てセッション確立。

セッション中:
　1. client:
　　　　SessionID とリクエストを送信。
　2. server:
　　　　{random(), t, a} = decrypt(ServerPubKey, SessionID)
　　　　(time() < t+TIMEOUT && a == Addr であれば valid なセッションであると
　　　　みなしてリクエストを処理する。

セッション終了:
　(開始後一定時間がたった SessionID は invalid とみなされるので、
　明示的なセッション終了手続きはない)

…ということで、1セッションごとにサーバ側でなんらかの復号をおこなう
必要があると思うんだけどどうだろう。結構重いんじゃないかと思うが、
ただサーバ側での暗号化・復号化はただ単に「サーバさえわかればいい」
レベルのものなんで、べつに RSA なんかをわざわざ使う必要は
ないのかもしれないな。ただしその場合はサーバ側のプログラムを
極秘にしておく必要があるし、なおかつその (valid な ID かどうかを判定する)
アルゴリズムが絶対に解析されないという自信がないとだめだろうね。

公開プロキシの問題は依然として残るな。
916 ：879 ：02/01/29 06:59: > …ということで、1セッションごとにサーバ側でなんらかの復号をおこなう

しつれい。「1リクエストごとに」ね。
917 ：デフォルトの名無しさん ：02/01/29 10:28: >>879
レベル低っ！出直してこい。
918 ：デフォルトの名無しさん ：02/01/29 10:43: >917
おまえのレベルの高い発言へリファレンスしてくれよ。
一言居士め。
919 ：917 ：02/01/29 12:17: >>918
ﾊｧ？意味わかんねぇ。
おまえも出直してこい！
920 ：デフォルトの名無しさん ：02/01/29 12:26: >>919
ということにしたいのですね? :)
921 ：917 ：02/01/29 13:05: >>920
ある意味、おまえもバカ。出直してこい！
922 ：日下部ネタをわかってない？ ：02/01/29 13:53: >>921
ということにしたいのですね。

238KB

新着レスの表示

スレッドリストへ戻る全部前100 次100 最新50

0ch BBS 2004-10-30