Officeアドインを、Office Onlineで実行するための手順です。

「Office Online」でOfficeアドインを実行するためには、アプリ本体となるhtmlファイル・各種プログラムをサーバーにアップロードしなければいけない・・・と考えがちですが、実はそんなことはなく、localhostにアプリを配置したまま、アプリを実行し、デバッグ・検証することができます。
以下、その手順を記載します。

前提条件

執筆時環境・バージョン

• Windows10
• Microsoft Office (Microsoft365版) ビルド13530.20376
• Edge 88.0.705.53(Chromeでも可)
• VSCode 1.52.1
• Live Server v5.6.1

前提

• すでにOfficeアドイン(クライアント版)を、ローカル環境で動作するための手順が整っていること

実行環境

• ローカル環境URL：https://127.0.0.1:5500 （Live Server）

必要ソフトウェア

• OpenSSL ※自己証明書を作るために必要です。証明書がすでにあったり、別の方法で証明書が作成可能な場合は、不要になります。

手順

自己証明書作成

Office Onlineでは、https通信で実行する必要があるようです。
そのため、証明書を作成します。すでに証明書がある場合は不要です。

• 証明書を配置するフォルダで、以下のコマンドを実行します。
  ※Windows用です。OpenSSLが"C:\Program Files\OpenSSL-Win64"にリリースされている前提です。その他諸々は、自己責任でお願いします。

"C:\Program Files\OpenSSL-Win64\bin\openssl.exe" req -x509 -newkey rsa:4096 -sha256 -nodes -keyout vscode_live_server.key.pem -out vscode_live_server.cert.pem  -subj "/CN=example.com" -days 3650

• これで、コマンドを実行したフォルダに、証明書"vscode_live_server.key.pem", "vscode_live_server.cert.pem"の2つが作成されます。

VSCode設定

• VSCodeを開き、アプリ本体(htmlファイルなど)のあるフォルダを開きます。

• Live Serverをhttpsで開くための設定を行います。
  VSCodeのメニューより、「ファイル」→「ユーザー設定」→「設定」を選択します。

• 「ワークスペース」タブの、「拡張機能」→「Live Server Setting」を選択します。

• Settingsの「Https」項目を探し、値を変更します。
  • enable : true
  • cert : 作成した証明書のcertファイルのフルパス
  • key : 作成した証明書のkeyファイルのフルパス
  • passphase : 空欄

• 右下の「Go Live」ボタンをクリックします。

• ブラウザで、証明書の確認メッセージが表示されますので、一旦承認し、アクセスを許可します。（この過程がないと、アプリが起動しませんでした）

マニフェストファイル修正

• マニフェストファイルのURLが、httpになっている場合、httpsに修正してください。デバッグとして必要な最低限は、以下の2箇所です。

①DefaultSettings->SourceLocation

②Contoso.Taskpane.Url

Office Onlineでアプリ実行

• そのブラウザのまま、Microsoft365などで、Office Onlineを開きます。
  ※キャプチャではWordですが、Excel・PowerPointなどでも手順は一緒なはずです。OneNoteやOutlookは同じか怪しいかも

• メニューの 「挿入」をクリックし、「アドイン」 を選択します。

• 「個人用アドイン」の中の「個人用アドインの管理」をクリックし、「マイ アドインのアップロード」をクリックします。

• これで、マニフェストファイルがアップロードされます。クライアント版Officeと同じような手順でアプリを実行することで、アプリが読み込まれます。

localhostで実行されている環境にも関わらず、アプリが読み込まれました。
※もちろん、Live Serverを実行している端末以外で、Office Onlineを起動しマニフェストファイルを読み込んでも、アプリは実行されませんので、ご了承ください

デバッグする

いろんな場所で記載していますが、OfficeアドインはWebアプリケーションです。そのため、ブラウザのデバッグ機能をそのまま実行できます。

• Edgeの場合、F12をクリックし、「ソース」タブを開きます。

• 左リストの中の、「ぺージ」から、「top」→「WebApplicationFrame」→「{"baseFrameName:....}」→「ローカル環境のURL(127.0.0.1:5500)」と開くことによって、作成したhtmlやスクリプトが開けます。

• 後は、各々で作成したコードにブレークポイントを置いて、実行することで、デバッグが実施できます。

まとめ

クライアント版のOfficeの方が安定感がありますが、前回の記事で書いたように、どうにも環境依存で動く・動かないがあるようです。
この手順なら、ごく普通のブラウザで動作・デバッグ可能ですので、場合によっては、Office Onlineでの開発も検討してみてください。

参考

https://docs.microsoft.com/ja-jp/office/dev/add-ins/testing/sideload-office-add-ins-for-testing
https://qiita.com/ma2shita/items/297c812a6cd09b5e82c8

Officeアドイン（クライアント）のデバッグを、VSCodeで実行するための手順です。

Visual Studio 201XのOfficeソリューションであったり、nodeを使用した環境であれば、デバッグの方法についてはちょいちょい出てくるのですが、それ以外の環境で、VSCodeを使用した手順がなかなか出てこなかったので、まとめました。

今回はサーバーにLive Serverを使用していますが、XAMPP、IIS、Apacheなど、環境は何でも良いと思います。

また、どういうわけか同じ手順を踏んでいても、なぜかデバッグが正常に動かなかったり、ブレークポイントに引っかからなかったりということが発生していました。
そのため、もしこの手順でデバッグが正常に動かない場合は、お手数ですが、端末の再起動、VSCodeの再起動など、お試しください。
それでも駄目なら、なにか別の理由があると思いますが、今は分かりません。ごめんなさい。

前提条件

執筆時環境・バージョン

• Windows10
• Microsoft Office (Microsoft365版) ビルド13530.20376
• Edge 88.0.705.53
• VSCode 1.52.1
• Microsoft Office Add-in Debugger v0.2.0
• Live Server v5.6.1

前提

• すでにOfficeアドイン(クライアント版)を、ローカル環境で動作するための手順が整っていること

実行環境

• ローカル環境URL：http://127.0.0.1:5500 （Live Server）

手順

• スタートメニューで、「Visual Studio」と入力すると、「Visual Studio Code」が表示されます。

• そこで、「管理者として実行」をクリックします。 (※)

• 正常に開けた場合、VSCodeのタイトルに[管理者]と表示されます。

• 左メニューの「拡張機能」で、「Microsoft Office Add-in Debugger」で検索し、インストールします。
  

• 左メニューより「実行」を選択し、「launch.jsonファイルを作成します」リンクをクリックし、「Office Addin」を選択します。
  

• launch.jsonファイルが作成されます。
  

• launch.jsonに、行を追加します。※最初の行に「,」を追加してください
  ※ここで、"url"の値の"?"の前に、「/」を付けてください。これが無いと、正常に動きませんでした。
  ※逆に、「/」があると動かないケースもあるかもしれません。この値は、有る無しで切り替えてみてほしいです。

        ,
        {
            "type": "office-addin",
            "request": "attach",
            "name": "Attach to Office Add-ins",
            "port": 9222,
            "trace": "verbose",
            "url": "http://127.0.0.1:5500/?_host_Info=Word$Win32$16.01$ja-JP$$$$0",
            "webRoot": "${workspaceFolder}",
            "timeout": 3000
          }

• VSCodeで、任意の場所にブレークポイントを置きます。
  

• Live Serverで実施する場合、右下の「Go Live」ボタンをクリックします。 (※)
  

• Wordを起動し、Officeアドインを開きます。 (※)
  

• VSCodeに戻り、左メニューの「実行」をクリック後、左上の「Launch」と書かれている再生ボタンの右の一覧をクリックし、「Attach to Office Add-ins」を選択します。 (※)
  

• そのまま、左上の「Launch」と書かれている再生ボタンをクリックします。 (※)
  正常にデバッグが完了すれば、VSCodeのページ上部に下記キャプチャのような表示が行われます。
  

• Wordのアプリのjs処理を実行してみます。 (※)
  

• VSCodeで、ブレークポイントで停止しました。
  

再度、デバッグを実施する場合

端末の再起動などで、再度デバッグを実施する場合は、手順に(※)と記載の部分のみ、実施を行ってください。

やっぱり動かない場合

どうもこのOfficeアドインのデバッグは不安定なようで、どうやっても正常に動作しない、というご報告をいただいていました。
そのため、Office Onlineでの動作手順も、今後記事にしようと思っています。気長にお待ちください。

前回の記事では、SharePoint Framework内でWordPress REST API処理を追加し、SharePointページ内でコンテンツを表示する対応を行いました。

しかし前回の記事のままだと、取得先のWordPressのURLは、ソースコード内に埋め込まれており、変更できません。
URLを変更するためには、都度ソースコードを変更する必要があり、非常に面倒です。

そのため今回は、SharePoint Frameworkにプロパティ要素を追加し、画面から設定値を変更できるようにする機能を追加します。
今回は、「取得先のWordPressのURLを、画面から変更できるようにする対応」とします。

SharePoint Frameworkのプロパティとは

前回作成したWebパーツを起動すると、「Edit web part」と、Webパーツを編集するタイルが表示されています。

このボタンをクリックすると、画面右に、プロパティを変更する要素が表示されます。

現在は「Description Field」、つまり説明文を変更する要素のみになりますが、今回はここに、取得先のWordPress APIを変更できるようにしていきます。

実装

今回の参考資料：
https://docs.microsoft.com/ja-jp/sharepoint/dev/spfx/web-parts/get-started/build-a-hello-world-web-part#configure-the-web-part-property-pane

プロパティの追加

• 前回修正した、「SharePointWordpressWebPart.ts」（アプリ名.ts）ファイルを開き、先頭の以下の要素を確認します。

import {
  IPropertyPaneConfiguration,
  PropertyPaneTextField
} from '@microsoft/sp-property-pane';

この「PropertyPaneTextField」というのが、プロパティのテキストフィールドになります。
ここで、プロパティ要素にチェックボックスを追加したい場合はPropertyPaneCheckbox、ドロップダウンメニューの場合はPropertyPaneDropdownなどを追加してください。
例：

import {
  IPropertyPaneConfiguration,
  PropertyPaneTextField,
  PropertyPaneCheckbox,
  PropertyPaneDropdown
} from '@microsoft/sp-property-pane';

※今回については、種類はテキストフィールドのみなので、上記の追加は不要です

• 同じtsファイル内のインタフェース、「ISharePointWordpressWebPartProps」を確認します。デフォルトだと以下のようになっております。

export interface ISharePointWordpressWebPartProps {
  description: string;
}

ここに、プロパティとして追加したい要素と、その種類を追記していきます。
今回はWordPressのURLなので、以下のように追加してください。その後、ファイルを保存します。

export interface ISharePointWordpressWebPartProps {
  description: string;
  wordPressUrl: string;
}

• その下の、getPropertyPaneConfigurationメソッドを確認します。
  デフォルトだと、以下のような記述になっております。

protected getPropertyPaneConfiguration(): IPropertyPaneConfiguration {
    return {
      pages: [
        {
          header: {
            description: strings.PropertyPaneDescription
          },
          groups: [
            {
              groupName: strings.BasicGroupName,
              groupFields: [
                PropertyPaneTextField('description', {
                  label: strings.DescriptionFieldLabel
                })
              ]
            }
          ]
        }
      ]
    };
  }

これを修正し、wordPressUrl要素を追加していきます。
具体的には、以下のようになります。

protected getPropertyPaneConfiguration(): IPropertyPaneConfiguration {
    return {
      pages: [
        {
          header: {
            description: strings.PropertyPaneDescription
          },
          groups: [
            {
              groupName: strings.BasicGroupName,
              groupFields: [
                PropertyPaneTextField('description', {
                  label: strings.DescriptionFieldLabel
                }),
                // 追加-開始
                PropertyPaneTextField('wordPressUrl', {
                  label: 'WordPress URL'
                }),
                // 追加-終了
              ]
            }
          ]
        }
      ]
    };
  }

これで、SharePointWordpressWebPart.tsに関する設定は完了です。

デフォルト値の修正

アプリのプロパティ既定値を追加していきます。

• 「SharePointWordpressWebPart.manifest.json」(アプリ名.manifest.json)を開きます。
  標準だと以下のような記載がされています。

  "preconfiguredEntries": [{
    "groupId": "5c03119e-3074-46fd-976b-c60198311f70", // Other
    "group": { "default": "Other" },
    "title": { "default": "SharePointWordpress" },
    "description": { "default": "SharePointWordpress description" },
    "officeFabricIconFontName": "Page",
    "properties": {
      "description": "SharePointWordpress"
    }
  }]
}

