松崎 剛 Blog

This Blog's theme : エンタープライズ開発 (Server side)、Office サーバ開発

SharePoint 2013 Apps で token が null になる場合の対処 (Workaround)

SharePoint 2013 Apps で token が null になる場合の対処 (Workaround)

  • Comments 0

こんにちは。

.NET CSOM を使ったプログラミングと認証 (Authentication)」で解説したように、Apps for SharePoint 2013 (SharePoint 用アプリ) では、認証用の Token が使用されており、これが正しく取得できないと、SharePoint にアクセスできません。
そして、なんと、Apps for SharePoint 2013 の開発 (Debug) の最中に、この Token (SPAppToken) が null になる現象が発生することがあります。たまに発生するという類のエラー (例外) ではなく、一度こうなってしまったプロジェクトは、何度コンパイルしなおしても、作り直しても、この現象から回避できません。
今回は、この原因と対処方法について解説します。

実は、数週間前に Apps のトレーニングが実施され、ここでも一部の参加者の方のマシンで同様の現象が発生しましたが、そのときは時間切れで細かく見れませんでした。(力不足ですみません。。。) そして、つい最近、遂に私の環境でも発生したので、夜中に確認してみました。。。(この現象に出会うのを待ってました !)

 

原因

この原因は、デバッグ実行の際に使用される IIS Express の https (SSL) の URL が、Windows Azure Active Directory (Office 365) に登録されている Application Principal (Service Principal) の URL と重複している場合に発生します。要旨を記載します。

  • Visual Studio は、Debug の際に、使用する Web アプリケーションの Applicatoin Principal として、Id や Url の情報などを Windows Azure Active Directory に登録します。(Provider-hosted の場合は、以前解説したように、AppRegNew.aspx を使って事前登録できます。)
  • この際、もちろん、同じ Id の Application Principal や、同じドメイン (domain) の Application Principal は登録できません。
    つまり、もし、プロジェクトで https://localhost:44304 が使用されていると仮定し、既に同じドメイン (localhost:44304) の Application Principal が登録されている場合、Visual Studio はこの登録をおこなわず、代わりに http (Non-SSL) のドメインを登録します。
  • この結果、登録は成功します。しかし、App が Debug 実行される際は https (SSL) でホストされるため、この App のドメインは localhost:44304 ですが、Windows Azure Active Directory にはこのドメインの Application Principal は別の情報 (Client Id) で登録されているため、結果として null の token を App に渡します。(つまり、許可されていないと判断されます。)

通常は、Debug 時に登録された Application Principal は、ブラウザーを閉じると削除されます。しかし、Debug で中断した場合など、簡単な理由で、この Application Principal が残ってしまいます。

 

確認方法

まず、説明の必要はないと思いますが、Visual Studio のプロジェクトで使用している https (SSL) のドメインは、プロジェクトのプロパティ ウィンドウで確認できます。(下図)

また、Windows Azure Active Directory に登録されている Application Principal の確認は、「Windows Azure Active Directory と事前準備」に記載した手順で、下記の通りコマンドを入力して確認できます。(一覧が表示されます。)

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe  -version 2.0
PS> Import-Module MSOnline
PS> Import-Module MSOnlineExtended
PS> $cr=Get-Credential
PS> Connect-MsolService -credential $cr
(rem -- id/password prompt appears. and please login !)
PS> Get-MsolServicePrincipal -All
(rem -- check your app principals !)

上記の 2 つの結果を見比べて、同じドメインの Service Principal が既に存在していないか確認してみてください。

 

対処方法

上記の動作 (解説) からお分かりの通り、対処方法は 2 つあります。

まず 1 つ目の対処方法が、Visual Studio 側の Debug で使用するサーバー (IIS Express 上の Web サイト) のドメインを変更する方法です。
IIS Express で、あれこれ」でぼやいたように、プロジェクト (つまり、サイト) で使用するサーバー (ポート番号など) は、プロジェクト (つまり、サイト) の絶対パスをキーとして %userprofile%\Documents\IISExpress\config\applicationhost.config に定義されています。そこで、メモ帳を管理者権限で実行して applicationhost.config を開き、該当の箇所のポート番号を変更します。(Windows Azure Active Directory に登録されている Application Principal のドメインと重複しないポート番号に変更します。) 再度、Visual Studio のプロジェクトを開きなおすと、変更されたポート番号がプロジェクトに反映されます。Debug 実行をおこなうと、問題なく動作するはずです。

補足 : ここでは詳細の手順を省略しますが、WebMatrix を使って、IIS Express に登録されているサイトを削除しても構いません。(ゴミは、どんどん消してもらって構いません。Visual Studio でプロジェクトを新規作成すると、再作成されます。)

もう一方の対処方法は、Windows Azure Active Directory 側の重複している Application Principal のほうを削除する方法です。
下記の通り、コマンドを入力します。(下記の Guid は、上記の Get-MsolServicePrincipal コマンドの出力結果として表示される AppPrincipalId です。)

PS> Remove-MsolServicePrincipal -AppPrincipalId <Guid>

いずれにせよ、開発中に、ゴミは、まめに消しておくと良いでしょう。面倒なトラブルの原因となります。
なお、間違えて、既定で入っている Application Principal を消さないように注意しましょう。(Get-MsolServicePrincipal コマンドの出力結果に表示される DisplayName を確認して消してください。)

 

稀に発生するように思われるかもしれませんが、考えてみれば、頻繁に起こるはずです。(むしろ、よく今まで発生しなかったと感心しています。。。) 例えば、チーム開発の際や、PC (開発機) を変えた際なども要注意です。単純な理由で、IIS Express が作成するポートは重なります。
以前、SharePoint User Group にお邪魔した際にもお伝えさせていただきましたが、SharePoint 開発者の方にとって、今後、Windows Azure Active Directory は必須の技術となるので抑えておいてください。

 

Leave a Comment
  • Please add 3 and 1 and type the answer here:
  • Post