bbs.cgi開発【WebProg板】
http://qb.2ch.net/test/read.cgi/jikken/1017071166/l50 2ちゃんねるの、bbs.cgiが、現在住民の手により作られているようです。 WebProg板でも、改良に役立つように、協力しませんか? >>35 phpって速いの?Perlより遅い気がするんだけど。 もしかして4.2xは速いの? >>36 mod_perlを使えばperl早いけど、 夜勤さんが使わないっていってるからなぁ。 ここでいいのかな トリップをメール欄に書くとおかしくなるの既出? 例えば、 名前[#hogehoge]メール欄[sage] →名前[ ◆/Re6aTC.]メール欄[sage] 名前[#hogehoge]メール欄[sage #hogehoge] →名前[ ◆jG/Re6aTC.]メール欄[sage] >>51 昨日からトリップ10桁になったんだよ メール欄とは無関係、メール欄の#以降が削除されるのは以前からの仕様 843 名前:夜勤 ★ 投稿日:02/11/14 15:22 ID:??? ??? ex , ex2 うまくいっているのかなぁ。 結局は、極端にいえば「もう一行も bbs.cgi にはコード追加できません」 ってことのような感じ、もちろんコードの内容にもよりますけど。 人が増えすぎて、コードを削らなきゃならない段階のようです。 解決策は (1) コードを削る。 (2) サーバを増設する。 ということでしょうが、どっちにしろ なんともかんとも さーおまいら出番ですよ。 >>55 夜勤が本気でそんなこと言ってるなら夜勤は真性のアフォ。 廃れてるなぁ。 誰かまじめにbbs.cgi開発する人いないの? >>61 真面目に開発している人はここには来ない罠。 お前らも暇な奴だなぁ(オレモナー っていうのは置いておいて、真面目にやっている人がいるなら ソースコードを提供してもいいよ。ただし再配布は禁止。 どうよ? あー、書き忘れたけれど興味あるならメールください。 フリーメールはNGです。 kigaru2@kigaru2.net (正体ばればれだなぁ。) >>65 hu8up@ww2.personal.ne.jp このメアドでよろしいでしょうか。 反応なしかyo! というか、面倒くなったのであと誰かよろ。 17氏の手に入った。 PATHINFO対応に改造するにはどうすればいいでつか? >>80 PATHINFO対応の他のBBSのソースを参考にしたら? 誰も突っ込みいれてない(´・ω・`) 一応動くんだけどなー。 誰か試してくれないかなー。 >>82 これはbbs.cgiをCで書いたやつとかですか? >>84 ダウンロードとコンパイル出来ました。 RedHat8です。 2ch初心者で申し訳無いんですけど、起動の方法がわかりません。 「ERROR:POSTしてください!」とか出ました。 コンパイルは適当に gcc -O2 -Wall -o bbs.cgi bbs.c とやればいいと思ふ。 >85 コンソールじゃなくて、CGIで起動しているんだよね? 環境変数がセットされてないのかなぁ? ごめん、よくわからないや^^; =""とかけばよいものを、="\0"と書くのがわからない。つーか静的なんだから自動的に0に初期化されるね。 staticのついていない関数の宣言はヘッダーファイルでした方がいいよ。 getenvがNULLを返さないかどうか監視しないと、strcmp等で悲惨な結果を生むことがあるだろう。例え(環境変数が)定義されていないはずがないと思っても。 もしもデコード対象の文字列が%で終わっていたらhex_packでまずいことになるかもね。hex_packでもきちんと文字列をチェックするか、decodeで2バイトstrncpyしてstrtolするといいよ。 mallocの戻り値をチェックしているところもあればしていないところも・・・ ところで、なんで*.hファイル(ヘッダーファイルだよね?)で関数の定義をしているの?(^_^;) >>85 書き込み用のフォームを用意していないからでしょ。直接bbs.cgiにアクセスすればそりゃあそのエラーが出るよ。 あとはPOSTじゃなくて小文字でpostだったりすると(そこは非標準関数のstrcasecmpを使えばうまくゆくね)。 >>87 コンソールから起動すれば多分Segmentation Faultが出るよ(理由は上述)。 >>87 SETTING.TXTが2chとは違うようだけど。 >88 突っ込み多謝ですm(_ _)m >ところで、なんで*.hファイル(ヘッダーファイルだよね?)で関数の定義をしているの?(^_^;) 他のコードを書くのに便利そうな関数は別ファイルにしようかなぁと。 それなら*.cにしる!ってことなんですけれども^^; >89 実験室仕様です。 2chに合わせるにはbbs.hを書き換えればいいと思います。 若干(でもないけど)テンポラリファイルの仕様も違うけど、 多分大丈夫^^; >>91 書き換えるのがめんどいのでSETTING.TXTもアップしてけろ SETTINT.TXTをパースする仕組みがないのでは。 更新したー。 88さんの指摘と、ID生成部分の修正、DATファイルの書き込み判定を追加。 >92 http://www90.sakura.ne.jp/ ~hoehoe/temp/kigaru/SETTING.TXT bbs.hの書き換えは俺も面倒い^^; >93 文字列を分割する処理だよね?<パース これのことではない? value = split( key, '=' ); split( value, '\n' ); 男爵Cも書けるのか… まぁそれはいいとしておいらはCはほとんど書けないから出番なしかなー。 ━―━―━―━―━―━―━―━―━[JR山崎駅(^^)]━―━―━―━―━―━―━―━―━― ∧_∧ ピュ.ー ( ^^ ) <これからも僕を応援して下さいね(^^)。 =〔~∪ ̄ ̄〕 = ◎――◎ 山崎渉 今だ!100ゲットォォォォ!!  ̄ ̄ ̄ ̄ ̄∨ ̄ ̄ ̄ (´´ ∧∧ ) (´⌒(´ ⊂(゚Д゚⊂⌒`つ≡≡≡(´⌒;;;≡≡≡  ̄ ̄ (´⌒(´⌒;; >>61 ワラタ ところで話変わるけど、携帯ゲーム機"プレイステーションポータブル(PSP) このPSPは、新規格UMD(ユニバーサルメディアディスク)というディスクを利用しており、そのサイズは直径6cmととても小さい(CDの半分程度)。 容量は1.8GBとなっている。 画面は4.5インチのTFT液晶で、480px x 272px(16:9)。MPEG4の再生やポリゴンも表示可能。外部端子として、USB2.0とメモリースティックコネクタが用意されているという。 この際、スク・エニもGBAからPSPに乗り換えたらどうでしょう。スク・エニの場合、PSPの方が実力を出しやすいような気がするんですが。 任天堂が携帯ゲーム機で圧倒的なシェアをもってるなら、スク・エニがそれを崩してみるのもおもしろいですし。かつて、PS人気の引き金となったFF7のように。 突然こんな事いいだしてすまそ・・ GBAと比べてみてどうなんでしょうか?(シェアのことは抜きで) __∧_∧_ |( ^^ )| <寝るぽ(^^) |\⌒⌒⌒\ \ |⌒⌒⌒~| 山崎渉 ~ ̄ ̄ ̄ ̄ ∧_∧ ∧_∧ ピュ.ー ( ・3・) ( ^^ ) <これからも僕たちを応援して下さいね(^^)。 =〔~∪ ̄ ̄ ̄∪ ̄ ̄〕 = ◎――――――◎ 山崎渉&ぼるじょあ (⌒V⌒) │ ^ ^ │<これからも僕を応援して下さいね(^^)。 ⊂| |つ (_)(_) 山崎パン 10月過ぎて暇だったら続きを頑張ってみようと思う。 Makefileも作らないと。 初めてPerl、CGIの勉強をしようと思うのですが、 皆様がこの本は良いと思ったのを、教えては 頂けないでしょうか。お願いします。 PHP使って、bzip2圧縮で転送量削減とかできないの? >>109 ガンバレ。 ところで、bzip2ってブラウザ対応してたっけ…? しんどいわぁ。 http://www.h4.dion.ne.jp/ ~sizzy99m/toybox/ch031107.tar.gz 一つ提案 ・広告対策/スクリプト荒らし対策もbbs.cgiに組み込んで欲しい ブラックリストを作って該当する物は排除といった感じで こんなもんで… http://www.h4.dion.ne.jp/ ~sizzy99m/toybox/ch031116.tar.gz おみとろんのばか・・・・ ttp://www111.sakura.ne.jp/~as/box/bbs.zip がんがって書き直してみた。 といっても、最小限の機能な上、限りなく怪しいソースだけど・・・。 限りなく怪しいソース第二弾。 ttp://www111.sakura.ne.jp/~as/src/bbs.zip ・トリップ、fusianasan、名無しさん に対応 ・デコード処理のバグ修正 ・Makefileのバグ修正 あいかわらずきれいなソースだね。 ただ、ヘッダに変数を置くのは止めたほうがいいと思われ。 >>124 言い方がキツイかもしれんがもう少しちゃんと組まないと利用者がとんでも ない被害をこうむるぞ。このままではたぶんコア吐きまくりになる。 バッファ・オーバーに対する緊張感が感じられない。 差し出がましいようだが製作中をチラっと紹介。 http://org.s38.xrea.com/bbs-mod.zip Apacheモジュール化を前提にしてるから回りくどい動作をしてるが 実用性を重視して設計してる。 現状はただのCGIでファイルでデータ保持してるがこれをApacheのメモリ 空間に置き換える。 そこそこの形にまとまれば軽くPerl版の100倍とかの速度になるんじゃないかな? >>124 くだらない煽りだと思われるかもしれないけど、もう少しCを勉強した方がいいよ。 >>129 つっこみナイス >>126 をApacheAPIに置き換える前に一応素のCGIとしても仕上げておこうと 思うが何か問題点があったら遠慮無しに叩いてもらえないだろうか。 >>126 結構うまく設計されてると思うけど。。 脆弱性があるなら、その部分を指摘してもらえるとありがたいと思うよ。 (ついでに私のもよろー。) ソース見たよ。 1Mのmallocって今時は普通? >>130 エンティティヘッダの区切りは \n じゃなくて \r\n にしろよ。 つかまだ完成度数%くらい?のものを叩けと言われてもなぁ… 細かい部分で自分で調べてもらうとして、 ・確保したメモリが確実に初期化されているという保証はあるのか? ・散在したリソースが整理して管理できてるか? ・冗長性の無い関数(strlenとかstrcat等)にそのままデータを入れていないか? っていう部分のポリシーが私の考え方と相違している。 危険性を多分に含んでいることは間違いない。 というより皆バラバラで作ってないで統合して分担できればいいんだが。 PM出現きのん >>132 改行コードは処理系が吸収してくれるはずなんだが。 ちなみに私の環境はWin2k3+Cygwin+GCC3.3とLinux2.4+GCC3.3 >>133 メモリの初期化はmemsetではだめなの? バッファオーバーフローを考えるなら、sprintfも危険ですよ。 strlenがだめなのは、ポインタにNULLが入っているかもしれないから? でもそれを言ったら、文字列操作系が全部だめって事になりそう。 >>135 データ型も保証されていた方がいいよね? stringまわりは手前できちんと例外処理しておけば済む事じゃない? サイニタイジングまわりをどうするかで思案中、、 regexでゴリっと正規表現使うかリクエスト・ボディの全バイトで ポインタ回してチェックするかどっちがいいだろう。 read.cgi ver 07.5.0 2024/04/24 Walang Kapalit ★ | Donguri System Team 5ちゃんねる