今年 (2020) のNext Stepの中で、Reactive Web Appのセキュリティセッションを聞いていて気になったので試してみました。
Reactive Web AppのAggreagateは最適化は開発者が自分で行わなければならず、セキュリティとパフォーマンスの観点で注意が必要とのこと。
環境情報
Personal Environment(Version 11.9.0 (Build 16900))
Service Studio(Version 11.8.7)
対象はReactive Web Appです。
テスト画面を用意
入力としてユーザーIDを受け取り、System EntityのUserレコードを取得する。
更にそのレコードのNameだけを画面にExpressionで表示しました。
サーバーサイドのAggregateであれば、OutSystemsによる最適化が行われ、使わない列（Name以外の列）はデータベースから取得されなくなるのですが……。
動作確認
Aggregateの条件等に使う変数もセキュリティ上注意
画面にぶら下げたAggregateは、初期表示時点で自動的に通信が走り取得されます。
非同期に呼ばれるために、画面のユーザーへの初期表示をブロックしないのがいいところ。
以下は、Chromeのデベロッパーツールで画面の通信を表示したところ。
Aggregateのフィルターに使っているUserIdが露出していますね。
HTTPSの通信なので、ユーザーが通信を見て、自分で任意のパラメータを渡して実行することはできてしまいますね。それを踏まえた設計にする必要があります。
結果は全列通信として返ってくる
以下は、Aggregateの通信のレスポンスに含まれるJSONを、JSON.parseで整形したもの。
User Entityの各列が全部出てしまっていますね。
ユーザーに見せたら行けない列が含まれないように注意しなければなりません。
列を隠す方法
Data Actionを使うことで解決しそうです。
Data ActionはScreenを右クリックし、「Fetch Data from Other Sources」を選択して作成します。
実装例：
画面入力のUserIdでUserを検索し、そのName列を出力変数にセットするだけのシンプルなAction。
Data ActionもAggregateと同様に通信が発生しますが、出力は、定義した出力変数のみです。
{"versionInfo":{"hasModuleVersionChanged":false,"hasApiVersionChanged":false},"data":{"Name":"テストユーザー"}}
設定したName出力だけが通信結果に出ていますね。
AggregateとData Actionのどちらを使うか？
基本はAggregateで良いと思います。
楽なので。
ただ、上で確認した特性を検討し、通信量が大きすぎる、セキュリティ上問題があるときにはData Actionを選ぶのが良いバランスではないかと。