【PHP】下らねぇ質問はここに 9
■ このスレッドは過去ログ倉庫に格納されています
PHPに関する質問スレです 前スレ 【PHP】下らねぇ質問はここに書き込みやがれ 8 http://mevius.5ch.net/test/read.cgi/tech/1489506082/ 次スレは>>980 以降 本文の1行目に以下を追加すること !extend:on:vvvvv:1000:512 VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured 更新履歴〜 みたいなページでSSI使ってたことはある これはこれで便利やしトリッキー言うほどじゃないだろ まあ今時としては、SSIみたいな挙動をするphpコード書くだけになるか public function Hoge($hoge) { return function () use ($hoge) { return $this->test_func($hoge); }; } こういうのって意味有りますか? クロージャのとこに$hogeを持ってきても実際には繋がりはないように見えるんすけど $var = Hoge($hoge) //$var = function($bar){ return $this->test_func($bar);} クロージャの$hogeと最初の引数の$hogeの繋がり クロージャになっても最初に渡された$hogeは生きてるんやな。。 知らなかった >>236 PHPを使ってるんだったら SSIの<!--#include...に該当する処理は 取り込み対象をPHPのコードとして評価したいならinclude、 文字列として評価したいならfile_get_contets()するだけの 1行で済む話 SSIはサーバー環境依存だし今どきSSIが有効になってる古いサーバーを これから先も使い続けるのか?という疑問もある SSIってJavaScriptもiframeタグもブラウザ標準ではなかったそれこそ10年以上前の遺物よな メンテしているperlのサイトで確か使ってたな phpで使おうと思うほど猛者じゃないので勘弁 PHPでerrnoを取得することはできますか? やりたいことは、ファイルまたはディレクトリの有無を確認しつつ、 falseだった場合は、ENOENTなのかEACCESなのか知りたいのです。 file_existsとis_readableを組み合わせるしかないですか? >>230 せっかくなので分かったことを報告。 SSI にせよ PHP の virtual にせよ apache のサブリクエストが発行される場合、元リクエストとサブリクエストのPHPのインスタンスは同一のものが使い回されるらしく、グローバル変数なんかは共通されるらしい。 恐らく define や include、出力バッファなんかも共有されてると思う。 それでいろいろ思いもよらない挙動を示すっぽい。 ということが分かったので、適当に回避した。 apacheの設定によるところもあるかもしれないけど、そこまで検証してない。 なんか普通の話だな グローバル変数なんて使ってたらそんなの当たり前だろ >>247 ユーザー定義のグローバル変数や名前空間をもたない定数なんかもう何年も使ったことないけど よく分かってないので、スマソ。 モジュール版PHP5.3環境で動かしていたのを、 @ モジュール版5.6環境に移行させる場合 A CGI版5.3環境に移行させる場合 @、Aともにソースコードの書き換えは必須なの? また、簡単なのはどっち? それだけじゃなんとも言えんよ… エスパーでも答えられんと思われ 上の話と同じでグローバル変数とか使ってるとかなら書き換える必要あるかもね 使われてるモジュールやライブラリが対応してるかどうかもあるし 同じ環境を用意して実際に動かしてテストするしかないと思う 5.6でサポートやめたり、推奨からは図したりしたものがあれば 良くて警告、悪くて動作せずとなる やってみないと分からないから、試験環境を作って試すのが最善 5.2.X⇒7.2.Xに以降した環境がいくつもあるけど PHPコンパイルで何度かこけた(コアに取り込まれて使えなくなってるオプションがあった)ぐらいで コードを手直しをした記憶が全くないなぁ 逆にどんな書き方をしてたら動かなくなるのやら… 開発を error_reporting=E_ALL(PHP5.4以前ならE_ALL|E_STRICT) でしてなかったりすると環境移行でエラー出まくったりするかもな 初心者はまずエラーを正しく出すところから学習しないとな >>248 同じインスタンスで動くならそりゃそうだろって話だけど、virtual はともかく SSI が同じインスタンスで動かすのが当たり前かと言われれば微妙じゃね? $_GET みたいなスーパーグローバルとかどうなっちゃうんだよって問題もあるし、実際出力バッファはまぜこぜになって使い物にならないわけだし。 わざわざ SSI でやるのなんて、他所の誰かが作った全く関係ないものを自分の処理と隔離してページ上に取り込みたいなんてケースだったりするわけで、隔離できないならあんまり意味が無いというか。 そういうものだということが分かってりゃやり方考えるからいいんだけど、なんでそうする?っていう仕様だと思う。 PHPそのものの問題じゃないであろうこと引っ張ってすまないけど。 前バージョンと同じように、必要なモジュール・ライブラリがロードされていて、 基本的な環境に差異がないのを前提とすれば、 あとは廃止変更された機能や関数が影響を受ける。 なので動かない場所が出てきて、書き換えが必要になる場合はあるが、 それはコードの1%にも満たないぐらいの量のはずだから、 大規模なアプリケーションでも書き換えに1日はかからないだろう。 >>256 > 他所の誰かが作った全く関係ないものを自分の処理と隔離してページ上に取り込みたい SSIを使う理由になってないしSSI以外の知識がないだけ サーバーの知識が多少ある人間なら今この時代にSSIを使うのがいかに馬鹿げているかすぐ分かる SSIもhtaccessも無駄にサーバーに負荷をかけわ、遅いわ、セキュリティリスクの管理もしにくわで何1つ良いことないから無効にしろと大昔に教わったな 結構最近でもSSIインジェクションで資生堂の小会社がが情報漏えい起こしてたけど資生堂みたいな大きなところが未だにSSI使ってることに驚いた includeしたいだけなら他にいくらでも代替案あるのにさ SSIインジェクションやらかすようなやつはSQLインジェクションだってやらかしかねないんだから、それはSSIを使わない理由としては弱いでしょ。 素人だからよく分かんないんだけど ssiでincludeするのとhtmlで<iframe> or phpでfile_get_contents するのは何が違うの? ssiを使う理由って何? >>261 旧来からのスタイルを踏襲しているとか、 SSIはPHP知らなくてもHTML(と言えるか微妙だが)分かれば使えるってのもあるかもね。 サイト全部がPHPじゃないし、みんながみんなPHP使えるわけじゃないからな。 PHP使うなら PHP の include しても file_get_contents しても、適用できるなら得られる結果は一緒でしょ。 >>261 使う理由は特にない 1.SSI/#include file|virtual="path"はpathの中身をそのまま取り込んだ結果を取り込んだ場所で出力する 2.<iframe src="url|local_path">は対象の出力をフレームとして取り込む 3.file_get_contents('url')はurlの出力を取り込む 4.file_get_contents('local_path')はlocal_pathの中身をそのまま取り込む 5.includeは対象を「PHPのコードとして評価する」 1 ≒ 2 ≒ 3 ≠ 4 ≠ 5 だと思っとけばいい includeとfile_get_contents()が等価なんてのは大嘘なので信じないよう SSIの#includeに該当する処理は、そのほとんどが<iframe>+αで片付く程度の低レベルの事しかしてないね 繰り返すけど今更使う必要性は全くない過去の遺物です include と file_get_contents が等価だなんて言ってないぞ。 別のコンテンツを差し込む方法として適用できるケースがあると言ってるだけで。 例えばページのヘッダやらフッタやらを別ファイルに浮かせたとして、それが include できるなら include で、file_get_contents できるなら file_get_contents で差し込めるだろ。 >>265 > PHP使うなら PHP の include しても file_get_contents しても、適用できるなら得られる結果は一緒 一緒じゃないでしょって話だと思う 実際全然違うし >>266 例えばただのHTMLファイルがあったとして、それを include した場合と file_get_contents 使って出力した場合とで得られる出力結果にどんな違いがあるの? もちろんただのHTMLじゃないものを扱おうとすれば、得たい出力を得るために適用できないこともあるよ。 >>263 の PHPのコードとして評価するというのも語弊があると思うよ。 パースはテキストとして始まるわけだから。 初心者も見てるだろうから実例を出しとく ・test.php ------------ test <?php echo $a; ------------ ・index.php ------------ <?php $a = 'hoge'; var_dump(file_get_contents('./test.php')); /* test <?php echo $a; */ var_dump(file_get_contents('http://localhost/test.php' )); /* test Notice: Undefined variable: a in...($aが定義されていないというエラー) */ include './test.php'; /* test hoge */ ------------ この違いを理解してるならこれ以上俺から言う事は何もない PHPを勉強している者ですが、 PHPを使ってお問い合わせフォームを作る際に気を付けるべきセキュリティ対策についてのアドバイスをください。 メールの送信までの流れは「入力」→「確認」→「送信」となりました。 入力・・・入力される文字の制限(メールアドレスの欄なら使用可能な文字以外でエラー) 確認・・・出力の前にhtmlspicialchars()を使い無害化 送信・・・? 参考になるサイトや書籍のアドバイスなどもいただけると嬉しいです。 よろしくお願いします。 >>270 とりあえず思い当たることをざっくり。 ・SQLインジェクション対策 ・セッションハイジャック対策 ・HTTPSの確認 ・管理者のうっかり対策 ・スパムメール基地化の防止 前2つはこの言葉と PHP で検索すれば出てくると思うけど、SQLインジェクション対策にはPDOのプリペアドステートメントとバインドを使うとか、セッションハイジャック対策は個人的には問い合わせフォーム程度ならセッションなんて使わずhiddenでたらい回しにするかな。 HTTPSの確認は、HTTPでアクセスされた場合に受け付けないとかHTTPSにリダイレクトするとかの施策だけど、シンプルなサーバ構成なら $_SERVER['HTTPS'] が 'on' かどうかを見ればいいものの、webサーバの前段に何か(AWS の ELBとか)入れてるとそれじゃダメなこともある。 開発前に HTTP と HTTPS でのアクセス時の違いを phpinfo を diff 取って確認しておくのがいいんじゃないかな。 管理者のうっかり対策ってのは、問い合わせ内容に悪意あるURLなんかが書かれていてもうっかり踏まないようにするとか。 悪意あるURLじゃなくても、管理画面なんかからリンクを直接踏めると referer とかで管理画面のURLが漏れることがある。 スパムメール基地ってのは、もし受け付け時にユーザーにメールを送信する場合、他人のメールアドレスを入力されるとそっちへメールが飛ぶことを悪用されること。 文面に悪意あるURLを書かれると、それを踏まされちゃうかもしれない。 対策はいろいろあると思うけど完璧な対策は難しく、どこかを妥協することになると思う(メール送るのやめるとか)。 >>270 です。 >>271 さん 詳細なレスをくださり、ありがとうございます。 今回いただいたアドバイスを元にセキュリティを強化していきます。 本当にありがとうございました。 >>272 こんなところで聞くだけじゃなく、本買ってちゃんと勉強した方がいいよ 得丸さんって有名な人が最近本出したから買って損はない >>270 です。 >>273 さん 書籍情報ありがとうございます。 独学なのでありがたいです。 >>274 ごめん、名前間違えてた 徳丸 浩 体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 脆弱性が生まれる原理と対策の実践 PHPがサンプルで使われてるので参考になると思うよ >>270 です。 >>275 さん 徳丸 浩ですね 了解しました。 重ね重ねありがとうございました。 練習なら色々気を遣うトレーニングになるからいいけど, 実際に公開する場合にはよく使われてるメールライブラリを使うべきだろうな >>278 スパムメール基地化に対しての対策とってるライブラリなんて見たこと無い。 正直、自動返信は鬼門だと思う >>279 それはライブラリでどうこうできる問題じゃなさそうだよね。 個別にトレードオフ見て仕様化してる。 送信されることを緩和するならボットチェック(と言うのか知らんが)入れるとか、本文の悪用防止ならメールに入力本文は転記しないとか入力本文中のURLを伏せて転記するとか、 あるいはそもそもメール送らないとか、悪用元が分かってるならIPアドレスチェックして内部処理変えるとか。 本文転記のニーズは高いから難しいのよね。 自動投稿系のスパムはハニーポットしかけるのが楽 <input type="text" name="mail" value=""> みたいなよくあるname値をもたせたダミーの<input>タグをcssとかで非表示にして GETやPOSTメソッドでnameの値が飛んできたらスパム扱いにするだけ 初心者でも簡単に実装できるのがメリット クラスAを継承したクラスA1、クラスA2を作りました クラスA1ではB1、クラスA2ではB2クラスをuse Bx as Bとして読み込み クラスAにクラスBを操作する処理を書けばクラスA1、A2に共通の処理を書かなくて済むかと思ったのですが、名前空間的にnew BとするとクラスAを基準としたパスで読み込もうとしてnot foundになってしまいます 親クラス側から子クラスで読み込む前提のクラスに対しての操作を書く方法はありますでしょうか? >>282 コード無いからエスパーするとinterface使え 少しマニアックな可能性はありますが シーサーブログへの自作エディタを作成したいと思っています。 プルダウン方式で時刻を簡単に選んだり その他を大分楽にすすめる事ができるのが目的です。 PHPでライブドアへの投稿ツールを少し作成してみたり PHP、pythonあたりを少しだけ知っている、というのが 現状の自分かと分析していますが ネットで少し検索してもシーサーブログへの投稿のためのプログラムは PHPであまり引っかかりませんでした。 最終的には、タイトル変更、カテゴリ選択、時刻設定、定型文の挿入あたりの出来る ツールを目指しているのですが、 スレッドのPHPとは離れますが もし良いツールが出来るならPerl、Rubyなどもチャレンジしてみるしかないのか、 と思うのですが、 現状、攻めれそうな言語、もしくは方法を・・ 本当にすみませんが、大まかなアドバイスでもいただけたら有難いです・・ よろしくお願いします。 >>285 結局APIをAPIの仕様に沿って叩くだけなんだから 言語なんか別に何でもいい SeesaaのAPIはXML-RPC互換らしいが XML-RPCを採用しているPHP製CMSで有名なのはWordPress だから情報は豊富にあるかと >>286 有難うございます。なるほど、そういう事ですか…。 確かにWordPressのそういう解説はある程度あると思われますし、 まずそこを自分も作って、それをシーサー向きにカスタマイズ、 という方向にもっていってみるのが得策ですかね。 プログラム等々色々しっかり理解できていないので 例えば、テストのワードプレスに投稿がうまくいっても それをシーサーに対応させる、その箇所でいかにも自分はつまずきそうですが… やってみようと思います!ありがとうございました! formからfileタイプでファイルを送信するとき、一緒にカスタムデータも渡したいんですが phpでカスタムデータを取得するにはどうすればいいんでしょうか カスタムデータはバックエンドやのうてフロントエンドで使うもんや html5の属性にdata-がつくってやつ? submitを動作のない通常のbuttonにしてjsでsubmitするようにして submitの前にjsでdata-要素を探して中身を hiddenフィールドに追加する処理書けば渡せる onsubmit時にやってもいいけどjavascriptオフだと想定したデータを受け取れない buttonにしてjsでsubmitすればjavascriptオフだとsubmit自体ができなくなるが そっちのほうが開発者には都合がいい 質問内容がPHPに関してではないし 回答もjavascriptを使用してと言うことだし Web製作板なら全般に渡って質疑しても良いけど プログラム板に設置したPHPスレとしては ちょっと違う感じを否めない webprogのほうは手取り足取りしてほしけりゃこっちこいって 初心者こっちに丸投げしてんだよな だから多少ズレててもしょうがない 難民受け入れる? 嫌がる人がいないなら、自分は反対はしない 今どきレガシーIE使ってるのとJavaScript使えない環境なんて考慮する必要ある? そういう人たちの考えを改めさせるためにも甘やかしてはだめだ あと広告ブロッカーなど入れてる人間にはおかえりいただくのだ IE11は新機能も追加されないのに 2025年10月までサポート続く 頭の固い奴がいつまでも使い続けそう そのレベルまで言うならサーバサイド使う必要性あるか? >>301 現状まだIE11はいいんだけど このまま取り残されるつもりなら害悪だね ITリテラシーのないユーザーが悪いわけではないが >>302 サーバサイドとクライアントサイドでは出来ることが違う 質問者のフォーム設計がクソであろうことは疑いの余地はないが >>300 で言いたかったことは 閲覧者様ありがとう!1人でも多くの閲覧者様に奴隷のように対応します ではなくサイト開設者側が閲覧者を選んでもいいということだ cakePHP3を使ってます。 mysqlに保存する場合、メールアドレスも暗号化した上で保存したほうがいいの? CakePHPの名前を出す意味が分からんが 動かす環境や設計思想によるとしか curl_setoptをphp.iniの中で設定したいのですが、そんなこと出来ますか? curl_setopt($ch, CURLOPT_SSL_CIPHER_LIST, 'ecdhe_ecdsa_aes_256_sha'); と同じ設定をiniファイルで設定できるかと curl.ssl_cipher_list="ecdhe_ecdsa_aes_256_sha" とcurl.iniに書いてみましたが、うまくいきませんでした iniファイルで設定するのはやはり無理なのでしょうか? そうですか VPSで動かしているTinyTinyRSSで、HTTPSのスクレイピング時にエラーが出ていて CURLOPT_SSL_CIPHER_LISTを設定すればいいということまでは分かったのですが コードを書き換えたとしてもアップデートで上書きされてしまう可能性があるので 設定ファイルでデフォルト値を設定できないかと思ったのですが、残念です・・ ありがとうございました >>310 自前のiniファイルを適当に用意し、parse_ini_file関数で読み込む それだとcurl呼び出し部分のコードを結局書き換えないとですよね? 設定ファイルで設定したいと言ったのは コードに手を加えずに挙動を変えたいという意味でした 目的じゃなくて手段です >>314 infoで出てくるcURLライブラリの情報出して cURLのビルド設定によっては楕円曲線をデフォルトで無効にしているケースがある(あった?) >>314 そこまで説明しなくても普通は>>310 読みゃ分かるよw そういう時は普通はラッパークラスを作る Adapterパターンとかでググるといい curl直接使うよりguzzle通じて使った方が良いよね? よっぽどシンプルなプログラムとかでも無い限り AWS SDK for PHPでも内部で使ってた 手続き型の書き方しかできないcURL関数群をラッピングして オブジェクト指向型のインターフェースを提供するライブラリは色々とあるから 実用的にはそっち使った方がいい(もちろん今ならguzzleが第一選択肢) 車輪の再発明をする必要はないが guzzleみたいにガッツリじゃなくて cURLのうすーいラッパークラスを作っとくと ちゃちゃっと何かしたい時に便利ではある >>312 を読んでないのか読んでて無視してるのか TinyTinyRSSを使うこと自体アレじゃねってのはあるけども TinyTinyRSSの中でguzzleを使った方がいいよねなんて話は誰もしてないかと ちょうどスクレイピングとかを勉強してる俺にはなんとタイムリーな話題 >>319 > cURLのうすーいラッパークラスを作っとくと > ちゃちゃっと何かしたい時に便利ではある もう少しkwsk >>322 例えば、http://example.com/ の出力結果を取りたいってだけなら file_get_contents('http://example.com/' ); だけでいいけど、もう少しだけ色々としたい時 例えば、POSTメソッドで「hage=fuge」を投げつつ ユーザーエージェント「Mona」、リファラ「http://2ch.net/ 」にした時の http://example.com/ のステータスコードを取りたいなんて時 $status = Curl_Wrapper::getInstance() ->requestPost('hage', 'fuge') ->setUserAgent('Mona') ->setReferer('http://2ch.net/' ) ->getStatusCode('http://example.com/' ); こんな風に書けるクラスを用意しとくと気持ちいいってだけの話 大した話じゃないから意味不明ならスルーでw >>321 うん >>323 なるほど やりたい事を書いた文章がそのままPHPのソースになってる感じですごく分かりやすい ->setUserAgent('Mona') ->setReferer('http://2ch.net/' ) こういう書き方ははじめて見た ;のつけ忘れではないよね? >>324 メソッドチェーン setうんたら系のメソッドで$thisを返すようにすればよい ただ(薄いwrapperだからアレだけど)getうんたら系のメソッドで副作用があるのはキモい >>324 $curl = new Curl_Wrapper; $curl->setUserAgent(); $curl->setReferer(); $status = $curl->getStatusCode(); 普通はこう書くけど面倒くさいから Curl_Wrapperクラス内のメソッド(setUserAgentやsetReferer)で Curl_Wrapper自身のインスタンス(PHPなら$this)をreturnする そのメソッドを鎖のように繋ぐから「メソッドチェーン」って呼ばれる 「PHP メソッドチェーン」とかでググってみるといい 上手く使えばすっきり書けるけどデメリットもあるのでケース・バイ・ケースで >>325 >>326 詳しくありがとう メソッドチェーンって呼び方がかっこいいな すごい勉強になった 質問です /aaa.php /bbb.php /ccc.php /ddd.php ... ばらばらに作って使うのと /xxx.php?aaa /xxx.php?bbb /xxx.php?ccc /xxx.php?ddd ... 一枚にまとめて使うのと どっちがパフォーマンスいいでしょうか? よろしくお願いします まとめても数百行程度なら、性能上は変わらないと思うが メンテナンスする上では、機能別に分けて置く方が楽かも 実体は別ファイルにしてエントリポイントからrouterで振り分ける バラした方が各スクリプトのサイズが小さいなら、物理的な読み取りとパースの分速くはなるんじゃね。 でもそんな細かいことよりメンテ性のいい方を選んだ方がいいんじゃないかな。 >>328 よく100万回ループ回した時の実行速度の差を比較したりする人がいるけど ハッキリいってやるだけ時間の無駄 そんな事を気にするならそもそもPHPなんか使わない方がいい webアプリのボトルネックというのは 大抵はDB周りだったりするわけで そのボトルネックを正確に計測し解決する手段を身につける事が遥かに大事 というかそんな事を気にしてるって時点で 何かしらのフレームワークは使ってないんだろうけど なぜ使わないの? >>332 フレームワークとか最近知ったばかりでよくわからん初心者です DBじゃなくてテキストファイルで処理するphpをああだこうだ弄って遊んでいて ふと思い付きで質問してみました PHPに関してフレームワーク使って良かったと思える場面て正直ほとんど無いな。 PHP自体がごった煮状態にしてまでいろいろできるようにしてある中で、フレームワークで実現しようとしている目標がいまいちわからん。 生産性にも得してるように思えないどころか、フレームワーク自体のメンテがだるい。 まあそれほどフレームワーク使ったわけでもなく、古くはSmarty、ちょっと前はCakePHP使ったくらいで、それも他所のベンダが作ったのを引き継いだくらいだから偏見に満ちてる可能性はある。 >>333 そか フレームワークに頼らずに作るのも DBに頼らずテキストベースで読み書きするのも とても良い経験にはなるから頑張って ただ○万回ループした時の実行時間の差を気にするなんてのは 本当にただの無駄でしかないから コードの見通しの良さとか管理のしやすさとか そっちを最優先で root.php?mode=aaa ⇒ mode/aaa.phpを読む root.php?mode=bbb ⇒ mode/bbb.phpを読む root.php?mode=ccc ⇒ mode/ccc.phpを読む なんて作り方もある 今これがベストだと思って設計しても どうせ1年後にはもっと良い設計が閃くさ だから色々と試してみるといい >>334 大規模開発をした経験がないとそうなるかもね PHPはとてもいい加減な言語なんで ”正しく”書くにはかなりの知識と経験が必要 ネット上のPHPコードの多くが糞なのを見てもよく分かる だから特定の規則さえ覚えれば”正しく”書ける フレームワークってのは大規模開発では必須になる あとは生産性の問題やね スクリプト言語なんてものはいかに短時間で簡単にものを生産するかが鍵なので 個人開発であっても何かしらのフレームワークは使え ってのが俺の意見 俺々マイクロフレームワークでもいいからさ ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる