2017-01-10 12 views
0

Outlookのデスクトップアドインで、Microsoft Graph APIのトークンを受信すると、次のエンドポイントからユーザーの電子メールメッセージを取得する呼び出しが行われます。https://graph.microsoft.com/v1.0/me/Messages/[message_id]Outlookアドインがクライアント内のメッセージを見つけることができません

このグラフAPIの呼び出しは私たちのサーバーから行われているため、アドインUIがブラウザまたはOutlookクライアントで実行されている必要はありません。しかし、Outlookクライアントから実行しているときに、私たちのサーバーからのメッセージの要求が404応答を受け取ることがあります。

私は両方の要求のURLとトークンをWebブラウザアドインとOutlookクライアントアドインから取得し、それぞれ手動でテストしました。両方のapi URLが同じで、生成されたトークン(OWAアドインとOutlookクライアントアドインの両方)は、Postmanで手動で試したときに正常に機能しました。

Webベースのアドイン要求が成功している間にOutlookクライアントのアドインからの要求が失敗する理由は何ですか?

答えて

0

stmcallister - 私はあなたの流れを少し理解しています。あなたの質問では、Microsoft Graphへの呼び出しがあなたのサービスから来ていると言います。あなたのアドインがあなたのサービスのアプリケーションIDのOAuthフローを提示していることを前提にして、その代わりにトークンを収集してから、トークンをAPI呼び出しを介してサービスに戻すことは正しいですか? Id、Access、またはRefresh Tokensをサービスに流しますか?

この場合、実行時にアドインがどこにホストされているかは問題ではありません。ただし、元のログインコンテキスト(ブラウザとOffice)に基づいて、トークン(具体的には主張)が多少異なる可能性があります。

いずれの場合も、トークンの問題がある場合、404は不幸な応答です。問題のリクエストに関する詳細を提供できる場合は、それを調べることができます。

おかげで、 -TimMc手伝っため

+0

ありがとう!私たちのアドインは、ユーザーがMicrosoft GraphでOAuthフローを開始するようにします。次に、認証トークンが受信されると、そのトークンを使用して、上記の質問に記載されているグラフエンドポイントにコールを発信します。一部のOutlookクライアントでは、このメッセージを取得する要求は404応答を受信します。ブラウザでは、このフローは一貫して機能します。他の詳細を共有することをうれしく思います。リクエストについて知りたいことがありますか? – stmcallister

+0

ありがとうございます - あなたが受け取る認証トークンは、アクセストークン、Idトークン、またはリフレッシュトークンですか?私はそれがアクセストークンであると推測しています、そして、あなたは後続のRESTコールを.../messages/...とそれを要求ヘッダーのベアラトークンとして作っています。 messageIdはOutlook APIによってアドインに提供されており、両方のクライアントでIDが正しく提供されていることを確認しましたか? –

関連する問題