【PHP】下らねぇ質問はID出して書き込みやがれ 77
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
2008/12/08(月) 01:27:39ID:???過去スレ、関連スレ、FAQなどは>>2-10辺り
次スレは>>980が立てる。10分以内に立たない場合、宣言してから立てたい人が立てること。
◆前スレ
【PHP】下らねぇ質問はID出して書き込みやがれ 76
http://pc11.2ch.net/test/read.cgi/php/1226517332/
◆質問用テンプレ
【OS名】vine linux
【PHPのバージョン】php5.26
【連携ソフトウェア】mysql
【質問内容】
◆質問する時の注意
・ スレを上げて自分のIDを表示させること。（メール欄に何も記述しない。専ブラのsageチェックを外す）
・ 己の行った操作、変更などを詳しく明記すること。
・ エラーメッセージはそのまま表記すること。「エラーが出ます」だけでは回答不可。
・ 質問者として、態度をわきまえること。
・ 事前に関連リンクの公式マニュアル、リファレンス本くらいはちゃんと目を通しておくこと。
（PHPで最良の教本はこの公式マニュアル。市販の書籍は嘘が多いので鵜呑みにしない。）
◆質問後の注意
・2回目以降は最初に質問した際のレス番号を入れて、偽者防止に必ずIDを表示させること。
・解決しなくても回答をもらった場合はお礼を言うこと。
（荒らし、煽りは除く。煽られたときも、無闇に反論せずスルーすること。）
◆回答者への注意
・誰にレスしているのか分からないと困るので、>>(アンカー)をつけて回答すること。
【その他諸注意】
・SQL・正規表現・PEAR・テンプレート(Smarty等)・フレームワークは各該当スレへ
0682nobodyくん
2008/12/20(土) 19:53:44ID:tNhejazT0684nobodyさん
2008/12/20(土) 20:12:49ID:???2行目には同意。
そもそも、静的型付けってのはできる事を制限する思想だから、「できる事が多い」は別にメリットではない。
という前提で。宗教論争になるから機能比較はしたくないんだが。
・引数の型によって同名の別関数を呼ぶ、という事ができない。
同様に、引数の数だけが違う同名の関数を定義できない。
・整数をタイプヒントに使用できない。
これは早晩解決されるだろうが。
・配列などの宣言時に、中に入る型を指定できない。
・そもそも実行時までタイプヒントに違反している事を検出できない（関数がどの型を返すか明示できないため）。
PHPしか触れてない奴にも容易に想像が付くものだとこの程度。
総じて「型があるからこそ使える便利な機能」は抜け落ちている傾向がある。
これは言語仕様として型を動的に扱う以上、埋めようがない差異。埋めたら別言語になってしまうし、性能がガタ落ちする。
恐らくこういうのが「It's not PHP way.」という発言の真意だろう。
型を使ってプログラマを制約するのは、PHPの得意分野ではないし、PHPの目指す方向でもない。
0685nobodyさん
2008/12/20(土) 20:24:58ID:???強力という言葉が果たして合うかはわからないが信頼性は高いよ
静的型付けはコンパイル時と実行時の2回チェックが行われる
対して動的型付けは実行しないと問題点がわからない
もう1つ静的型付けにすることによって最適化が図れる
型の定義というのはメモリの確保であるから
書き手が意識して書くことができる
0686nobodyさん
2008/12/20(土) 20:27:47ID:???目指す方向について詳しく。
0687nobodyさん
2008/12/20(土) 20:37:13ID:???0688nobodyさん
2008/12/20(土) 20:38:15ID:???どういう観点から明らかなの？
0690nobodyさん
2008/12/20(土) 21:26:13ID:???型が静的だと、変数が確保する領域のサイズがコンパイル時に分かる。
動的だと実行時まで分からない。後は分かるな。
静的言語に静的型付けを持つものが多い理由のひとつがここ。
0691nobodyさん
2008/12/20(土) 22:17:13ID:???初心者がしつもんできなくなるだろうから
さまざまな言語仕様について熱く語る闘技場
http://pc11.2ch.net/test/read.cgi/php/1228709756/
0692nobodyさん
2008/12/20(土) 23:10:55ID:5BlIZK9J<tr>
<td>id</td>
<td>name</td>
</tr>
<?php do { ?>
<tr>
<td><?php echo $row_rsLocations['id']; ?></td>
<td><?php echo $row_rsLocations['name']; ?></td>
</tr>
<?php } while ($row_rsLocations = mysql_fetch_assoc($rsLocations)); ?> ←ここ
</table>
”ここ”って行がエラーを吐きます
mysql_fetch_assoc(): 4 is not a valid MySQL result resource in
なぜでしょうか・・・・
0693nobodyさん
2008/12/20(土) 23:14:33ID:???$rsLocationsの中身を確認しましょう
$rsLocationsの中身がMySQLが返すリソースじゃないから
怒られてます
0694規模について質問した者
2008/12/20(土) 23:28:26ID:???なるほどある程度の大規模システムでもphpでパフォーマンスを損なう事無く
構築する事は可能なんですね。
ヤフー関連のＷＥＢシステムでそんなに思いと感じる事は無いですしね。
>>java と phpを比較して解説してくれた人
＠ＩＴのなんちゃって記事を書いている人より分かり易かったです。
それはそうと、自分は.NETマンセーな人間なので、個人的にはＷＥＢシステムは
ASP.net一本にしてくれればなぁ、と思ってます。
まぁ、ＷＥＢ系＋クラサバも全て.NET一本にしてしまえば色々とメリットがあると思うんですけどね。
俺の好きな言語の順序
ASP.net >> php >> Java
0695nobodyさん
2008/12/20(土) 23:29:43ID:???環境構築にもコード書くにもやたら面倒そうな印象だったんだが
0696nobodyさん
2008/12/20(土) 23:30:47ID:???0699nobodyさん
2008/12/21(日) 00:02:39ID:???if($hen != "")ってあるんですけど、これって＝の時？それとも＝で無い時？どっち？
!って良く解らないです。ビックリしてるわけじゃないと思いますが。
0703nobodyさん
2008/12/21(日) 00:19:31ID:???詳しく教えて欲しい。
0704nobodyさん
2008/12/21(日) 00:22:14ID:???0705nobodyさん
2008/12/21(日) 00:26:01ID:???処理のパフォーマンスを重視するなら、あり得ない選択。
0706nobodyさん
2008/12/21(日) 00:39:16ID:???0708nobodyさん
2008/12/21(日) 01:24:50ID:???ＰＣユーザの何割がWindowsを使ってると思ってるんだ。↑
0709nobodyさん
2008/12/21(日) 04:20:18ID:???0710nobodyさん
2008/12/21(日) 04:21:40ID:???0712nobodyさん
2008/12/21(日) 05:40:08ID:???0713nobodyさん
2008/12/21(日) 05:53:02ID:???a=b これは代入
0714nobodyさん
2008/12/21(日) 06:10:13ID:???* セキュリティに関する大切な警告なのに、マニュア
ルの後ろの方に書かれている。サンプルコードより前
じゃないと気がつかない人が多そう
* 「なぜ使用してはいけないか」が書かれていない。
なので、対策を読んでも OK の場合と NG の場合の
区別がつかない
0715nobodyさん
2008/12/21(日) 06:25:36ID:???これ結局、どっちなの？
PHPでは、一部のマルチバイトエンコーディングにお
いて、addslashes()を使っているとSQLインジェクション
が発生しかねないよ、はてどうしましょう、というお話。
Chris Shiflett 氏が仰ることでは、addslashes()は使わず
に、mysql_real_escape_string()を使いましょうと。そこへ I
lia Alshanetsky 氏が、いやいや、mysql_real_escape_stri
ng()でも駄目で、Prepared Statements を使いましょう、
と言っているような気がします。一方日本でもこの現象
について触れている文書があります。
0716nobodyさん
2008/12/21(日) 06:28:44ID:???Shift_JISを素直に使っている限り、
addslashes()は駄目(Chris Shiflett氏)、
mysql_real_escape_string() は駄目(Ilia Alshanetsky氏)、
一部のPrepared Statements すらも駄目(id:jrofbyrsさん)、
ということらしいです。
0717nobodyさん
2008/12/21(日) 08:40:48ID:???大手のケータイサイトでさえEUCで作って鯖でシフトジスに変換して出力してんのに
貧乏鯖でしか借りれない人達はがんばってシフトジス（笑）で年越してくださいな
0718nobodyさん
2008/12/21(日) 10:34:46ID:???SET NAMES sjis;等を実行した後に使うと
2バイト目の0x5C文字がエスケープされない
0719nobodyさん
2008/12/21(日) 10:35:19ID:???わけではない」というものがあるが、これは断定できない
ことを言うときの逃げ口上だってことを知っておいたほう
がよい。マスコミには許されるが、技術文書には許されな
い。技術文書なら、前提を明らかにした上でその前提の
上で何が言えるかを書くのであって、例外があるなら例
外を書くようにする。
セキュリティの解説で「どれも完全じゃないからいろいろや
っておこう」という表現が出てきたら、その著者は信頼す
るに値しないと判断してよい。書いてる当人がわかってい
ないから、問題を整理できていないから、そういう表現が
出てくる。
0720nobodyさん
2008/12/21(日) 10:37:30ID:???さっさとやめろ
0721nobodyさん
2008/12/21(日) 10:42:23ID:???0722nobodyさん
2008/12/21(日) 10:44:07ID:???0723nobodyさん
2008/12/21(日) 10:51:21ID:pZUxQjb7UTF-8は、全ての文字が3バイト掛かるんだよ。
サーバー負荷が大きいサイトなら、メモリーが圧迫されることになる。
インフラも含めてプログラミングするのは、真のプログラマーだろ。
そういう視点が抜けているように思うが。
0725nobodyさん
2008/12/21(日) 10:54:28ID:pZUxQjb7今更、EUCって何だよ。俺はCCNPだぞ。もっと考えろよ。
0726nobodyさん
2008/12/21(日) 10:57:12ID:???0727nobodyさん
2008/12/21(日) 12:10:15ID:???>技術文書なら、前提を明らかにした上でその前提の
>上で何が言えるかを書くのであって、例外があるなら例
>外を書くようにする。
これの根拠が示されておらず勝手に決め付けてる。
0728nobodyさん
2008/12/21(日) 12:30:16ID:VviuyWm4$a=" aaa ";
$b=" bbb ";
$c= $a.$b;
print $c;
print "<br>";
trim ($c);
print $c;
?>
なんかこれで、
全然トリムされてないんだけど？？？
0730nobodyさん
2008/12/21(日) 12:52:07ID:VviuyWm4あ、、、
代入しないとダメなんだ、、、
ありがと
0731nobodyさん
2008/12/21(日) 12:52:30ID:???0732nobodyさん
2008/12/21(日) 13:06:16ID:VviuyWm4basenameって日本語使えないの？
0733nobodyさん
2008/12/21(日) 13:07:05ID:???0735nobodyさん
2008/12/21(日) 15:28:56ID:???やっぱ不景気でカツカツな人が多いいの？かわいそうに。
0736nobodyさん
2008/12/21(日) 15:33:09ID:???0737nobodyさん
2008/12/21(日) 15:41:06ID:???0740nobodyさん
2008/12/21(日) 16:04:30ID:???0743nobodyさん
2008/12/21(日) 16:09:21ID:???http://info.2ch.net/guide/faq.html#C5
0745nobodyさん
2008/12/21(日) 22:25:03ID:BLufKTBe同じクラスのメンバやメソッドにアクセスする際に $this->
はつけた方がいいのでしょうか？
class A {
private $hoge;
private function foo() { }
public function bar() {
$hoge = 'なんたらかんたら';
$this->hoge = 'なんたらかんたら'; /* どっちいいの？ */
foo();
$this->foo(); /* どっちがいいの？ */
}
}
0746nobodyさん
2008/12/21(日) 22:37:42ID:???0748nobodyさん
2008/12/22(月) 01:52:46ID:???あと日本語のマルチバイトが３バイト使うってだけでUTF8の全てが３バイトじゃないよね？
信頼性と容量どっちを優先するかは好きにすりゃいい。
自分でよりよい案も出せず文句つけるだけの723には無理だけど。
0749nobodyさん
2008/12/22(月) 02:19:57ID:???帳票出力アプリ任せてたのに、出力データ取得条件が絶対に1件も持ってこない条件だった。
引継ぎ資料には「帳票が出ないのは整合性の取れたデータが無いためです。アプリの動作は問題ありません」
エビデンスのデータで再テスト行っても出力されず。
技術が無くて作業が進まず、それを隠すために逃げたんだろうな
0751nobodyさん
2008/12/22(月) 05:37:08ID:???「ニューヨークにはピアノの調律師は何人いるか？」
って質問されたら、答えられなくて発狂するの？
0753nobodyさん
2008/12/22(月) 06:07:29ID:???スレ違いな上に頭悪いな
0754nobodyさん
2008/12/22(月) 06:13:45ID:???質問されると発狂するじゃん
0755nobodyさん
2008/12/22(月) 06:24:37ID:???0756nobodyさん
2008/12/22(月) 06:31:15ID:???はてなにでも池
0757nobodyさん
2008/12/22(月) 08:53:52ID:Cwv0g3tMPECL::PDOのことなの？
0758nobodyさん
2008/12/22(月) 08:59:25ID:Cwv0g3tMmysqliと、
pear::DBと、
PEAR::MDB2と、
PECL::PDOと、
どれを使えばいいの？
0759nobodyさん
2008/12/22(月) 09:04:29ID:Cwv0g3tMmysqliと、
pear::DBと、
PEAR::MDBと
PEAR::MDB2と、
PECL::PDOと、
どれを使えばいいの？
0760nobodyさん
2008/12/22(月) 09:15:50ID:???使いやすさや開発の効率など機能の利便さを求めるならライブラリ
0761nobodyさん
2008/12/22(月) 09:20:53ID:Cwv0g3tMPDO一択かな
でもそれだと、mysqliが使えないんだけど、
みんな使ってないの？
0762nobodyさん
2008/12/22(月) 09:25:01ID:???0763nobodyさん
2008/12/22(月) 09:41:19ID:Cwv0g3tMmysql_real_escape_string でエスケープしなければ
いけないのか、それとも、しなくていいのか、という議論ですが、
http://labs.cybozu.co.jp/blog/hata/archives/2005-10-04-1.html
このページを読む限りだと、
（１）
PDO::query() でいきなりSQL文を実行する場合
↓
SQLインジェクションの可能性があるので、
自分でmysql_real_escape_stringしなければならない
（２）
prepare()して、execute()する場合、
↓
SQLインジェクション対策を自動的にしてくれる
↓
mysql_real_escape_string 不要
=--------------------------
この理解で合ってますか？
0764nobodyさん
2008/12/22(月) 09:57:12ID:???0765nobodyさん
2008/12/22(月) 09:57:50ID:Cwv0g3tMhtmlentitiesを使ってエスケープする」
という記事を読んだことがあるのですが、
これってマユツバですか？
0766nobodyさん
2008/12/22(月) 10:00:35ID:???あってる。というか、可能な時はいつでもprepareを使え。
DB接続のパフォーマンスがどうしても問題になる場合のみ、しぶしぶmysql関数。
それ以外の場合はPECL::PDO（現在はPECLではなく標準ライブラリ）。
きちんとクラス構成ができていれば、書き換えはそれほど手間ではないので、迷ったらとりあえずPDOで書く。
0767nobodyさん
2008/12/22(月) 10:14:36ID:???その本を燃やせ。というか、出版社を燃やせ。あり得ない。
「エスケープは、出力先に応じて適切なものを選ぶ」のが基本。
出力先はSQLなのだから、SQLとして安全になるようなエスケープを選ぶ必要がある。
DBに応じたエスケープ関数があるはずだからそれを使え。
たとえばMySQLならmysql_real_escape_string。SQLiteならsqlite_escape_string。
ttp://jp2.php.net/manual/ja/refs.database.php
とりあえずそれだと、'NULL OR TRUE'という入力には確実に無防備になる。
WHERE ID = $id
というプログラムに上記文字列がぶち込まれた時にどう動作するか考えてみるといい。
DROPやDELETE、UPDATEと組み合わせた文も上手くやれば発行可能かもしれん。
HTMLの実体参照はよりによってセミコロンを多用するしな。
ユーザー管理テーブルが書き換えられ、RDBMSのroot権限を奪取される事もじゅうぶんあり得る。
0768nobodyさん
2008/12/22(月) 10:15:12ID:???目的がSQLインジェクション対策でないからしなくていい
DBには生のデータを入れるのが基本
XSS等を意識するのは取り出す時
取り出す時に忘れるかもしれないから入れる時にエスケープする人もいるが
取り出す時にエスケープするのは当たり前なので
穴を防ぐ目的としてはいいかもしれないが根本的な解決にはなってない
0770nobodyさん
2008/12/22(月) 10:20:58ID:???0771nobodyさん
2008/12/22(月) 11:27:37ID:YHC8UPCZ画像キャプチャによるフォームの認証のセキュリティについて
画像キャプチャの下にhiddenでその画像キャプチャの値を設定し
認証の時にユーザが記述した値とhiddenの値を照らし合わせるという
やり方はセキュリティー的に問題がありますか？
以前どこかのサイトで
生成された画像キャプチャの値とidを一度データベースに書き込み
hiddenには値ではなくIDを設定、
認証時にそのIDからデータベース検索を行い認証するやり方
を目にし上のやり方はセキュリティ的に問題あるのかなと
ずっと気になっています。
わかりにくい説明ですいませんがアドバイスよろしくお願いします。
0772nobodyさん
2008/12/22(月) 11:29:20ID:???http://gimpo.2ch.net/test/read.cgi/wildplus/1229912492/
0773nobodyさん
2008/12/22(月) 11:31:17ID:???hiddenの値はHTMLのソース見れば
誰でも見れるよね。
つまり、スクリプト等でhiddenの値を
自動的に読み取るようにして、その値を
連続でぶちこまれたら、アカウント10万個とか
取られてしまうのではないかな？
0774nobodyさん
2008/12/22(月) 11:33:23ID:???金庫に鍵をさしっぱなしで一緒に置いておいても
問題がないならいいんじゃないの？
俺ならhiddenにいれずに簡易に済ませるならセッションに入れる
0775nobodyさん
2008/12/22(月) 11:37:46ID:???クッキーにも書き込んでるよね。
クッキーの値はクライアント側から読めるわけで、
もしアタッカーが、クッキーの値を読み取って、
自動的に連続入力するスクリプトをrubyで書いたら
やっぱりアカウント10万個とか取られてしまう。のでは？
0777nobodyさん
2008/12/22(月) 11:46:49ID:???すまん、高度すぎて言ってる意味が分らん
クッキーに入ってるのはセッションIDだろ？
画像チャプタってたいがい都度生成だろうからその都度ID変わるし
都度セッションに値セットするなら仮に違うセッションID使われたとしても
セッションの参照先に値が無いからとおらないだろ
0778nobodyさん
2008/12/22(月) 11:52:47ID:???だから安全性に問題があるとは書いている
0779nobodyさん
2008/12/22(月) 11:57:34ID:???0780771
2008/12/22(月) 12:01:59ID:???>>774
たくさんのアドバイスありがとうございます！
今独学でPHPを勉強してるんですが
アプリケーション作成時にXXSやSQLインジェクション、XSRFなど
どんな時にセキュリティを施せばいいかがすごい難しかったりします。
もう少し頑張って勉強してみます。
本当にありがとうございました！
0781nobodyさん
2008/12/22(月) 12:04:39ID:???ユーザーが手で入力すべき値と
同一なの？
■ このスレッドは過去ログ倉庫に格納されています