bbs.cgi再開発プロジェクト6

「書きこみ＆クッキー確認」の画面で、

[上記全てを承諾して書き込む]を押さずに、ブラウザの「戻る」機能で戻った場合、
次回以降、確認画面が出ずに、いきなり書き込めてしまいます。

このバグを悪用して、
俺は2chに書き込んではいるが、投稿確認に書かれた事項は承諾していない
と主張している困ったさんがいます。

簡単に直せるなら、直してもらえないでしょうか。
(そうすると、その人は書き込まなくなるでしょうから、
その人によるスレの話題の激しい脱線・罵り合いから、
スレが救われます。)

…

>>887
この話は前から出ているですね。

クッキー使っているわけですが、
＊技術的に＊、どうするのがいいんだべか。

[上記すべてを承諾して書き込む]じゃなくて、
ワンクリみたいに強制的に承諾させちゃえばいいんじゃない？ｗ

>>889
ポチっとな♪する前に食わせちゃっているからかな。
ポチっとな♪したあとに食べさせれば。。。

専ブラ側でも対応が必要になってきますね、この問題。

cookieがセットされていないなら承諾画面を出してformに
「bbs.cgiしか知らないテンポラリキー\0名前欄\0メールアドレス欄\0本文」
のハッシュ(md5かなにか?)をhiddenで入れておく。
でもって、実際の書き込み時にcookieをセットする、という形にならざるをえないのではないかと。
コスト削減のためにID算出と同じ種を使っても良いかも。

あ、リモホを入れていないのは携帯など毎回代わってしまうところを考慮に入れているからです。

対応策として・・・

・クッキーに承諾したフラグを入れる入れないの問題
・カキコボタンにtarget=newを仕込むようにして新しい開くようにしてブラウザでバックできなくする

なんかがおもいつきでかけますが・・・どうでしょう＞rootさん

>>894
馬鹿は引っ込んでろ

>>894
あっと、これの後者はw3mとかのテキストブラウザの場合には使えませんね・・・

テキストブラウザでどれだけカキコがあるかにもよると思いますが、
かなり多いようであればnewWindow案は棄却だと思います。

>>894
二番目は意味がないです。
このケースではブラウザのバックボタンがつかえるかどうかはさしたる意味を持ちません。
それだけなら元のwindowでもう一度書き込みボタンを押せば突破できてしまいます。

>>897
やっぱそうでしょうねぇ

やはりクッキーで承諾フラグをつけるのが望ましいということですか。

>>889
「この画面を表示させた後の書き込みは、すべて上記内容を承諾したものとみなします。」の
一文でも書き加えればいいと思われ。
で、そうするとボタンのキャプションがくどいから、ボタンは「書き込む」だけに変更。

大人の世界の内容なんだからシステムで解決できないなら
大人らしく承諾させる内容だけで勝負を。

>>899
ゴネ厨がそれで納得するかどうかは難しいと思います。
法的に無効な契約とされかねませんし。

ボタンを押させる事が重要なのか。
それなら表示されるのと同じ内容をどこかにまとめておいて、
初回は強制表示で、2回目以降は表示させなくする判定をread.cgiで読み取って
read.cgiの書き込みボタンのキャプションを「○○を承諾して書き込み」に置き換えて、
承諾させる内容をまとめたページへの○○ってリンクを表示させるとか。
専用ブラウザは使うこと自体承諾したようなものだと思うし。

今
U) bbs.cgiにアクセス
B) クッキーが無い
B) 確認画面＆クッキー発行（←表示した段階で発行！）
U)承諾ボタン押して送信 or 承諾ボタン押さず再度投稿
B) クッキーがある＆その他問題無し
B) 投稿完了


変更案
U) bbs.cgiにアクセス
B) クッキーが無い
B) 確認画面
U) 承諾ボタンを押す
B) もし（$FORM{'submit'} が "承諾云々"）なら {クッキー発行};
　　＆他各種投稿の処理
B) 投稿完了 or 何かエラー（←この返事の段階で発行！）


U = ユーザーの操作
B = bbs.cgiの処理

>>902
手元に承諾form同等の機能だけもったform置いたら突破できますよ、それ。

承諾するとは言ったがその利用規約を承諾した覚えは無い。
というのが通用するならね。

投稿規約を承諾するとは言ったが投稿規約を承諾した覚えは無い

の方が良いかな。

荒らし対策じゃないんで、投稿を防ぐ必要は無いんだよね、別に。
承諾さえされれば。

>>901
それで解決ですな

承諾したくない困った人は、これを改良したとしても、
前回は承諾フォームが出て承諾して書き込んだが、
今回は承諾フォームが出なかったので、表示されもしない内容に承諾できるわけがない、承諾していない
と言い出すと思う。

