Classic環境でよく利用されている「Javascriptボタン」ですが、Lightning Experience上ではこのJavascriptボタンは利用できず、また今後もサポートの予定もありません。 ですがサポートをしないのには明確な理由があり、そしてLightning Experienceではより魅力的な代替案のソリューションを提供しています。少し前の記事ですが、このJavaScriptボタンの移行をご理解頂くためのシリーズ物のブログが 米国の開発者ブログに投稿 されていいたので、翻訳致しました。 これから本格的にLightning Experienceへ移行される方は、ぜひお読みください。

皆様には JavaScript ボタンを気に入っていただき、長きにわたって Salesforce Classic でご利用いただいてきたかと思います。実際、JavaScript ボタンの機能がないことから、多くの方が Lightning エクスペリエンスへの移行に消極的になっているようです。しかし Lightning エクスペリエンスは Salesforce Classic よりもはるかに多くのメリットをもたらす、進化した環境です。皆様からは既存の機能が常に新しい機能や UI に移行されることが期待され、これまでそのように信じていただいてきたことは承知していますが、JavaScript ボタンの場合に限っては、JavaScript ボタンのサポートがなくても Lightning エクスペリエンスの未来は明るいと考えています。

JavaScript ボタンおよびリンクは、Salesforce Classic UI における各種のアクションです。これを使って作成したインライン JavaScript コードは、レコードやリストページに埋め込まれたボタンまたはリンクから呼び出すことができます。あるお客様は、新規レコードの作成時にデータを事前入力したり、他のロジックにもとづいて項目の値を更新しています。そのほか、カスタムボタンを使って自社プラットフォームと統合しているパートナーもいます。

それほど便利な JavaScript ボタンがなぜ Lightning Experienceでサポートされないのでしょうか？問題となるのは、ソースも作成者もさまざまに異なる未信頼の JavaScript をアプリケーションのソースコードと組み合わせつつ、アプリケーション全体の信頼性を維持することに、セキュリティ上の大きな課題があるという点です。

このブログシリーズでは、そうしたセキュリティ上および機能上の課題を取り上げるとともに、JavaScript ボタンの代替となる、Lightning 対応、モバイル対応のソリューションを紹介します。ここで取り上げる Salesforce の既存の機能や今後リリース予定の機能を利用することで、皆様がカスタムボタンを使って作成した機能を移行していただくことができます。

Salesforce では、クライアント側でのカスタマイズや統合における問題の解決に取り組んでいます。Lightning Experienceの中で JavaScript ボタンの機能を実現し、誰にとっても今まで以上に大きなメリットを提供するという新しい考え方をどのように実現しているか紹介していきます。

シリーズの概要

パート 1 – 今、JavaScript ボタンから Lightning に移行すべき理由

JavaScript は Web 開発に欠かせないものですが、On-Click JavaScript ボタンにはリスクがあることから、Salesforce ではお客様によるアプリケーションのカスタマイズで利用できる代替機能を検討することになりました。この記事では、その判断に至った理由、JavaScript ボタンの一般的なユースケース、代替ソリューションの方が優れている理由について説明します。

パート 2 – 最初の一歩 – JavaScript ボタンを置き換える方法

この記事では、JavaScript ボタンの最も一般的なユースケースを紹介するとともに、同等の機能を Salesforce1 と Lightning Experienceで実現するための機能を取り上げます。現在多くのお客様やパートナーが、クイックアクションや Apex の利用による Lightning Experienceへの移行をすでに開始しています。

パート 3 – Lightning アクションで実現する、モバイル対応のスマートな開発

このシリーズの最後の記事では、移行プロセスを容易にする、Salesforce1 と Lightning Experienceに導入されている新機能（Lightning アクションなど）について説明します。

JavaScript ボタンから Lightning に移行すべき理由

Lightning エクスペリエンスによって得られる最大のメリットの 1 つが、Salesforce アプリケーションのレコードやホームなどのページにお客様やパートナー自身で Lightning コンポーネントを追加できることです。たとえば、お客様が取引先レコードページに地図コンポーネントを追加したり、パートナーが自社の AppExchange アプリ用コンポーネントをホームページや商談レコードに追加することができます。

このように非常に幅広いユースケースを提供する Lightning Experienceは、お客様やパートナーから高い評価をいただいています。しかし、適切な対策を施さないと、相互のデータへのアクセス権、ウィンドウやイベントの構造に対する共有アクセス権、任意のクライアント側 API へのアクセス権をコンポーネントが取得できてしまいます。これにより、パートナーが提供する HIPAA 準拠を前提としたコンポーネントや財務情報を扱うコンポーネントに、同じページ上のソースが異なるコンポーネントからアクセスできてしまう可能性が発生します。このことが問題であること、セキュリティ上あるいは法規制関連上のさまざまな問題をもたらすことは明らかです。

インライン JavaScript の問題




