アカウント名:
パスワード:
公式の説明で公開されたソースコード [bngames.net] は、サーバ側ではなくユーザーがダウンロードするアプリに含まれていたコードなので、アプリを逆コンパイルをすることで実際に使われていたコードであることを確認することができます。ただし、利用規約違反となる恐れがあります。
当該のコードは、実際にユーザーに配信されたアプリに含まれていた [imgur.com] ようなので、公表さ
今回はクライアントサイドのコードですし、仮にサーバーサイドでも元のデータがuint32_tのvectorなので、どう頑張っても"SQLインジェクション"はできません。(継承してたら可能性はゼロではありませんが、現実的ではない)Web業界は馬鹿の一つ覚えでSQLは全部プリペアードステートメントって風潮がありますが、ゲーム業界だとパフォーマンス重視でこう言う安全が保障されているところでは、自前で組み立てたりします。他にRDBMSであえてリレーションを貼らずにソフト側で処理したりとか、独自の最適化?が結構あります。こう言った最適化の積み重ねがの結果がモッサリ感有無になったりするので、結構重要です。
引数が整数なのでインジェクションの心配がない、という点については同意なんですが
必要最小限(キャッシュにないデータ)だけを取ってくるのではなく、キャッシュから取得済のIdも含めた全Idを IN に入れたSQLを発行するなんて、とても「パフォーマンス重視」とは思えないですね。パフォーマンスを気にするなら、キャッシュになかったIdだけを指定して取得するSQLを発行しないと。
単に「引数個数不定だからプリペーアドステートメントが使えないのでSQL文字列生成した」だけで「パフォーマンスのことなんか何も考えてないだけ」に一票入れたい。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
公表されたソースコードが使われていたことは恐らく真実 (スコア:3)
公式の説明で公開されたソースコード [bngames.net] は、サーバ側ではなくユーザーがダウンロードするアプリに含まれていたコードなので、アプリを逆コンパイルをすることで実際に使われていたコードであることを確認することができます。ただし、利用規約違反となる恐れがあります。
当該のコードは、実際にユーザーに配信されたアプリに含まれていた [imgur.com] ようなので、公表さ
Re: (スコア:0)
ユーザーローカルで実行されるコードでSQLのWHERE節を%sで組み立てちゃうのかよ
典型的なSQLインクジェットの原因になるんじゃないの
Re: (スコア:0)
今回はクライアントサイドのコードですし、仮にサーバーサイドでも元のデータがuint32_tのvectorなので、どう頑張っても"SQLインジェクション"はできません。(継承してたら可能性はゼロではありませんが、現実的ではない)
Web業界は馬鹿の一つ覚えでSQLは全部プリペアードステートメントって風潮がありますが、ゲーム業界だとパフォーマンス重視でこう言う安全が保障されているところでは、自前で組み立てたりします。
他にRDBMSであえてリレーションを貼らずにソフト側で処理したりとか、独自の最適化?が結構あります。
こう言った最適化の積み重ねがの結果がモッサリ感有無になったりするので、結構重要です。
Re:公表されたソースコードが使われていたことは恐らく真実 (スコア:1)
引数が整数なのでインジェクションの心配がない、という点については同意なんですが
必要最小限(キャッシュにないデータ)だけを取ってくるのではなく、キャッシュから取得済のIdも含めた全Idを IN に入れたSQLを発行するなんて、とても「パフォーマンス重視」とは思えないですね。パフォーマンスを気にするなら、キャッシュになかったIdだけを指定して取得するSQLを発行しないと。
単に「引数個数不定だからプリペーアドステートメントが使えないのでSQL文字列生成した」だけで「パフォーマンスのことなんか何も考えてないだけ」に一票入れたい。