Archive for August, 2015

Microsoft Office Add-ins Short Video (Apps for Office)

Outlook/PowerPoint/Excel/Outlook Office Add-ins の概略がわかります。 以下のURLから一度閲覧するとわかりやすいです。 http://dev.office.com/snack-videos?utm_content=buffer7f4ef&utm_medium=social&utm_source=facebook.com&utm_campaign=buffer しかも英語字幕つきますので、ヒアリングに自信のない方も大丈夫です!!   ビデオ例

PHP+UnifiedAPI(Office Dev Show – Episode 4)

PHP(MAC上のエディター)にてOffice365から Azure + Office365 Unified APIでUser/Group情報を取ってくる。 完全にREST APIというのがVSわからない人でもわかりやすい

Office365の情報を取得するデスクトップアプリケーションの開発

AzureADにサインインし、Office365の情報を取得するために必要な リフレッシュトークンとアクセストークンを取得する 簡単なアプリケーションの作り方を記載します。 用意する物 ・VisualStudio 2013 ・Office365 (SharePoint、Azure AD) ■リフレッシュトークン?アクセストークン? 2種類トークンという言葉が出ておりますが、 リフレッシュトークン=ログインしたという情報 アクセストークン=使用可能なリソースの情報(権限) という形で覚えると分かりやすいと思います。 ■AzureADの設定 Office365の情報を使用する際は、AzureADにOffice365のアプリケーションを使えるようにする設定が必要なので、 Office365の管理者またはAzureポータルサイトからAzureADに入ります。 設定できない場合はOffice365の管理権限を持つ方に相談してください。 1.Azure内のActiveDirectoryに入り、ネイティブアプリケーションを作成 2.作成したアプリの構成を確認し、「リダイレクトURI」と「他のアプリケーションに対するアクセス許可」を変更する ※初期ではWindows Azure Active Directoryだけ入っているので、アプリケーションの追加を押して追加する 3.設定が完了したら保存する 赤丸の部分が追加した情報です ■リフレッシュトークン、アクセストークンを取得する方法 https://login.microsoftonline.com/common/oauth2/tokenにアクセスし grant_typeにpasswordか、authorization_codeを指定 HTTPヘッダのContent-Type にapplication/x-www-form-urlencodedを指定 ○grant_type=passwordの場合 パラメータ(下記はPOSTメソッドで送信) grant_type=password client_id = AzureクライアントID user = ※ユーザーID password = パスワード resource = リソース(SharePoint)のURL ※ユーザIDはOffice365の管理権限を持つアカウントで確認してます。 grant_type=passwordのケースに関してはリクエスト結果からアクセストークンが取得できます。 ○grant_type=authorization_codeの場合 URLパラメータ(下記はPOSTメソッドで送信) grant_type=authorization_code code = リフレッシュトークン client_id = Azure ADのクライアントID redirect_uri = Azure ADで指定したリダイレクト先 resource = リソース(SharePoint)のURL こちらのケースの場合はリフレッシュトークンを別な方法で取得しないといけないので、あらかじめ次の処理を行います。 https://login.microsoftonline.com/common/oauth2/authorize?response_type=code&client_id=(Azure ADのクライアントID)&redirect_uri=(Azure ADで指定したリダイレクト先) からサインイン画面を表示し、サインイン後にリダイレクトした先のURL内に含まれるcodeパラメータを保持する ※code情報がリフレッシュトークン これでアクセストークンの取得は完了です。 アクセストークンの有効期間(1時間程度)が切れたときは、リフレッシュトークンを用いて再度取得しましょう。 VisualStudio2013向けサンプル用プロジェクトを作りましたので、よろしければご確認ください。 野本 育男

SharePoint AccessToken/RefreshToken

この記事は書きかけです。 いくつかSharePoint Add-insを作成していて、気が付いた点をメモします。 SharePoint AccessToken/RefreshToken いくつかポイントがあるのですが、わかる範囲で記載しておきます。 Access Tokenの種類 参考 Inside SharePoint 2013 OAuth Context Tokens ACS 00000001-0000-0000-c000-000000000000 Exchange 00000002-0000-0ff1-ce00-000000000000 SharePoint 00000003-0000-0ff1-ce00-000000000000 Lync 00000004-0000-0ff1-ce00-000000000000 Workflow 00000005-0000-0000-c000-000000000000   AccessTokenの有効期限は1時間 実際にテストをする約1時間(2015/08/10時点)でした。 AccessTokenが期限切れになりましたら、RefreshToken(おそらく有効期限が長いはず)でAccessTokenを再取得します。   参考 松崎さんBlog Native Application (Mobile App) で Azure Active Directory に Login するプログラミング (OAuth 紹介) また、Access Token の有効期限は、約 1 時間です。Access Token が期限切れになった場合にも、上記の通り Refresh Token を使って Access Token を取得しなおします。 補足 : refresh token は最大 14 日使用可能で、再取得することで、さらに 14 日間使用できます。(最大で 90 日まで使用できます。)   Micrsosft Sample Office 365 API Tools を使用したプログラミング Access Token と Refresh Token アプリケーションが Exchange のサービスに接続する際、内部で Access Token と呼ばれる文字列が使用されています。この Access Token を使用して、アプリケーションは、その他の処理も継続して実行できます。 また、Access Token には有効期限があり、1 時間で使用できなくなりますが、この場合は Refresh Token と呼ばれるものを使用して、再度、Access Token を取り直します。 上記の AcquireTokenSilentAsync では、こうした面倒なトークンの扱いも自動化してくれています。 また、Access Token や Refresh Token をキャッシュしてアプリケーション終了後もこの値を保持することで、同じアカウント情報で継続して利用することが可能です。(上記のサンプルでは、このキャッシュの処理はおこなっていません。)   野呂清二

Making SharePoint Add-ins + Azure Session

こんにちは野呂です。 SharePoint Add-insのSession(セッション)管理でクラスの一部でシリアル化がうまく出来ない問題がありますので、解決策を一番下にリンクしました。 解説 SharePoint Add-ins でアプリを作成してリリースすると、そのままテンプレートを使用すると下記のエラーがでます。 セッション状態をシリアル化できません。’StateServer’ および ‘SQLServer’ モードでは、ASP.NET はセッション状態オブジェクトをシリアル化します。その結果、シリアル化できないオブジェクトまたは MarshalByRef オブジェクトは許可されません。’Custom’ モードのカスタム セッション状態ストアによって類似したシリアル化が実行される場合、同一の制限が適用されます   Web.config のSession は、なにも記述されていないので、”InProc” になっています。 なので、”Azure Redis Cache” 、”SQL Server”, “ASP.NET Universal Providers and Session State”等を使用してセッションを保持する仕組みを設定する必要があります。 しかしながら、SharePoint のToken/RefreshToken 管理クラスである。 いくつかのAccessToken管理クラス(SharePointContext他)は標準ではSeriazaibleではありませんので、InProc以外のセッションのSQL Azure, Redis Cache、等はクラスをシリアル化しなければならないです。 しかしながら、いくつかのクラスはライブラリ(dll)の中に定義してありシリアル化の定義ができないので、プログラムを別途作る必要があります。 MSDNにサンプルがありました。私も、実際に Universal Providers でテストしてOKでした。 参考までにどうぞ Making SharePoint Apps Scale with Azure Redis Cache 野呂清二