Salesforce が Lightning コンポーネントに採用したセキュリティ対策について説明する前に、インライン JavaScript がはらむ問題をいくつか紹介しましょう。JavaScript は弱い型付けのプログラミング言語で、あらゆる最新 Web ブラウザがデフォルトでサポートしています。Cookie やストレージ API によってデータや状態を保持でき、ブラウザ経由でイベント、URL、Cookie にアクセスすることが可能です。そして、その利便性だけでなく危険性も高めているのが、Document Object Model（DOM）と Browser Object Model（BOM）に対するフルアクセスの権限を持つ点です。

DOM にアクセスできれば、HTML または XML ドキュメントのほぼすべての要素をプログラマーが追加、変更、削除できるようになります。これは正しい意図を持ったプログラマーにとってはきわめて便利です。JavaScript ではテキスト、日付、正規表現を扱うための API が用意されているため、JavaScript スニペットによってクライアント側の機能を追加し、基本となるユーザーインターフェースを簡単に強化できます。しかし一方ではこのことが大きな脆弱性にもなります。悪意のある攻撃者が JavaScript を悪用したクロスサイトスクリプティング（XSS）の手法を用いれば、DOM や BOM へのアクセス権を取得して大きな混乱をもたらすことができるためです。

Web サイトが動的コンテンツに対応していれば、ハッカーは XSS の手法によって、一般ユーザーが閲覧する Web ページに悪意のあるクライアント側コードを挿入するおそれがあります。さらに、一般ユーザーのセッションや Cookie を悪用してスクリプトを実行し、データの抽出、キーストロークの記録、フォームへの入力内容の操作、API へのアクセスを実行することさえ可能になります。

LockerService – Lightning コンポーネントのセキュリティを強化

でもご安心ください。Salesforce はすでに Lightning コンポーネントのセキュリティを強化し、JavaScript を通じた無制限のアクセスを制限する、LockerService というソリューションの開発に着手しています。さまざまなテクノロジーや手法が採用された LockerService は、以下のことを実現できます。

LockerServiceによって解決する課題:

  • XSS や類似のセキュリティ問題
  • DOM への無制限のアクセス
  • 非公式またはプライベートな API の呼び出し機能強化や改善を可能にする

LockerServiceによって可能となる手法:

  • 優れた新機能（クライアント側 API のバージョン管理など）
  • 迅速なセキュリティレビュー（AppExchange）
  • より優れた JavaScript 開発手法

セキュリティ機能やポリシーの容易な更新 では、Lightning コンポーネントのセキュリティが強化されていることをおわかりいただいたところで、それによってメリットを得るには、また Lightning Experienceで JavaScript ボタンの機能を再現するにはどうすればよいのでしょうか？それにはまず、お客様やパートナーが Salesforce Classic で JavaScript ボタンをどのように使っているかを見てみましょう。

JavaScript ボタンのユースケース

Salesforce では、組織内で何百個もの JavaScript ボタンを使っているお客様を含め、多くのお客様のご意見を伺いました。パートナーとも、JavaScript ボタンのユースケースについて意見を交わしています。Salesforce ではその成果として、さまざまなユーザー独自のユースケースを大まかなカテゴリにまとめました。以下に、JavaScript ボタンのもっとも一般的なユースケースを紹介します。

  • 保存操作の「前に」レコードの値を利用または操作
    • 項目の値の検証 — 値が入力されているか、条件を満たしているかを確認
    • 他の項目での入力内容に応じて値を事前に入力
    • 入力値に応じて Visualforce ページにリダイレクト
    • ポップアップによる確認画面
  • 値が事前に入力されたレコードを作成
  • Visual Workflow のフローを開始
  • Salesforce API または外部 API へのコールアウト
  • サードパーティとの統合
  • リストに含まれるレコードに対する一括アクション
  • ユーザーに方法や手順を伝えるポップアップ画面

シナリオはこれだけではなく、ある組織にしか存在しないため上記のカテゴリに当てはまらないユースケースもあります。このブログシリーズでは、Salesforce1 や Lightning Experienceに JavaScript ボタンの機能を移行する際に利用できる、既存の機能や今後予定されている機能を紹介していきます。その中で、代替ソリューションのメリットを実感していただき、お客様固有のニーズに合わせてソリューションを調整する方法を見出していただければ幸いです。

次の記事では、上記のユースケースの一部に対処できる既存ソリューションを取り上げます。具体的には、クイックアクションや Apex の利用方法、Lightning Experienceへの移行をすでに始められたお客様やパートナーの事例を見ていきます。さらには、JavaScript ボタンを古臭く感じさせるような新しいテクノロジーもいくつか紹介します。引き続きご期待ください。

LockerService と Lightning コンポーネントの詳細については、Trailhead の「 Lightning コンポーネントの基本 」、LockerService を取り上げたすばらしいブログ記事、「 Lightning コンポーネント開発者ガイド 」をご覧ください。

Get the latest Salesforce Developer blog posts and podcast episodes via Slack or RSS.

(英語のみです)

Add to Slack Subscribe to RSS