Lightning Locker Serviceのご紹介
米国のSalesforce Developers BlogでLockerServiceの情報が解禁されていましたので、日本語でも簡単にご紹介いたします。
Introducing The LockerService For Lightning Components
Lightning Locker Serviceとは
Salesforceは何よりもセキュリティと信頼性を重要視するサービスです。 そしてLightningコンポーネントに対するセキュリティを向上させる取り組みをLockerServiceと呼びます。 LockerServiceをリリースする背景には以下のような背景があります。
セキュリティ:
コンポーネントをXSSなどのセキュリティ脅威からから守る 他のコンポーネントで読み込まれたデータを制限なしに読み取るのを防ぐ コンポーネントがプライベートなAPIをコールするのを防ぐ
機能:
- クライアントサイドのAPIバージョニング*
- セキュリティレビューの高速化
- Javascriptでの開発環境の改善とセキュリティ向上
- ReactやAngularなどのサードパーティフレームワークの利用*
- 新しいセキュリティ機能やポリシーの容易な追加と削除
* 幾つかの機能は制限がかかっており、Winter’16以降のリリースとなる予定です
リリース時期
LockerServiceはSummer’16リリースより以下に従って有効になり始める予定です:
- Summer ’16リリース後にSignupした組織もしくは今までLightning Componentが存在しなかった組織 : LockerServiceは自動的に有効になります。
- Lightning Componentが既に存在している組織 : 重要な更新に表示され、管理者によってリリースの判断が行われます。
注意: LockerServiceは10月にリリースされる予定のWinter’16リリースで全ての組織で有効になる予定です。
LockerServiceの動作
例えば以下のようなサンプルのLightning アプリケーションがあり、4つのコンポーネントを持っています。 ボタン、天気を表示するWeatherコンポーネント(Mapのサブコンポーネントを内部に持つ)、そしてFinanceコンポーネントです。 これらのコンポーネントを例にLockerServiceの適用前後でどのように違うのかを見ていきます。 
LockerService適用前
LockerServiceの前は、DOMツリー及びJavascriptへのアクセスは以下の画像のようになっていました。 
この場合には以下のような問題が生じます:
- コンポーネント内のすべてのJSはDOM上にロードされた別のコンポーネント上のJS FunctionのCallが可能
- コンポーネント内のすべてのJSは非公開のプライベートLightning APIのCallが可能
- コンポーネント内のすべてのJSはDOMにアクセスし、他のコンポーネントがレンダリングしたデータを取得できる
- セキュリティレビューを通っていないコンポーネントはセキュリティの問題を抱えている可能性がある
LockerService適用後
同じコードで作られたLightning アプリケーションをLockerServiceで実行すると以下のようになります 
LockerServiceが有効になった場合は以下のように動作します:
- Salesforce製のcomponent及びJSは“システムモード” (オペレーティングシステムのシステムモードと似ています) にて動作し、すべてに対してフルアクセスを持ちます。
- カスタムコンポーネントは“ユーザーモード” で動作し、Documentやwindowオブジェクトにアクセスすることはできません。
- カスタムコンポーネントは代わりにカスタムDOM (“セキュアDOM”)にアクセスができ、カスタムWindowなどにアクセスできます。
- カスタムコンポーネントは他のコンンポーネントのDOMに対して同じ名前空間内であればアクセスできるが、対象コンポーネントのDOMが別の名前空間にある場合にはアクセスできません。例えば“Weather”コンポーネントのJSは“Map”コンポーネントのDOMにアクセス可能です。しかし“Finance”や“button”コンポーネントのDOMにアクセスすることはできません。
- さらに、カスタムコンポーネントは公開されたLightning JS APIにしかアクセスを許されず、Lightningフレームワークの“非公開” APIへアクセスすることはできません。
- “Use strict” 及びCSPが有効化され全てのコンポーネントのセキュリティが強制されます。
コード例
以下では、サンプルの ui:button 内にdivタグ (“c”名前空間) がラベルと共に配置されています。console.log はLockerServiceが有効になった画面で表示が異なります。カスタムコンポーネントのJSがdiv.parentNode.innerHTMLによってボタンのinnerHTMLを取得しようとDOMを走破しますが、このボタンは“ui”名前空間にいるため“undefined”となります。 
FAQ
既存のカスタムコンポーネントやコンポーネントExchangeのコンポーネントに何が起こりますか？
LockerServiceは背後で実行されます。公開されたAPIに対して変更は何もありません。しかしながらLockerServiceはモダンなJSの標準的及び新しいセキュリティルールの順守を強制します。そのため関連するコンポーネントを構築していた場合は、その標準に沿ってアップグレードを行う必要があります。その変更を容易に行うためのTipsやツールを提供する予定です。
Locker内で3rdパーティのライブラリ(React,Angularなど)を動作させることは可能ですか?
はい。静的リソースやセキュリティポリシーに許可された場所からそれらを読み込むことができます。
異なるコンポーネントは異なるバージョンの3rdパーティライブラリを利用できますか?
はい, LokerServiceは完全なwindow, documentなどにJSモジュールレベルアイソレーションを提供しますので、あなたのLocker (名前空間内) は自由です.
LockerはCDN上にホストされたライブラリにアクセスを許可してますか？ (例えばGoogle Maps)
2016年の冬のリリースにてこのセキュリティポリシーをオープンにすることができる予定となっています。
LockerはsandboxのためのiFrameを利用していますか？
いいえ – あなたのコードはアプリケーション内の他のコンポーネントと同じようにブラウザウィンドウ内で直接動作します。
アプリケーションイベントはlocker内でSandbox化されていますか。
いいえ、しかし全てのイベント (Aura及びDOM) はフィルタリングproxyによってwrappされ、コードからアクセス権を持っているかどうかの確認だけが許可されます。互いの名前空間に関わることなくコンポーネント間の通信を行うにはLightning Eventing フレームワークを利用し続けることも可能です。
raw DOMエレメントにアクセスすることは可能でしょうか?
いいえ – 常にSecure Virtual DOMに対して操作を行います。 – しかしあなたのコード及び3rdパーティコードはその違いを意識する必要はありません – プログラミングモデルに変更はありません。(例: Component.getElement()はそのまま動作します)。しかしながらもともと私たちが非推奨としてきたことはできなくなります。例えば node.parentNode.parentNodeのようなコードで対象DOMを保有していない場合はブロックされます。
lockerの粒度は? 一つのコンポーネントごとにlocker?複数のコンポーネントにlocker?
現在の粒度は全てのコンポーネントが同じ皿の上に乗ってしまっています。未来のSalesforceリリースであれば両方に対応する予定です (例. コンポーネントに設定) そして粒度の設定などにも対応予定です (例. 組織上で保有する名前空間を設定する)
これはほんのご紹介用のポストです。LockerServiceがリリースされるまでの今後数週間から数ヶ月にわたりツールやBlog、詳細記事及びTrailheadモジュールを公開していきます。ぜひSalesforce Developersの最新情報をご確認ください。