書き込む度に、確認・承諾フォームを表示しないようにするのは、なぜでしょう。
転送量が厳しいから、その節約のためでしょうか。

つまりクッキーを持ってると表示されない・書き込めるということなら、確認画面を表示したことを
クッキーで確認していることとクッキーとともに書き込むデータをそぅしんしてきたら
自動的に確認画面の内容を承諾したとみなすと確認画面に書いてしまえばいいかも。

つーかシステム側で対応しなくても　http://info.2ch.net/guide/　あたりに

2chは以下の条件を承諾した方のみ書き込み可能です。
・投稿者は、投稿に関して発生する責任が全て投稿者に帰すことを承諾します。
・投稿者は、話題と無関係な広告の投稿に関して、相応の費用を支払うことを承諾します

こんな感じの項目を作ればいいんじゃないの？

>>910
「そんなところまで見てないから知らなかった」とか嘘でも言う奴が出るから
いろいろ話し合ってるわけで、

【きちんと】設置された承諾画面を【わざわざ】回避する措置を講じる者は
その時点で、それ相応の責任を負うと言わざるを得ないかと 何というか

一つの方法は、承諾ボタンと同時に、拒否ボタンを作っておくことかな
そして「拒否ボタンを押す以外の否認の方法はありません」とでも書く。

いずれにせよ、言い逃れができない形にしないと、たとえば2ch発の
書籍を作ったりする際にいろいろ問題が発生してしまいそうな気もする。

まあ、建前で表示してるだけだし。

>>914
建前…っても、
http://www.itmedia.co.jp/news/bursts/0204/15/13.html
みたいに、書籍の出版・販売差し止めと賠償を認めた判決もあるし。
２ちゃんねる編の書籍もある以上、あまりないがしろにするのもどうかと。

「拒否ボタン」いいね。

通常の利用ではありえない方法で、規約に同意したかのような
データを送信して、そうであるから規約には同意していないのだ、
というのが通用するかどうかのな。
掲示板での議論ではなく、裁判で。

だから、まあ、建前を通していれば、不利になる事態は
そうは無いかな、とか。

そういった点で、通常の利用方法で、承諾しなくても承諾と
見なされている現状の改善が議題なわけだね。

承諾を回避して「そんな規約ｼﾗﾈ」というなら、拒否ボタンが
有ろうが無かろうが「そんな規約ｼﾗﾈ」なだけじゃん。

承諾メッセージは送信時に明示されるからいいとして、
裁判だと、「不具合があるのを知っていたにも関わらず対策をとらなかった」
式の判断で負けちゃう場合もありますよ。(心配性)

無理でなければ、なんらかの対策をとってほしいです。

承諾が必要な事を知りながら承諾を偽装した
と判断される事を心配しようよ。

荒らし対策と規約承諾を別々のクッキーで扱うのが面倒なら、
>>910をしつつ、投稿ボタンを全て「規約を承諾して書き込む」
にして、
もし ($FORM{'submit'} が "承諾云々" ではない) なら
{DispError("ＥＲＲＯＲ！","規約を承諾しないと投稿できません！");}
とか

専ブラが全滅だけどね。対応されるまで。

>>919
２ちゃんねる側が原告ならそれはありだけど、
被告側ではその意見はあまり意味がないな。

裁判ネタはこれ以上はスレ違い。

まあ、最近インスパイアのこともあってぴりぴりしてるから
これを機に徹底的に話し合って詰めた方がいいかもね。

>>920
専用ブラウザに対しては、UserAgentを見て従来通りの動作にする、というのはどうでしょう。
それを恒久策にするか、移行が済むまでにするかは、考えないといけないけど。

というか、あんなに防御していたのに、
スレッドが80超えちゃってたのがなぁ。

たぶんほとんど同時に何十本とスレ立て要求が来て、一気に追い込まれたんだと思われ。

何か、工夫が必要ですね。
スレ立て処理を実行中の船は、スレ立て処理をしないようにするとか。

グローバル変数でできるような気がするので、後で、考えてみよう。

>>923
Monazilla/2.0 ですか？

うーむ、同じスレッドキーのスレができないようにするところって、
激しくうーむなような。

どうしたの？

安易なロック方式として、スレを立てるところで
どこか(板単位で分離が好ましい？)にunixtime%閾値をファイル名として/dev/nullからでもsymlinkを貼ってみて、
失敗したらスレたて拒否。成功したら建てる。
ガベージコレクトのタイミングで一番新しいヤツ以外を削除するようにすればおっけ。
マルチスレッド/タスクを考慮するならこれが一番コストがかからないと思いますがどうです？
閾値はスレたての最大間隔ね。最小1秒になることもあるけど２スレ連続ならまぁ許容範囲内ではないかと。