• preconfiguredEntries > properties が、プロパティの既定に関する内容です。
  この内容を変更します。今回は前回同等、弊社で提供しているサービスのURLにします。
  （他社のブログにアクセスするのも問題なので）

  "preconfiguredEntries": [{
    "groupId": "5c03119e-3074-46fd-976b-c60198311f70", // Other
    "group": { "default": "Other" },
    "title": { "default": "SharePointWordpress" },
    "description": { "default": "SharePointWordpress description" },
    "officeFabricIconFontName": "Page",
    "properties": {
      "description": "SharePointWordpress",
      "wordPressUrl": "https://exment.net"
    }
  }]
}

• Ctrl + Shift + Bでビルドを行い、以下のコマンドでWorkBenchを表示します。

gulp serve

これで、先ほど確認したプロパティを表示すると、「WordPress URL」入力テキスト欄が追加されています。

プロパティ値をWebパーツに埋め込む

いよいよ、今回作成したプロパティwordPressUrlを、Webパーツに埋め込む処理を追加していきます。

• WordPress.tsのgetWordpressHtmlを、引数よりWordPressのURLを取得する方式に修正します。

export default class WordPress {
  public static getWordpressHtml = (wordPressUrl) => {
    var $defer = $.Deferred();
    var apiUrl = wordPressUrl + '/wp-json/wp/v2/posts?_embed';
    $.getJSON(apiUrl).then((data) => {
        // 以下省略

apiUrlを、wordPressUrl + '/wp-json/wp/v2/posts?_embed' より作成する方式に修正しました。

• SharePointWordpressWebPart.tsのrender関数を修正します。

public render(): void {
    var wordPressUrl = this.properties.wordPressUrl;  // ポイント
    WordPress.getWordpressHtml(wordPressUrl)
      .then((html:string) => {
        $(this.domElement).html(html); 
      });
  }

ポイントは「this.properties.wordPressUrl」です。this.propertiesで、プロパティ値を取得できます。
今回はthis.properties.wordPressUrlで、WordPressのURLを取得しています。

これにより、WordPressのURLを、画面から取得するようになりました。
試しに、URLを変更してみます。プロパティウィンドウを開き、WordPress URLを、かつて私が書いていた個人ブログに変更します。

めちゃくちゃ色々語ってますねｗ
このように、画面からURLを変更することで、取得先のURLを変更することができます。

ちなみに、レンダリング時に直接埋め込むことも可能なようです。
参考サイトだと、以下のように記載しておりました。この中の「this.properties.description」が該当します。

public render(): void {
  this.domElement.innerHTML = `
    <div class="${ styles.helloWorld }">
      <div class="${ styles.container }">
        <div class="${ styles.row }">
          <div class="${ styles.column }">
            <span class="${ styles.title }">Welcome to SharePoint!</span>
            <p class="${ styles.subTitle }">Customize SharePoint experiences using web parts.</p>
            <p class="${ styles.description }">${escape(this.properties.description)}</p>
            <a href="https://aka.ms/spfx" class="${ styles.button }">
              <span class="${ styles.label }">Learn more</span>
            </a>
          </div>
        </div>
      </div>
    </div>`;
}

まとめ

このように、プロパティを設定することで、ユーザーによる柔軟な設定変更ができるようになります。
設定値は可能な限りプロパティ値にすることで、変化に柔軟なアプリ作りを心掛けましょう！

SharepointFrameworkの検証を行います。
この記事では、以下について扱います。

1. SharePointFrameworkのインストール
2. とりあえずSharePointFrameworkで実行してみる
3. jqueryの追加
4. 独自処理 - WordPress連携部分の追加

※SharepointFrameworkの概念の話はしません。それはまた別の機会に。

実装

今回の参考資料

https://docs.microsoft.com/ja-jp/sharepoint/dev/spfx/web-parts/get-started/build-a-hello-world-web-part

SharePointFrameworkのインストール

• nodeを未インストールの場合、nodeをインストール

https://nodejs.org/ja/

• npm確認

  npm --version

• 必要パッケージインストール

  npm install -g yo gulp
  npm install -g @microsoft/generator-sharepoint

• SharepointFrameworkインストール先のフォルダを作成

mkdir SharePointWordpress
cd SharePointWordpress

• SharepointFrameworkインストール実行

  yo @microsoft/sharepoint

ここで、対話式でさまざまなことを聞かれるので、回答します。

  What is your solution name? : (任意のソリューション名)  
  Which baseline packages do you want to target for your component(s)? :(そのままEnter。SharePoint Onlineのみ)  
  Where do you want to place the files? : (そのままEnter。カレントフォルダにインストール)  
  Do you want to allow the tenant admin the choice of being able to deploy the solution to all sites immediately without running any feature deployment or adding apps in sites? : (N)  
  Will the components in the solution require permissions to access web APIs that are unique and not shared with other components in the tenant? : (N)  
  Which type of client-side component to create? : (そのままEnter。WebPart)  
  What is your Web part name? : (任意のWebパーツ名。この名前が画面に表示される様子)
  What is your Web part description? : (説明文。面倒なのでそのままEnter)
  Which framework would you like to use? : (JSのフレームワーク。Reactとか使う場合は指定する様子)  

これが完了したら、インストールが開始されます。超時間かかりますが、待ちましょう。

• Visual Studio Codeで、インストールしたフォルダを開いて起動

• Ctrl + Shift + Bで、gulpのビルド実行
  gulp buildを選択 → タスクのスキャンを出力せず実行 をクリック
  →これで、元々入っているSharePointFrameworkのビルドが実行されます。

• VSCodeで、以下のコマンドを実行

  gulp serve

  →ブラウザが立ち上がり、SharePoint WorkBenchが起動します。

• 「+」ボタンをクリック後、パーツ名をクリックし、Webパーツを配置します。
  

• 既定のパーツが配置されていることを確認します。
  

カスタマイズ

デフォルト設定で起動できることを確認したら、ここからカスタマイズをしていきましょう。

jquery追加

まずはjqueryの追加です。

• VSCodeで、以下のコマンドを実行

  npm install jquery@2 --save
  npm install @types/jquery@2 --save

• VSCodeで、config/config.jsonを開き、externalsに以下を追加

  "jquery":"node_modules/jquery/dist/jquery.min.js"

独自処理を追加

独自処理として、今回はWordPressのAPIを使用し、WordPressの記事一覧を取得し表示します。
※WordPressの向き先は、とりあえず自社サービスのものにしています。

• src\webparts\sharePointWordpressに、WordPress.tsを追加します。
  その後、以下のコードを追加します。

import * as $ from 'jquery';

export default class WordPress {
  public static getWordpressHtml = () => {
    var $defer = $.Deferred();

    // wordpressのAPIのURL
    $.getJSON('https://exment.net/wp-json/wp/v2/posts?_embed').then((data) => {
          console.log(data);

          var html = '';
          for(var index in data){
              var d = data[index];

              var title = d.title.rendered;
              var link = d.link;
              var excerpt = d.excerpt.rendered;
              var date = d.date;

              // ul作成
              var $a = $('<a/>', {'href' : link, 'style' : 'margin-bottom:4em; display:block;'});
              var $ul = $('<ul/>');

              $ul.append($('<li/>', {'text': 'タイトル：' + title}));
              $ul.append($('<li/>', {'text': '日付：' + date}));
              $ul.append($('<li/>', {'html': '本文：' + excerpt}));

              $a.append($ul);

              html += $a[0].outerHTML;
          }

          $defer.resolve(html);
      });

    return $defer.promise();
  }

}

• src\webparts\sharePointWordpress\SharePointWordpressWebPart.tsの記述を修正します。

import { Version } from '@microsoft/sp-core-library';
import { BaseClientSideWebPart } from '@microsoft/sp-webpart-base';
import {
  IPropertyPaneConfiguration,
  PropertyPaneTextField
} from '@microsoft/sp-property-pane';
import { escape } from '@microsoft/sp-lodash-subset';

import styles from './SharePointWordpressWebPart.module.scss';
import * as strings from 'SharePointWordpressWebPartStrings';

///// 追加---s
import * as $ from 'jquery';
//WordPress.tsを読み込む
import WordPress from './WordPress';
///// 追加---e

export interface ISharePointWordpressWebPartProps {
  description: string;
}

export default class SharePointWordpressWebPart extends BaseClientSideWebPart<ISharePointWordpressWebPartProps> {

  public render(): void {
    ///// 修正---s
    // WordPress.ts内のgetWordpressHtml実行
    WordPress.getWordpressHtml()
      .then((html:string) => {
        $(this.domElement).html(html); 
      });
    ///// 修正---e
  }

  protected get dataVersion(): Version {
    return Version.parse('1.0');
  }

  protected getPropertyPaneConfiguration(): IPropertyPaneConfiguration {
    return {
      pages: [
        {
          header: {
            description: strings.PropertyPaneDescription
          },
          groups: [
            {
              groupName: strings.BasicGroupName,
              groupFields: [
                PropertyPaneTextField('description', {
                  label: strings.DescriptionFieldLabel
                })
              ]
            }
          ]
        }
      ]
    };
  }
}

• 再度Ctrl + Shift + Bで、ビルドを行います。
  その後Sharepoint WorkBenchにアクセスすることで、WordPressの記事一覧が表示されます。
  

• 無事、jqueryも呼び出した上で、独自の実装を実現できました！

実装方針

MSのサイトに、node.jsとASP.NETのサンプルはすでにあるので、今回は別の言語で実装することにします。
今回は最近愛してやまない、PHPのLaravelで実装しました。Laravelサイコー。

なお、基本的には以下のドキュメントに記載の内容の後追いになります。こっちと自分の記事を読みながら検証するのがベスト。
https://docs.microsoft.com/ja-jp/office/dev/add-ins/develop/sso-in-office-add-ins

https://docs.microsoft.com/ja-jp/office/dev/add-ins/develop/register-sso-add-in-aad-v2

準備・設定

前提

• 今回構築するLaravelサイトの情報は以下になります。
  http://127.0.0.1:8000
  ※実際に公開する場合は、「127.0.0.1:8000」を修正してください
  ※また、この記事を書き始めた当初、「localhost:9000」と思い、キャプチャを作成し始めてしまいました。そのため、キャプチャ内に「localhost:9000」があった場合、「127.0.0.1:8000」に修正をお願いします。

• Laravel5.6で構築しております。

Office365インストール

Office365のクライアント版を、Office365のサイトからインストールします。

Azure AD v2設定

• 以下のAzureポータルページにアクセスし、Office365のアカウントでサインインします。
  [https://go.microsoft.com/fwlink/?linkid=2083908]

• 「アプリの登録」より、「新規登録」をクリックします。
  

• 以下のように入力し、「登録」をクリックします。
  

• アプリケーション (クライアント) IDとディレクトリ (テナント) IDをコピーしておきます。（あとで使用します）
  

• 「証明書とシークレット」をクリックし、「新しいクライアント シークレット」をクリックして、クライアントシークレットをコピーします。(こちらも後で使用します)
  

• 「API の公開」→「設定」をクリックし、値に以下を入力します。
  api://(Webサイトのドメイン)/(先ほどコピしたアプリケーションID)
  例： api://127.0.0.1:8000/f4255842-2ac6-4b01-b8a6-aaaaaaaaaaaa

• 「Scopeの追加」をクリックし、以下のように入力します。
  ※スコープ名に「access_as_user」、同意できるのは誰ですかを「管理者とユーザー」と記入し、後は適当に

• 「承認済みのクライアント アプリケーション」下の「クライアント アプリケーションの追加」をクリックし、
  「クライアントID」に以下の3つを入力し、「承認済みのスコープ」チェックを行い、「アプリケーションの追加」をクリックします。
  (Office系の設定値らしいです)
  d3590ed6-52b3-4102-aeff-aad2292ab01c
  57fb890c-0dab-4253-a5e0-7188c88b2bb4
  bc59ab01-8403-45c6-8796-ac3ef710b3e3

• 「APIのアクセス許可」をクリックし、[Microsoft Graph] を選択してから [委任されたアクセス許可] を選択します。
  その後、以下にチェックを行い、「アクセス許可の更新」をクリックします。
  offline_access
  openid
  profile

最後に、「既定のディレクトリ に管理者の同意を与えます」をクリックします。

以上で、Azure AD v2側の設定は完了です。

Laravel開発

Laravelの開発を行っていきます。
※composerをインストールしている前提です。composerの説明は割愛します。

• インストールするフォルダで、コマンドプロンプトなどで、以下のコマンドを実行します。
  実行後、officejs_sso_laravelフォルダにcdします。
  composer create-project "laravel/laravel=5.6.*" officejs_sso_laravel

• 以下のリポジトリより、phpファイルをダウンロードします。
  https://github.com/hirossyi73/office-js-sso-laravel

該当ファイルを、Laravelディレクトリに上書きます。

• .envファイルに、以下の値を記入します。
  CLIENT_ID=(コピーしたアプリケーションID)
  CLIENT_SECRET="(コピーしたクライアントシークレット。ダブルクオーテーションで囲むことを推奨)"
  SCOPE="offline_access openid profile"
  TENANT=(コピーしたテナントID)

• 以下のコマンドを実行します。
  php artisan serve

これで、以下のURLでサーバーが起動します。
http://127.0.0.1:8000

Officeアドイン設定

• githubより、マニフェストファイルをダウンロードします。

https://github.com/hirossyi73/office-js-sso-laravel/blob/master/Office-Add-in-Laravel.xml

• ダウンロードしたマニフェストファイルを開き、135行目以降のWebApplicationInfo以下の内容を修正します。

    <WebApplicationInfo>
      <Id>(アプリケーションID)</Id>
      <Resource>api://(ドメイン)/(アプリケーションID)</Resource>
        <Scopes>
            <Scope>openid</Scope>
            <Scope>offline_access</Scope>
            <Scope>profile</Scope>
        </Scopes>
    </WebApplicationInfo>

• マニフェストファイルを、Officeのセキュリティ設定で「カタログ URL」に設定したパスに配置します。

• PowerPointを開き、アドインを起動します。

• 正常終了すると、このようにトークンが取得されます。

• このうち、
  • アドイントークン：OfficeのSSOから取得したトークンです。
  • ユーザー名：アドイントークンから取得したログインユーザー名です。
  • Eメール：アドイントークンから取得したメールアドレスです。
  • Graphアクセストークン：アドイントークンを使用し、PHP(Laravel)側で取得したMicrosoft Graphトークンです。もちろん、このトークンをMicrosoft Graphに使用すれば、情報を取得できます。
  • Graphリフレッシュトークン：アドイントークンを使用し、PHP(Laravel)側で取得したMicrosoft Graphのリフレッシュトークンです。

解説

ソース単位でご説明します。

アドイントークン取得

以下の内容で、アドイントークンを取得しています。

//  app.js
(function(){
    // 初期化処理
    Office.onReady(function(info) {
        if(!Office.context.auth.getAccessTokenAsync){
            log('Office.context.auth.getAccessTokenAsync not supported');
            return;
        }

        // 認証実行
        Office.context.auth.getAccessTokenAsync(function (result) {
            if (result.status === "succeeded") {
                // Use this token to call Web API
                var ssoToken = result.value;
                $('#addin_token').val(ssoToken);

                // decode user info
                var decoded = jwt_decode(ssoToken);

                $('#username').val(decoded.name);
                $('#email').val(decoded.preferred_username);

                getGraphToken(ssoToken);
            } else {
                if (result.error.code === 13003) {
                    // SSO is not supported for domain user accounts, only
                    // work or school (Office 365) or Microsoft Account IDs.
                } else {
                    // Handle error
                }

                log('error ' + result.error.code);
            }
        });
    });
})();

ポイントは「Office.context.auth.getAccessTokenAsync(function (result) {」で、この関数で、PowerPointのアプリケーションからSSOで、アドインのトークンを取得しています。
トークンはJWT形式なので、「//decode user info」の部分で内容を解析し、名前とメールアドレスを取得しています。

Microsoft Graphトークン取得

以下の内容で、Microsoft Graphトークンを取得しています。

//  app.js

/**
 * Microsoft Graphのトークンをサーバーサイドから取得
 * @param string apptoken アドイントークン
 */
function getGraphToken(apptoken){
    var CSRF_TOKEN = $('meta[name="csrf-token"]').attr('content');

    $.ajax({
        url:'./graphtoken',
        type:'POST',
        data:{
            'apptoken':apptoken,
            '_token' : CSRF_TOKEN,
        }
    })
    // Ajaxリクエストが成功した時発動
    .done(function(data){
        $('#graph_token').val(data.access_token);
        $('#graph_refresh_token').val(data.refresh_token);
    })
    // Ajaxリクエストが失敗した時発動
    .fail(function(data){
        log('Graph token error : ' + JSON.stringify(data));
    })
    // Ajaxリクエストが成功・失敗どちらでも発動
    .always(function(data){
    });
}

// IndexController.php
    /**
     * Graphのトークン取得
     *
     * @return void
     */
    public function graphtoken(){
        $apptoken = request()->get('apptoken');

        // ホントはここで検証を行う

        // Graphのアクセストークンを代理フローで取得
        // https://docs.microsoft.com/ja-jp/azure/active-directory/develop/v2-oauth2-on-behalf-of-flow
        $client = new \GuzzleHttp\Client;

        $res = $client->request(
            'POST',
            'https://login.microsoftonline.com/common/oauth2/v2.0/token',
            [
                'form_params' => [
                    'grant_type' => 'urn:ietf:params:oauth:grant-type:jwt-bearer',
                    'client_id' => env('CLIENT_ID'),
                    'client_secret' => env('CLIENT_SECRET'),
                    'assertion' => $apptoken,
                    'scope' => env('SCOPE'),
                    'requested_token_use' => 'on_behalf_of',
                ]
            ]
        );

        $list = json_decode($res->getBody()->getContents(), true);
        return $list;
    }

検証をサボってますが、本番環境では検証、ちゃんとやってくださいね。
この内容によって、代理フローを使用し、Microsoft Graphトークンを取得するわけです。

まとめ

長くなってしまいましたが、以上でSSOを使用したサンプルは完了します。
今後実装を検討される方は、是非参考にしてみてください！

Officeアドインを開発時に気を付けなければいけない地雷まとめの「Officeのログイン者情報を、Officeアドインで取得することはできない」にも書いたのですが、Officeアドインの安定版では現在、「Officeにログインしているユーザー」を取得することはできません。

どう考えても取れそうな「佐藤 裕」という情報が、残念ながら取得は出来ないのです。安定版では。

そのため、もし「Officeアドインで、Office365のユーザー情報を取得してゴニョゴニョする」というアプリを検討していたとしても、ユーザーに再度ログインを強要する必要があります。
これがクライアント版のOfficeならまだ良いのですが、Online版まで考えると本当に地獄。
アプリがiframeで実装されているがゆえに、認証できず、dialogを表示する必要が出てしまいます。
※これもOfficeアドインを開発時に気を付けなければいけない地雷まとめの「認証が絡む場合、Office Onlineには本当に注意」を参照

しかし、これがPreviewでは、一部できるようになります！
Office系、それもAzure AD v2でのログインに限り、SSOとして、Officeのアプリにログインしている情報（正確にはアクセストークン）を取得できるようになるわけです。
そのため、ユーザーはわざわざ2回目のログインを行う必要がなくなるわけですね。

今回は、この「Office アドインのシングル サインオン」の概要をご紹介します。
検証はまだなので、触りのみとなってしまうことをご了承ください。

概要

基本的にはこちらの公式サイトをご参照ください。
https://docs.microsoft.com/ja-jp/office/dev/add-ins/develop/sso-in-office-add-ins
キーポイントをかいつまんで解説します。

流れ

※引用：https://docs.microsoft.com/ja-jp/office/dev/add-ins/develop/sso-in-office-add-ins

ざっくり流れをまとめると、以下のとおりです。

• Officeアプリ(各開発者が開発するWebアプリ)内のjsファイルで、getAccessTokenAsync関数を実行する

• getAccessTokenAsync内の処理で、Officeプログラム（ExcelやWordの本体）に、現在ログインしているユーザー情報を取得するよう要求する

• Officeプログラムにログインしていない場合、ログインするようユーザーに要求するダイアログを表示する

• Officeプログラムは、Azure AD v2エンドポイントから、現在のユーザーのアドイン トークンを取得する

• Officeプログラムから、getAccessTokenAsync関数の処理として、Officeアプリに、アドイントークンを返却する
  →アドイントークン(JWT)を解析して、ログインユーザーのメールアドレスなどを取得する

ユーザー情報などを取得するのみであれば、ここまでで処理は終了なのですが、Microsoft Graphなども絡める場合、以下の処理も必要になります。

• Officeアプリから、サーバーサイドにアドイントークンを送信する

• サーバーサイドで、Microsoft Graphなどで使用できるアクセストークンを取得し、Officeアプリに返却する

このような処理になります。

注意点

ここからは、現在分かっている注意点を記載します。やはり地雷は多し。

Office Insiderに参加が必要

2019/05/21現在、プレビュー版のみ対応であるため、「Office Insider」に参加する必要があります。
参加した上で、プレビュー版のOfficeをインストールする必要があります。

Office2013や2016には非対応

これがとっても大事ですね。
SSOは「IdentityAPI」という要件セットが必要で、これはOffice2013や2016は非対応です。恐らく今後も。
なので、このSSOを対応させるのであれば、2013や2016を切り捨てる必要がありますね。

サーバーサイドの実装が必要

これは実際のサンプルコードで実装した時に解説予定なのですが、Microsoft Graphなどのトークンを活用したい場合には、サーバーサイドの実装が必要になります。
通常のhtmlとjavascriptだけのアプリを開発しよう！と思っても、それはNGなんですね。vueとかReactとかも多分NG。

今回取得できるトークンは、あくまでも「アドイントークン」で、Microsoft Graphのアクセストークンではありません。
Microsoft Graphのアクセストークンを取得する際には、別途サーバーサイドの処理が必要、ということを覚えておいてください。

まとめ

このように、どうしても限定的な範囲にはなってしまいますので、これはOfficeストアのような全体公開向けのアプリではなく、組織内でのアプリの方が向いているかもしれないですね。
また、現在はプレビュー版なので、いずれにせよ正式版に採用は難しいです。

それでもメリットは十分にあります。Office365前提のアプリであれば、非常に便利な機能になることは間違いないです。

実装の検証と、具体的な解説は次回行う予定です。ぜひお待ちください。

「Officeアドイン」は、ざっくり言うとOffice上で動作するWebアプリケーションです。
Office2013から登場し、Office2016、Office365(クライアント版)、Office365(Web版)など、様々なOfficeで動作します。

Officeアドインは2013年頃に登場し、細々と機能追加を繰り返してきました。
しかし、いかんせんノウハウと情報が少ないです。
そしてこの技術を使えるエンジニアの方も非常に少ないので、なかなか広まらないのも事実です。
「Officeアドイン」と日本語で検索すると、MS公式か、ほとんどが自分の発信な気がしてます・・・笑
（先日、「officeアドイン」で検索したら、MS公式ページより先に、自分の過去の発信が上位に出てきました笑）

そしてもう一つ。
このOfficeアドインは、いかんせん情報が少ないこともあり、いざやってみると、意外なところで詰まってしまう「地雷」が多いです。
そこで今回は、幾多の案件を行ってきて、この地雷に立ち向かってきた自分が、「Officeアドインで気を付けなければいけないところ」についてまとめます。
今後、もしOfficeアドインを案件や自社開発などで使用することを検討している方は、まずこの記事を読んでいただいて、事前に検証いただけることをオススメします。

地雷まとめ

Officeの種類によって、出来ることがぜんぜん違う

OfficeアドインはOffice2013から登場した、ということは上記で説明しました。
そこからOffice2016、Office365(クライアント版)、Office365(Web版)と増えてくるにつれて、出来る機能も増えてきました。
ですが、その出来る機能が、すべてのOfficeで使えるものではありません。

例えば「アドインコマンド」。これはOfficeのメニューにコマンドを追加するという機能です。
あらかじめアドインを設定しておけば、以降わざわざOfficeアドインを選択しなくても、メニューボタンをクリックするだけでアドインを実行できます。

※引用：(https://docs.microsoft.com/ja-jp/office/dev/add-ins/design/add-in-commands)

しかし、この機能はOffice2013とOffice2016では動作しません（ただしOutlook2016のみOK）。
こちらにアドイン コマンドの要件セットというページがあるのですが、ここでアドインコマンドは、Office2013と2016は「N/A」や「16.0.4678.1000 Supported in Outlook only」となっています。
つまり非対応ですね。
最新のOfficeだけで合わせると、「これ出来なかったのか」という事故につながるので、気をつける必要があります。

なお、各Officeで出来ること、出来ないことは、以下のページをご参照ください。
Office Common API requirement sets

Officeのログイン者情報を、Officeアドインで取得することはできない

Office2013から、Officeにログインを行うことができます。

なのでOfficeアドインを始める際、「このログイン情報を取得しよう」と誰もが思うでしょう。このログイン情報からアクセストークンを取得し、ゴニョゴニョしよう、ということです。
ですが、このOfficeの情報を、Officeアドインでは取得することが、現在は出来ません。
なので、ユーザーのOffice365の情報を絡めたアプリを作成する場合、ユーザーは再度、サインインページを表示する必要があります。

なお正確に言うと、2019/04/13現在、上記機能はプレビュー版です。Identity APIという名前で、現在プレビュー版ということで実装しているようです。
ただし、それでもやはり「Office 2013 or later for Windows」では「N/A」になっているので、いずれにせよOffice2013と2016は切り捨てて実装しなければなりません。

認証が絡む場合、Office Onlineには本当に注意

クライアント版のOfficeアドインが、Office Onlineでも動作すると思っていると、確実に失敗します。
なぜなら、クライアント版のOfficeアドインと、Office OnlineのOfficeアドインは、作られ方がぜんぜん違うからです。

クライアント版のOfficeアドインは、ざっくり言うとアプリ内で、ブラウザ（IE）を立ち上げるような形式に対し、
Office OnlineのOfficeアドインは、iframeで起動します。

もし、サードパーティ(GoogleやOffice365やGitHubなど)のアクセストークンを使用して、サードパーティの情報を使用したアプリを開発しようと考えた場合。
iframeなので、つまりサードパーティ(GoogleやOffice365やGitHubなど)のログイン画面などは、パネル内で表示されないことになります。

一方で、クライアント版では普通に表示されます。
なので、最初にクライアント版でログイン画面が表示され、よしこのままOnline版もやっちゃおう！となった場合、
このことを知らないと、Office Onlineでは確実にエラーになってしまいます。

回避方法もあるが、IEで以上に面倒なことになる

これを回避するために、office-js-helpersという仕組みも用意されています。
これは、ログイン画面をOfficeアドイン内ではなく、ダイアログを起動してログイン画面を表示する仕組みです。

上記のように、アドインとは別のダイアログを起動します。
未ログインの状況であれば、そのままログイン画面が表示され、IDパスワードを入力し、ログイン完了したら、ダイアログを自動で閉じて、アドイン側にトークンを受け渡す、という仕組みです。
ダイアログ内で表示するので、iframeの制約にも引っかかることなく、ログインを行うことができます。

これを使えばいいじゃないか、と思うかもしれませんが、今度はIEの場合で、「信頼済みサイト」の問題が出てきます。
「信頼済みサイト」の問題とは、簡単にいうと「ブラウザ内のすべてのサイトを、同一のセキュリティゾーンに入れなければいけない」、という制約です。

例えば、Office365にログインを行ってアクセストークンを取得し、Office365の情報を取得するようなアプリを考える場合。
この場合、以下のページの信頼済みサイトを揃える必要があります。
「Office OnlineのSharePointサイト」（https://foobar.sharepoint.com）
「アドインの本体のサイト」（https://foobar1234567.azurewebsites.net）
「Office365ログインページ」(https://login.microsoftonline.com)

「揃える」とはすなわち、
「すべて信頼済みサイトに入れる」か、「すべて信頼済みサイトに入れない」の、どちらかです。
これが揃っていないと、エラーが発生します。

そしてこれが厄介なのが、『いつの間にか、Office OnlineのSharePointサイトが追加されていることがある』ということです。
Office365をいじっているときなのか、クライアント版のOfficeにアプリのURLを追加した場合なのかは分かりませんが、気付いたらこのSharePointサイトが信頼済みサイトに追加されているときがあります。
そうなると、アプリが起動できなくなります。その場合には、残りのサイトを追加する必要があります。

そして、この一連の流れを、アプリを利用する利用者にやってもらわなければなりません。
会社でポリシー配布などを行っていればいいですが、そうでない場合でIEで実行を行う場合に、すべての利用者に、この信頼済みサイトの追加をやってもらわなければなりません。・・・まあ、超面倒ですね。
対策としては、「IEをサポートから切り捨てる」というのも有りかもしれないですね笑

Windows10のIE11で、データのやり取りが正常に動作しない場合がある

上記のダイアログ形式で、アクセストークンのやり取りをするわけですが、ここまでやっても、正常に動作しないことがあります。
それはどうも、Windows10の、一定時期より古いIE11だと、正常に動作しないようです。
かんたんに調査してみたでのすが、

• ダイアログ同士のデータのやり取りは、標準ではjavascriptのpostMessageで行う
• だが、IEではpostMessageに対応していないので、localStorageの監視によりデータをやり取りしている
• だがだが、Windows10のIE11だと、上記の「IEかどうか」という条件が正常にしておらず、うまく動かない（Office.jsのバグ？）
• そのため結果的に、一部のWindows10のIE11だと動作しない

ということで、Windows10のIE11だと、うまく動かないことがあるようです。
なので、最終的な結論としては、Online版はIE非推奨にしてしまうのが一番ですね。（切実）

まとめ

Officeアドインはどうにも伸び悩んでいます。
その背景は多々ありますが、一つはこの地雷の多さにあると、私は思っています。
それでも、Officeアドインで開発する！という事になった場合、まずはこの記事を読んでいただき、どんな地雷があるかどうか、知ってもらえると嬉しいです。

Officeアドインで、設定値を保存したい場合。
例えば、アプリの表示言語を変更・設定できるようにしたい場合、 設定値を保持することが出来れば、アプリを再起動した場合でもわざわざ再設定する必要が無くなって便利ですね。

このような機能を実装したい場合、果たしてどのように開発すればいいでしょうか？
その方法について、実は2つの方法があります。
その2つの方法はどのようなものか？ その使い分けも含め、今回はその開発方法について解説します。

■解説

上記でも記載した通り、Officeアドインで設定値を保存する方法は主に2つあります。
それぞれメリット・デメリットあるので、それぞれ見てみましょう。 　

①Officeアドインの関数"Settings.set"を使用する

"Office.context.document.settings.set"というメソッドを使用することで、 Officeのドキュメントに名前/値のペアとして設定値を格納します。
参考：https://msdn.microsoft.com/ja-jp/library/office/fp161063.aspx

イメージとしては、Officeファイルに名前/値のペアとして設定値を格納することになります。

Officeファイルに格納するので、保存時とは別のOfficeファイルを開いた場合は、その設定値を読み込むことは出来ません。別の値として扱われます。

一方で、別ユーザーが同じファイルを読み込んだ場合は、すでに保存済みの設定値を読み込むことができます。
これはファイルそのものに設定値を書き込みしているので、どのユーザーが開いても同じ設定値を利用することが出来るのです。

②HTML5の機能"LocalStorage"を使用する

LocalStorageは、HTML5で新たに追加された機能です。
ブラウザ側に名前/値のペアとして設定値を格納する事ができます。
http://wp.tech-style.info/archives/742

「OfficeなのにHTML5の機能を利用できるの？」と思う方もいるかもしれませんが、 OfficeアドインはれっきとしたWebアプリケーションなので、問題なくLocalStorageを使用できます。
OfficeアドインでLocalStorageを使用した場合、そのアプリ内では共通して同じ値として管理されます。
つまり、別のOfficeドキュメントでアプリを起動した場合でも、同じ設定値を保存・読込することが出来ます。わざわざ保存し直す必要がなくて便利ですね。

しかし、別ユーザーが同じファイルを開いたとしても、同じ設定値を使用することは出来ません。 そこはご注意下さい。

③結局どっちがいいの？

ぶっちゃけ用途によります。 以下、簡単にまとめてみました。

※Settings.set関数
・ドキュメントに設定値を格納する
・同じファイルを開いた場合、どのユーザーであっても同じ設定値を保存・読み込むことができる
・別のファイルを使用した場合、設定値は共有されない
・Excelセルに記載された金額・人物名など、各Officeファイルに紐付いた値を保持しておきたい場合におすすめ

※LocalStorage
・ブラウザに設定値を格納する
・保存時とは別のファイルを開いた場合でも、設定値を共有することができる
・別のユーザーが保存時のファイルを開いた場合、設定値は共有されない
・アプリの表示言語など、実行したユーザーごとに異なる設定を保持しておきたい場合におすすめ

開発したいアプリの用途によって使い分けることをおすすめします。 もちろん両方使用することもアリでしょう！ あなたの開発にお役立て下さい。

■おわりに（自己紹介）

まだまだマイナーながら、無限の可能性を秘めた「Officeアドイン」の解説記事を少しずつ執筆しています。
もっと詳しく知りたい！といったことや、この内容を解説して欲しい！ということがありましたら、 コメントなどにてお気軽にご連絡ください。

前回の記事で、Facebookアプリの仕組みと、そのリスクや、巷で言われていることの真偽を記載しました。
https://develop.kajitori.co.jp/?p=97

その中で特に言いたかったのは、

• Facebookアプリを使っても、アカウントが乗っ取られることはない
• Facebookアプリが、アプリを使用していない別の友だちの情報を取得することはできない
  といったことです。

なので、「Facebookアプリを使用すると、パスワード流出して乗っ取られるよ」「友だちの情報を守るためにFacebookアプリを使用するな」といった記事が散見されますが、
そのような記事は盛り過ぎなのでご注意ください。
※ただし、アプリからタイムラインに投稿されるリスクはあります。それは前回の記事参照

しかし、個人情報提供のリスクについては、注意が必要です。
巷では、すでにアプリを使用している方に対し、「対策はアプリの削除」というものがあると言われています。
しかし、それだけでは済まない、非常に重要なリスクがあります。それは、「後でアプリ削除すればいいや」では済まない問題です。
今回はその点を解説します。いつものように技術的な観点も含みます。
結論だけまとめた分かりやすい記事は、誰かにお任せします笑

先に結論を書くと(最低限これだけ)

• Facebookアプリを使用した場合の対策として、Facebookから「アプリの削除」を行うというものがあるが、それはあくまでも、「新しくFacebookから情報を取得できない」ということだけ
• 一度でもアプリを使用すると、それだけでアプリの開発者（業者など）に個人情報を渡す
• そして、その個人情報は永続的に保管される可能性がある
• それが嫌な人は、やはりアプリを使用しないのが吉
• ただ、Facebookアプリは実は浸透しているので、どのアプリを使用するか、必ず吟味すること

データベースについて(システム的なお話)

Facebookアプリをはじめ、一般的なシステムでは、「データベース」と呼ばれる仕組みを備えています。
データベースとは、ざっくりいうと「情報を貯めて、情報の検索や更新などに使用するための仕組み」のことです。

例えばTwitterだと、
・TwitterのユーザーのIDやメールアドレス、表示名
・つぶやいた日時、投稿
・つぶやきの「いいね」や「リツイート」
などは、すべて「データベース」とよばれる仕組みに蓄積され、WebページやTwitterアプリで使用されます。

他の例としては、ソシャゲのパズドラで、
・パズドラのユーザー情報
・所有しているモンスター情報
・ダンジョン攻略情報
などもすべて、データベースに保持しています。（※パズドラあんまり詳しくないです）

このように、システムを構築する際には切っても切れない仕組み、それがデータベースです。

では、Facebookアプリではどのように、データベースを使用しているのでしょうか？
※それぞれのFacebookアプリで使われ方は違いますので、あくまでも「こう使われているかも、可能性がある」というニュアンスで読んでください。すべてのFacebookアプリがこの例ではありません。

まずは、ログインユーザーごとの「アクセストークン」を保存しています。
アクセストークンは、前回も記載したように「Facebookからユーザー情報などを取得する際に使用する文字列」のことです。
※詳しくは前回参照

このトークンを保存しておくことで、今後ユーザーが再ログインしなくても、Facebookからユーザー情報などを取得することが出来るようになります。
ユーザーはわざわざFacebookにログインする必要がなく、アプリを使用できるようになるので、結構便利です。

そして、こっからが非常に重要なのですが、Facebookから取得したユーザー情報、すなわちidや名前など公開情報を、データベースに保存しています。
これはアプリ内で、名前などを表示するために使用しています。

Facebookアプリの対策「アプリの削除」について

診断系Facebookアプリの危険性を謳っているサイトで、対策としてだいたい書いているのが、「アプリの削除をする」です。
具体的には、Facebookの設定画面の「アプリとウェブサイト」から、該当するアプリを削除することです。

https://www.facebook.com/help/204306713029340

不審なアプリがあったとして、この手順は正しいです。この手順を行うとどうなるかを解説します。

アプリを削除すると、Facebookアプリがアクセストークンを使って、Facebookから情報を取得することが出来なくなります。

他にも、Facebook設定からアプリを削除することで、Facebookアプリがタイムラインに、投稿を行うことも出来なくなります。
そのため、不審なアプリを設定から削除するというのは、間違いなく必要な手順です。

ですが、ここで大きな落とし穴があります。
先ほど、各Facebookアプリでは、データベースという仕組みで、個人情報などを保存している、という話をしました。
ですが、Facebook設定からアプリを削除しても、このFacebookアプリのデータベースから、あなたの個人情報が削除されることはありません。
あくまでも、「新しく」Facebookの情報をアプリが取得できないだけで、
データベースに保存済みのデータは削除されることはなく、永続的に保存されたままです。

ネガティブに言い方を変えると、
Facebookアプリで「Facebookにログイン」をし、アプリにログインを行った時点で、その後設定からアプリを削除したとしても、あなたの情報は業者のデータベースに、ずっと保存されたままになります。

もしアプリの開発者が、非常に悪徳な業者であった場合、このデータベースに保存した情報をもとに、おそらく悪いことをしていくことになるでしょう。
スパムメールを送ったり、・・・その他色々なことが起きてしまいます。

仮にこんなアプリに、一度でもログインしてしまったら、
あなたの氏名も誕生日も、出身地も写真も動画も性別もタイムラインも年齢層も、すべて・・・ずっと保存されたままです。
非常に非常に危険ですね。

対策

確かに、アプリ利用による乗っ取りは起きません。
そして、アプリを利用していない友達の情報を、アプリが取得することも出来ません。なので関係ない人に迷惑をかけることもありません。

しかし、この「アプリに個人情報を渡す仕組みやリスク」については、重々承知する必要があります。

この対策ですが、適切かつ明確なのが、
アプリを利用しない
というのが一番です。

ですが、このFacebookアプリの仕組み、実は意外と色んなところで使われています。
例えば前回紹介した「キャンディークラッシュ」。

これもFacebookの友達情報と連携して、アプリに活用しています。
なので、厳密に言えばこのようなアプリも使用できなくなります。

他にも、グルメ系の投稿サイト「Retty」も、Facebookログインを用意しています。

このサイトを利用する場合、このRettyにも、他のアプリと同様に情報を提供することになるので、ログインできなくなっちゃいます。

すなわち何が言いたいかと言うと、このFacebookアプリの仕組み、すでに世の中で色んな所で使われているわけです。
もし、本当にこれらを使わない、となると、けっこう不自由を受ける可能性があります。
悪いのは悪徳な業者です。真っ当な会社やシステムであれば、本来であればアプリを利用しても問題ないはずです。

なので大切なことは、
・どのアプリを使用するかどうかを、必ず吟味すること。情報を提供する先の会社はどんな業者かを必ず確認すること
・Facebookアプリにログインする前に、「受け取る情報」がどうなっているかを必ず確認すること
・一度でもアプリにログインを行ったら、その後アプリを削除したとしても、情報はアプリに渡っていることを理解すること
・すべては自己責任
ということです。

結論

不安だったら利用しない
すべては自己責任と理解した人だけアプリを使用すべし

はじめに

最近、筆者の周りで
「Facebookの診断系アプリは危険」
「あらゆる個人情報を、業者に渡すことになる」
「やってしまうと、Facebook乗っ取られたり、投稿」
「やってしまった方は、今すぐパスワードを変更して二段階認証を設定するべき」
という話が上がっていました。

Facebookの診断系アプリというと、例えば今だと以下のようなものです。

これ系のアプリの診断結果は、ちょいちょいFacebookのフィードにも上がってきますね。

これらのアプリをあまりやらないほうがいいのは、筆者も同意見です。
ですが、「ものすごく危険」「やると乗っ取られる」といったこととは、事実と若干異なる部分があります。

そこで今回は、

• Facebookアプリとはそもそもなにか
• どのような情報を取得しているか
• どのような仕組みなのか
• 巷で言われていることの事実・間違いの切り分け

を、可能な限りシステム疎い方でも分かるように、頑張って解説していこうと思います！

※個人の見解を含みます。また間違いや情報の更新などございましたら、ご指摘いただければ幸いです。

先に結論を書くと(最低限これだけ)

• Facebookアプリはパスワードを盗めないから乗っ取りも出来ないから安心しろ
• あなたの友達がどんなアプリを使用していても、あなたには影響がない
• ただし、アプリの設定によっては「あなたに代わって投稿」は出来ちゃうから、そこだけ注意
• また、アプリの設定によっては「個人情報を不必要に悪用」されるリスクはある
• 100％安全というわけではないので、アプリ使用時の設定を必ず確認し、自己責任で使用すること

Facebookアプリとは？

ざっくり言うと、Facebookの情報を使用したアプリすべてです。
それはWebサイトの場合も、スマホのアプリの場合もあります。

例えば、前述したWebサイトの「nametests.com」は、典型的なFacebookアプリです。
https://ja.nametests.com/

Facebookの情報を使用して、診断や占いなど行うものですね。

一方で、スマホのアプリでも、Facebookの情報を使用しているものがあります。
例えば、一時期筆者もやっておりました「キャンディークラッシュ」。
これはアプリの設定で、「Facebookでログイン」という表記がされています。

よくある診断系だけでなく、このようなスマホのアプリも、立派なFacebookアプリです。

そして、そのFacebookアプリをユーザーがはじめて使用するとき、このような表示がされます。

よく見るやつですね。
そして、「裕としてログイン」をクリックすることで、アプリ（写真の場合はnametests.com）が、ユーザーの情報を取得することができるわけです。

Facebookアプリの仕組み

さて、ここからはFacebookアプリの仕組みを、簡単に解説します。
順を追って解説していきますね。

開発者がFacebookアプリを作る時

開発者がFacebookアプリを開発する際、「このアプリは、Facebookのどの情報を取得するか？」という情報を、開発者はあらかじめ設定しておきます。
例えば、

・ユーザーのEメールアドレス
・ユーザーの写真一覧
・ユーザーの誕生日
・ユーザーの性別
・ユーザーのタイムライン一覧
・友達リスト
といった情報です。

このような情報を、アプリごとに、あらかじめ設定しておく必要があります。ちなみにこれらの設定を「スコープ」といいます。

なお、ここで1点特記事項としては、これらの項目として、パスワードを設定することは出来ません。
Facebookアプリはパスワードを取得することは出来ませんし、変更することも出来ません。

ユーザーがFacebookアプリを使用する時

そして、Facebookアプリを使用する場合です。
下の画像のように、Facebookアプリを使用する際、「Facebookにログイン」のボタンをクリックします。

すると、上にも貼り付けた画像が表示されます。

ここで重要なのは、赤線で囲った部分です。
これは、これから使用するFacebookアプリが、Facebookから取得する情報・もしくは使用する権限を、一覧で表示します。

ちなみにキャンディクラッシュの場合はこちらです。

「友達リスト」が含まれていますね。なのでキャンディクラッシュは、ログインしたユーザーの友達リストも取得することができるようになっています。
（そして、この「友達リスト」についても重要な事実があります。詳しくは後述します）

ユーザーは、ここに書かれている情報を確認することで、「これから使用するFacebookアプリは、いったいどんな情報を使用するか」ということを、確認することができるわけです。

なので、必要以上にてんこ盛りだと、「あれ、なにか怪しくない？」となるわけです。
設定を大量にぶち込むと、こんな感じになります。

これはあからさまに怪しいですねｗこのようなアプリは怪しいので、ユーザーは使用しない方がいいです。

ユーザーがFacebookにログイン後、アプリで行っていること

「Facebookにログイン」を実施した後、アプリ内部でどのような処理を行っているかを説明します。

まず、ログインすることで、Facebookから「アクセストークン」と呼ばれる、超長い文字列が返ってきます。

こんな感じの文字列です。実際には200字以上あります。

この文字列を使用して、アプリはFacebookから、情報を取得するわけです。
例えば、ログインユーザーのプロフィールを、アプリから取得したい場合、

・先ほど取得したアクセストークン
・取得したい内容
この2点をFacebookに渡します。

こうすることによって、Facebookはプロフィール情報を、アプリに送り返すわけです。

ちなみにここで取得できるのは、ユーザーがログインしたときに設定している、「スコープ」の範囲内です。
上の画像で使用している例でいうと、アプリBでは「友達リスト」を設定しています。
そのため、アプリは友達リストを取得することができます。

一方、アプリAでは「友達リスト」を、取得する情報として設定していません。
そのため、仮にアプリAが友達リストを取得しようとすると、エラーが発生して取得できません。

このように、Facebookから情報を受け取ったアプリは、この情報を使用して、その後のプログラムで活用できることになります。

※この仕組みは、システム用語で言うと「API」と呼ばれます。
また、ログインなどの仕組みを「認証」「認可」、Facebookアプリで採用している仕組みは「OAuth2」と呼びます。
テストには出ないです。

これが、Facebookアプリの一連の流れです。
ここで重要なのは、
・Facebookアプリでは、ログインユーザーのパスワードを受け取っていないし、受け取ることは決して出来ない
・ログインユーザーの情報は、「アクセストークン」と呼ばれる超長い文字列を使用することで、取得できる。そしてこれは、パスワードを使用しない
・Facebookアプリがアクセストークンを取得するためには、ログインユーザーが一度、「Facebookでログイン」ボタンを押す必要がある
ということです。

巷で言われている話の真偽、QA

これらの話を踏まえ、Facebookアプリ（特に診断系）について、巷で言われていることの真偽やQAをまとめていきます。

Facebookアプリを使用すると、アカウントが乗っ取られる！！

「乗っ取られる」の定義が何かによりますが、「IDパスワードが盗まれる」「自分のアカウントを誰かに勝手に使われる」という意味だと、それはNOです。
なぜなら、Facebookアプリはログインユーザーのパスワードを取得することが出来ないからです。
パスワードを取得出来ないので、悪意のある開発者が、その後のアカウントをどうこうしようとしても、それは出来ません。
※ただしFacebookアプリでは、「タイムラインの投稿」というスコープがあります。これは文字通り、Facebookアプリが、ログインユーザーのタイムラインに投稿をすることができる権利です。
そのため、アプリのスコープに「タイムラインの投稿」が含まれていた場合、悪意のあるアプリが、ユーザーにタイムラインに投稿することは出来てしまいます。そこは要注意です。

診断系アプリを使用してしまったら、今すぐパスワード変更をして二段階認証を設定すべき！

これは意味がないです。なぜなら、もうおわかりだと思いますが、Facebookアプリはパスワードを使用していません。
いくらパスワードを変更しようとも、二段階認証を設定しようとも、アクセストークンが有効な限り、Facebookアプリはあなたの情報を取得できてしまいます。
なのでこの点に関しては、二段階認証も無意味です。
（ただ一般論として、現代では二段階認証の有無で情報流出のリスクが段違いなので、二段階認証は設定するようにしてくださいね）

アプリを使用すると、個人情報を抜かれるんでしょ？

これは、上で解説している「スコープ」次第です。スコープで設定した内容のみ、Facebookから情報が取得できます。
ちなみに標準設定だと、アプリが取得できるのは、
※2018/09/02 1:00訂正
・id
・名前
・公開プロフィール(プロフィール写真、性別など)
です。
※当初、idと名前のみと記載しておりましたが、公開プロフィールも含まれておりました。訂正いたします。
なお、公開プロフィールは、Facebookに登録していなくても、誰でも閲覧できる情報になります。

これらはFacebookの画面からかんたんに取得できる、公開情報になります。
それ以上の情報は、アプリごとに設定されているスコープ次第です。ログイン画面でユーザーが許可した内容のみ、Facebookアプリに渡すことになります。

この設定によって、例えば以下のような情報をアプリに渡すことになります。
・メールアドレス
・誕生日
・写真
・タイムライン投稿の一覧
なにかに悪用しようと思えば十分ですね。
そのため、Facebookアプリを使用する場合、ログイン時の「受け取る情報」がどうなっているかを確認し、自己判断で行ってください。
ちなみに、実際に個人情報悪用のニュースもあるようです。
https://r.nikkei.com/article/DGXMZO29264270R10C18A4X11000?s=0

友達のあの人がFacebookアプリを使用すると、自分の個人情報まで流出するからやめろ！！

これは明確にNOです。
その根拠は、Facebook APIの「友達リスト」の仕様に記載があります。
https://developers.facebook.com/docs/graph-api/reference/v3.1/user/friends
ざっくり和訳すると、以下になります。

↓↓↓↓↓↓
友達リスト
あなたに以下の情報を提供します
・このFacebookアプリをインストールした、あなたの友達ユーザーの一覧
・あなたの友達ユーザーの総数（このFacebookアプリをインストールしていないユーザーを含む）
↑↑↑↑↑↑

つまり、悪意のあるアプリを友達が利用しちゃってたとして、あなたがそのアプリを使用しない限り、あなたの情報を友達が取得することは出来ません。

キャンディークラッシュを例にとります。キャンディークラッシュのアプリで取得できる、Facebookの友達の情報は、すでにキャンディークラッシュをインストールしている友達のもののみです。
キャンディークラッシュを使用していないユーザーの情報を、キャンディークラッシュが取得することは出来ません。

なので、どれだけ友達が変なアプリを使用していようが、イライラする必要はないです。ご安心を。

じゃあなんでレイ○ンの投稿や乗っ取りは終わらないの？

Facebookアプリとは別の原因の可能性が高いです。例えばパスワード使い回しとかね。
最低限パスワード使い回しは辞めて、二段階認証の設定は行いましょう。起こってからでは遅いです。

他のブログで、「個人情報が抜かれる！！」「こんなのやる人は頭が悪い！！」と書いてあったんだけど

たぶん技術的なことが分かっていない人が書いたブログだと思います。それかアクセス稼ぎか。
「Facebookにログイン」のときに書かれている項目以外の情報が、Facebookから抜き出されていたとしたら、それはFacebookの大セキュリティ事故です。それも株価大暴落ってレベルじゃない。
そんなことができるとしたら、真っ先にこっそりFacebookに報告しましょう。すごい報酬がもらえるはずです。
・・・まあ、それぐらい有り得ないレベルですね。

結局、Facebookアプリは100％安全なの？

100％安全という訳ではないです。
乗っ取りや、関係ない友達の情報を悪用されることはありませんが、あなたの個人情報悪用のリスクがあります。

難しくて、良く分からなかった！

アプリを使用しないのが無難です。

まとめ

以上、Facebookアプリの仕様をまとめました。
昔はFacebookアプリは、割と自由だった記憶があります。なので友達の情報を勝手に利用とか、そういうことが起きていたのかもしれません。
が、最近厳しくなったようです。悪意のある業者が勝手に投稿など行ったんでしょう。
それもあってか、少なくとも2018年現在では、アプリに関するセキュリティはかなり厳重になっております。なので、悪意のあるアプリによる被害というのは、限りなく低いと思います。
（考えてみると、Facebookアプリのそういった投稿、昔に比べて減ってますよね）

ただ、それでもリスクが無いわけではないです。
例えば診断系のアプリでは、写真を使うものがあります。
「写真を取得」のスコープを設定すれば、アプリがログインユーザーの写真を取得することが出来ますので、その写真を使って、どうこうすることは考えられます。

なので、やはりFacebookアプリを使用する場合は、自己判断で行うほうが良いです。
そのアプリが信頼できる業者なのか、その辺は自分自身で判断してください。

最後に

Facebookアプリが、情報を取得できないようにする方法です。
この方法を実行すれば、実行後はFacebookアプリは、一度許可していたとしても、情報を取得することができなくなります。
その手順は以下のURLをご参照ください。（書こうとしたけど力尽きた）
https://www.facebook.com/help/204306713029340

つづき

個人情報提供のリスクについて書きました
https://develop.kajitori.co.jp/?p=100