アカウント名:
パスワード:
公式の説明で公開されたソースコード [bngames.net] は、サーバ側ではなくユーザーがダウンロードするアプリに含まれていたコードなので、アプリを逆コンパイルをすることで実際に使われていたコードであることを確認することができます。ただし、利用規約違反となる恐れがあります。
当該のコードは、実際にユーザーに配信されたアプリに含まれていた [imgur.com] ようなので、公表されたソースコードが使われており、それにより表示上の不具合が発生したというのは真実だと思われます。
ユーザー毎の確率操作が行われていたかは分かりませんが、仮に確率操作をしていたのだとしたら「出現キャラ提供割合」は完全な静的ページにするのが自然（不正が発覚しにくい）なので、今回の表示バグとは一切関係がありません。
ユーザーローカルで実行されるコードでSQLのWHERE節を%sで組み立てちゃうのかよ 典型的なSQLインクジェットの原因になるんじゃないの
当該コードについては、ソシャゲ事業者のサーバ上のデータベースではなく、ユーザーの端末のストレージ上に存在する SQLite データベースに接続して cache.cards テーブルからデータを取得しているだけなので、特に問題無いと思います。
内部で指定されたIDしか入らないと分かっているなら心配ご無用です。
今回はクライアントサイドのコードですし、仮にサーバーサイドでも元のデータがuint32_tのvectorなので、どう頑張っても"SQLインジェクション"はできません。(継承してたら可能性はゼロではありませんが、現実的ではない)Web業界は馬鹿の一つ覚えでSQLは全部プリペアードステートメントって風潮がありますが、ゲーム業界だとパフォーマンス重視でこう言う安全が保障されているところでは、自前で組み立てたりします。他にRDBMSであえてリレーションを貼らずにソフト側で処理したりとか、独自の最適化？が結構あります。こう言った最適化の積み重ねがの結果がモッサリ感有無になったりするので、結構重要です。
引数が整数なのでインジェクションの心配がない、という点については同意なんですが
必要最小限(キャッシュにないデータ)だけを取ってくるのではなく、キャッシュから取得済のIdも含めた全Idを IN に入れたSQLを発行するなんて、とても「パフォーマンス重視」とは思えないですね。パフォーマンスを気にするなら、キャッシュになかったIdだけを指定して取得するSQLを発行しないと。
単に「引数個数不定だからプリペーアドステートメントが使えないのでSQL文字列生成した」だけで「パフォーマンスのことなんか何も考えてないだけ」に一票入れたい。
なら数不定のwhere inをどうやって事前に組み立てるのか教えて欲しい。in文については、プリペアードステートメントで指定出来る方法を一向に提供しないDB側にも大いに問題あるよ
良く見るのは↓見たいな形を関数化してたりしますね。PHPです。(必要な箇所以外端折っています) $db->prepare('SELECT ～ WHERE id IN (' . str_repeat('?,', count($ids) - 1) . '?)')->execute($ids);str_repeatは第一引数を第二引数回繰り返しした文字列を返します。$id以外にある場合は少し面倒ですが、一度関数化してしまえば、それほど不満なく使えますよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
公表されたソースコードが使われていたことは恐らく真実 (スコア:3)
公式の説明で公開されたソースコード [bngames.net] は、サーバ側ではなくユーザーがダウンロードするアプリに含まれていたコードなので、アプリを逆コンパイルをすることで実際に使われていたコードであることを確認することができます。ただし、利用規約違反となる恐れがあります。
当該のコードは、実際にユーザーに配信されたアプリに含まれていた [imgur.com] ようなので、公表されたソースコードが使われており、それにより表示上の不具合が発生したというのは真実だと思われます。
ユーザー毎の確率操作が行われていたかは分かりませんが、仮に確率操作をしていたのだとしたら「出現キャラ提供割合」は完全な静的ページにするのが自然（不正が発覚しにくい）なので、今回の表示バグとは一切関係がありません。
Re: (スコア:0)
ユーザーローカルで実行されるコードでSQLのWHERE節を%sで組み立てちゃうのかよ
典型的なSQLインクジェットの原因になるんじゃないの
Re:公表されたソースコードが使われていたことは恐らく真実 (スコア:2)
当該コードについては、ソシャゲ事業者のサーバ上のデータベースではなく、ユーザーの端末のストレージ上に存在する SQLite データベースに接続して cache.cards テーブルからデータを取得しているだけなので、特に問題無いと思います。
Re: (スコア:0)
内部で指定されたIDしか入らないと分かっているなら心配ご無用です。
Re: (スコア:0)
今回はクライアントサイドのコードですし、仮にサーバーサイドでも元のデータがuint32_tのvectorなので、どう頑張っても"SQLインジェクション"はできません。(継承してたら可能性はゼロではありませんが、現実的ではない)
Web業界は馬鹿の一つ覚えでSQLは全部プリペアードステートメントって風潮がありますが、ゲーム業界だとパフォーマンス重視でこう言う安全が保障されているところでは、自前で組み立てたりします。
他にRDBMSであえてリレーションを貼らずにソフト側で処理したりとか、独自の最適化？が結構あります。
こう言った最適化の積み重ねがの結果がモッサリ感有無になったりするので、結構重要です。
Re:公表されたソースコードが使われていたことは恐らく真実 (スコア:1)
引数が整数なのでインジェクションの心配がない、という点については同意なんですが
必要最小限(キャッシュにないデータ)だけを取ってくるのではなく、キャッシュから取得済のIdも含めた全Idを IN に入れたSQLを発行するなんて、とても「パフォーマンス重視」とは思えないですね。パフォーマンスを気にするなら、キャッシュになかったIdだけを指定して取得するSQLを発行しないと。
単に「引数個数不定だからプリペーアドステートメントが使えないのでSQL文字列生成した」だけで「パフォーマンスのことなんか何も考えてないだけ」に一票入れたい。
Re: (スコア:0)
なら数不定のwhere inをどうやって事前に組み立てるのか教えて欲しい。
in文については、プリペアードステートメントで指定出来る方法を一向に提供しないDB側にも大いに問題あるよ
Re: (スコア:0)
良く見るのは↓見たいな形を関数化してたりしますね。
PHPです。(必要な箇所以外端折っています)
$db->prepare('SELECT ～ WHERE id IN (' . str_repeat('?,', count($ids) - 1) . '?)')->execute($ids);
str_repeatは第一引数を第二引数回繰り返しした文字列を返します。
$id以外にある場合は少し面倒ですが、一度関数化してしまえば、それほど不満なく使えますよ。