ん？
Perlでのまともなlockの方法って、2年ほど前の再開発スレでrootさんが話題にしてましたよね。
そのレベルは脱した上で「うーむ」なことに成っているのだと解釈。

ほぼ同時にスレ立て要求→同時に数十本もスレ立っちゃった→スレッドキーみんな同じだ→しかも今夜が山だ

こんなところ？

今の bbs.cgi は、同じスレッドキーのやつが立たないようにするコードが
ちゃんと入っているです。

ようは、その実装方法がうーむだと。

do {
#サブジェクトがあれば新規スレなのでキーを現在に設定
$GB->{FORM}->{'key'} = $GB->{NOWTIME};
#.datファイルの設定
$DATAFILE = $GB->{DATPATH} . $GB->{FORM}->{'key'} . ".dat";

} while ( -e $DATAFILE ) ;

これって、$DATAFILE が既に存在してたら、無限ループに陥るんではないかしら。

不動楽さんが入れたやつですね


2ｃｈの動作報告はここで。 パート15
http://qb5.2ch.net/test/read.cgi/operate/1090485214/676-685

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
676 削除車 ★[sage] 04/11/01 23:25:56 ID:???
お疲れさまです。ちょっとご相談があります。

最近ニュース速報(VIP)が、非常に板飛び回数が多いです。
少しお話を窺ったところ、同じタイミングでスレが立ったときに合体を起こして、板が飛ぶみたいです。
お手数ですが、ちょっとcgiの方を確認していただけますか？
(それとも一般的なことで、VIPでたまたま多く発生しているだけなんでしょうか)

よろしくお願いします。


★板のスレ一覧復帰＆修正依頼21★
http://qb5.2ch.net/test/read.cgi/operate/1096548247/677-682


679 不動楽 ★ [sage] 04/11/02 00:45:12 ID:???
>>676
原因らしき個所は炙り出せたのですが、
その変数にからむ処理を上から眺めていきますので、
少しお時間を頂きたいです。

>(それとも一般的なことで、VIPでたまたま多く発生しているだけなんでしょうか)
ex7だけでなく、全板のbbs.cgiで同じことが起こる可能性があるようです。

684 root▲ ★ [sage] 04/11/02 02:08:27 ID:???
直すときには、安易な flock() は控えてほしいなぁと強くおながいしておきますです。

685 不動楽 ★ [sage] 04/11/02 02:13:12 ID:???
>>684
排他処理をしていないのが原因、というわけではないので大丈夫かと思うです。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

それについて書こうと思ったら、>>933 が。

それは、これですね。
上記よりも後、最後ところでやっているです。

if($GB->{FORM}->{'subject'} ne "" && -e $DATAFILE){
&DispError2($GB,"ＥＲＲＯＲ！","ＥＲＲＯＲ：板飛びそうなので、またの機会にどうぞ。。。");
}

ということで、それはクラシックさんが入れたところではないと思います。
昔からあったところだと思う。

＊以下推測＊

たぶん、昔は do 〜 while のところでもtime; していたんでしょう。
それなら、1秒経てば条件が変わります(ループを抜けるかは別)。

コピペみすった。

コメントつきなので、ほぼ間違いないです。

#==================================================
#　板飛び回避策
#==================================================
if($GB->{FORM}->{'subject'} ne "" && -e $DATAFILE){
&DispError2($GB,"ＥＲＲＯＲ！","ＥＲＲＯＲ：板飛びそうなので、またの機会にどうぞ。。。");
}

で、ここの制御を変えようと思うわけです。
安易に、

・live系は既にあったらごめんなさい
・他はスレッドキーを+1しながら、最大3回ぐらい試してみる

ってことにしようかなと。

BBS.CGI - 2005/10/26

$GB->{FORM}->{'key'} = &mumumuAllocateThreadKey($GB);
$DATAFILE = $GB->{DATPATH} . $GB->{FORM}->{'key'} . ".dat";

にした。
で、mumumu AllocateThreadKeyの中身は >>936 にしたつもり。

これで、

・bbs.cgi謎の暴走
・スレ立て混雑時にサーバ劇重

が、少しでも改善されるといいかなと。

スレッドキーは毎秒かわるんでしたっけ、でしたらこんなのはどうですか？

0. ロックの待ち番号を0で初期化

1. ロックの待ち番号をファイル名にして/dev/nullからsymlinkしてみる
　成功; → 6へ

