私は、OLAP サーバーによって部分的に強化される公開 Web プロジェクトに取り組んでいます。セキュリティの観点から、これを行ういくつかの方法を比較したかったのです。
私の最初のアイデアは、ユーザーの意図の表現を AJAX 経由で Web サーバーに渡し、Web サーバーに多くの入力検証を行わせ、適切な MDX 式を作成して OLAP サーバーに渡し、最後に OLAP の結果をプロキシすることでした。ブラウザ。(接線的には、これは jpivot が採用したアプローチのようです。たとえば、クリックして jpivot の例でテーブルにドリルダウンしたところ、サーバーに送信されたのは MDX ではなく、単純に x-www-form-urlencoded 文字列でした"wcf65768426.x=3&wcf65768426.y=3".)
対照的に、xmla4jsプロジェクトは、ファイアウォール ポートを開き、OLAP サーバーを XML/A 経由で世界 (または少なくとも特定の顧客) に公開し、クライアント側の JavaScript で MDX クエリを記述し、ブラウザを直接使用することを前提としているようです。 OLAP サーバーにヒットします。
私の直観的な反応は、2 番目のアプローチには非常に懐疑的です。誰かが私の OLAP サーバーに対して任意の MDX ステートメントを実行したとしても、悪いことは何も起こらないと思われます。私はまだ特に高度な MDX の学習者ではありませんが、これがリスクのない提案であることはすぐにはわかりません。少なくとも、誰かが非常に高価なクエリを開始したり、人々が簡単に利用できるようにすることを望んでいたよりも大きなデータセットのチャンクをダウンロードしたりする可能性があります。これは、人々が一般的に SQL サーバーで行うようなことではありません。私は当初、OLAP サーバーでも同様のことを行うべきではないことを示唆する同じ理由を考える傾向があります。
しかし、xmla4js の背後にいる人々は、クレイジーなセキュリティ リスクではないいくつかのユース ケースを念頭に置いていたと思います。そして、私はこれについて慎重に考えすぎている可能性があると思います.
より経験豊富な OLAP 関係者が、たとえば XML/A を介して OLAP サーバーに直接アクセスできるようにすることの賢明さについてコメントしたいと思いますか?