wpdb prepareを使用する必要がありますか？

私はSQL wpdb->prepareが初めてで、作成したテーブルへの次のクエリに使用する必要があるかどうか疑問に思っています

global $wpdb;
$tablename = $wpdb->prefix . "my_custom_table";
$sql = "SELECT * FROM " . $tablename . " ORDER BY date_created DESC";
$resulst = $wpdb->get_results( $sql , ARRAY_A );

prepareここで使用する必要がありますか？どうすればいいですか？

乾杯

plugin-development mysql wpdb

— リチャード・スウィーニー
ソース

常に使用することをお勧めしますprepareが、主な用途はSQLインジェクション攻撃を防ぐことです。ユーザー/訪問者からの入力がないか、クエリに影響を与えないため、現在の例では問題になりません。

しかし、前に言ったように、それを使用するのがベストプラクティスであり、一度使用を開始したら停止することはないので、例では次のように使用できます。

global $wpdb;
$tablename = $wpdb->prefix . "my_custom_table";
$sql = $wpdb->prepare( "SELECT * FROM %s ORDER BY date_created DESC",$tablename );
$results = $wpdb->get_results( $sql , ARRAY_A );

それを使用する方法についての詳細を読むには、コーデックスに向かいます

— Bainternet
ソース

こんにちは@Bainternet、このような明確な説明に感謝します-何らかの理由でコードを試すと、空の配列が返されます。誤字をチェックし、ダブルチェックしました。準備されていないクエリを実行すると、配列が取得されます。なぜ機能していないのかわかりません。

— リチャードスウィーニー

奇数。私は同じコードを別のクエリで使用しようとしました：

$tablename = $wpdb->prefix . "my_custom_table"; $concert_id = 1;  $sql = "SELECT * FROM " . $tablename . " WHERE concert_id = %d LIMIT 1;";  $prep_sql = $wpdb->prepare( $sql, $concert_id );  $get_concerts = $wpdb->get_results( $prep_sql , ARRAY_A );

そしてそれはうまくいきます！なぜそうなるのか分かりません。しかし、私はいずれにせよ今すぐそれを手に入れます！

— リチャードスウィーニー

テーブル名を一重引用符で囲むと機能しません。通常のエスケープはバックティックを使用するため、クエリは次のようになりますSELECT * FROM `wp_my_custom_table`。二重引用符のサポートを有効にできますが、次のようになりますSELECT * FROM "wp_my_custom_table"。

— ヤンファブリー

私はこの答えに同意しません。関数がすでにすべてをエスケープしているのに、なぜエスケープする必要があるのですか？Wordpressはコアからのエスケープを削除することを決定すると思いますか？また、テーブル名をエスケープする必要はありません:)それはハードコードされており、あなたはそれが大丈夫だと知っているからです。私はこれが単なる例であることを知っていましたが、とにかくテーブル名をエスケープしてはいけません。

— Tommixoft 14年

@Tommixoft答えをもう一度読むと、実際に私が言ったのと同じことを言っており、テーブル名が例であることがわかります。

— Bainternet 14年

prepareを使用すると、SQLインジェクションの脆弱性からコードが保護されます。

以下は、使用するために変更する必要があるコードですprepare()。

global $wpdb;
$tablename = $wpdb->prefix . "my_custom_table";
$sql = $wpdb->prepare( "SELECT * FROM {$tablename} ORDER BY date_created DESC");
$resulst = $wpdb->get_results( $sql , ARRAY_A );

— ソフトワード
ソース

あなたの場合、SQLインジェクション攻撃は不可能です。post、get、request、cookieなどのユーザー入力を使用しないため、コードに追加の保護は必要ありません。

サーバーリソースを節約する必要がない場合は、複雑な機能を使用しないでください。

— サッシュアート
ソース