2. ロックの待ち番号を1カウントアップ

3. ロックの待ち番号最大値を超えてるかチェック
　超えてる: → 建てたい人大杉表示にして諦める

4. 1秒まつ

5. 1へ

6. ロックの待ち番号が0か？
　はい: 9へ

7. 0.5秒待つ。

8. ロックの待ち番号-1をsymlinkしてみる
　失敗: → 7へ
　成功:
ロックの待ち番号をunlink
ロックの待ち番号を-1
6へ

9. スレたて処理

>>938
最初はそういうのを考えていたんですが、
1秒とか0.5秒とか待つのが、いやだったです。

スレッドキーは所詮本当の時間とあっている必要はないので、
・live系はごめんなさい
・通常系は 0 +1 +2 を試して、だめならごめんなさい

ぐらいのいい加減さにして、一刻も早くbbs.cgiに終わっていただくことにしました。

それだと、多台数とかからスレたて攻撃が同時に来たときにやっぱり被害が起こることは避けれないと思いますがどうでしょう。

計算量がO(n * log n)で収まれば収束しないか？

メモリ上に前回のスレキーを持たせたファイルを置いてそれを参照
とかは無理だろうしなぁ…
（素人案だし毎回読み込みとか（ｒｙ）

>>940
if ( ! -e datファイル ) {
return それでOKよん;
} elsif ( ! live系 ) {
for ( $i = 0; $i < $maxtries; $i++) {
スレッドキーを一つずつ増やして存在チェックし、なかったやつを
return これ使ってちょ;
}
&error(ごめんなさい);

って、なっています。

というわけでおっしゃるとおり、タイミングにより突破もありえます。

その場合は、>>935 でひっかかると。
でもそれにしても、ほんとうは完璧じゃないです。

雪だるま作戦では、このへんはバックエンドプロセスに依頼する形になるので、
その時に、きちんと対応することになるかなと。

てなわけで、-e でdatファイルの存在をチェックしていたり、
924の処理のところみたいに utime でdatのタイムスタンプ更新したりすることは
雪だるま環境ではそのままではむりぽなわけで、
そういったAPIを、入れ込んでほしいということなわけです。

一つ海外出張がキャンセルになってちょっと落ち着いたので、
このへんを、ぼちぼちあっちですすめようかなと。> SunOSさん

で、>>937 により「ごめんなさいリミッター第二弾」が実装されました。
どのくらい、発動しているんだろうか。

ん〜と，現在の bbsd ではスレ立て時の key をインクリメントしながら一定回数（現在は16）
リトライするようになっています．その際，open() を O_CREAT|O_EXCL フラグ付きで
呼び出しているため，ファイルの存在確認と生成はアトミックになっているはずです．

当初はスレ立て時の key としては bbsd 側の現在時刻を用いていましたが，
それだと headline に渡す key とのずれが生じる問題も発生したため，
現在は bbs.cgi 側から渡された key を使用するようになっています．
ただ，上記の key のインクリメントが発生するとやはりずれが生じることに
なるので，そこの調整をする仕組みが必要になりますかね．

単純に，bbsd 側ではリトライせず，key をインクリメントした上でのリトライは
bbs.cgi 側に任せるという形でもいいんですかね．同じ key を持つ dat が
存在した場合，bbsd は EEXIST に相当するエラーメッセージを返すことになるんで．

>>946-947
なるほど、なるほど。

bbsdについては、そのうちoperateにスレ立てるかも。
(いろんな意味でhtml化されてほしいし)

で、スレ立てのAPIの戻りで、実際に立ったスレのキー(だめなら-1)を、
戻すとかすればいいと思うです。>>946-947

ロックのループにはまった時はスレキーとかに使うUNIX時間なんかを
新たに取り直した方がよくね？
でもスレ立て処理は排他ロックさせずに複数同時進行してそうだし、
ロックのループが1秒待ちでもなさそうだから関係ない話か。

>>949 成功時は key，失敗時はエラーメッセージを返し，戻り値が
数値か文字列かを bbs.cgi 側で判定してもらうというのはどうでしょうか？
スレ立てが失敗する原因は EEXIST 以外にもあり得るので
（といっても実際はまれでしょうが），エラーの内容がわかった方が
異常発見もしやすくなるかと思いますし．

>>951
悪くないと思いますです。

週末あたりから、APIを詰めていくスレをoperateに立てようかと。
ほんじつは、ここまで。

ということで、立てました。

【雪だるま】bbsd⇔各cgi間のI/F仕様について考え・詰めていくスレッド
http://qb5.2ch.net/test/read.cgi/operate/1130482779/

ぼちぼち、すすめていこうかと。

てすと