連携先アプリの認証エラー
認証エラーが起こる例
連携先アプリによっては、トークンをリフレッシュする仕組みがないなどの理由により、アクセストークン等の有効期限が切れると認証がエラーとなります。
それ以外にも、連携先アプリの何らかの仕組みにより認可が取り消される等でアクセストークンが無効化された場合にも認証はエラーとなります。
Anyflowの仕様
基本的に、Anyflowから連携先アプリにリクエストを行った際、
401
( 認証情報が無効 )403
( 権限エラー )
のステータスコードが返却された場合に、Anyflowでは認証が無効になったと判定しアクセストークン等を破棄(リボーク)します。
より詳細には、
リフレッシュ機構をもつアプリの場合:リフレッシュ時のレスポンスが 401 等だった場合にリボーク
リフレッシュ機構をもたないアプリの場合:アクション(レコードの取得等)のレスポンスが 401 等だった場合にリボーク
認証がエラーとなった場合、Anyflowシステムから連携先アプリのAPIを実行できないため、ソリューションは無効となります。
ソリューションを有効にするには、以下の方法に沿ってエンドユーザーが解決を行う必要があります。
認証エラーの検知方法
イベント通知
イベント通知を設定することで、ご利用中のツールに認証エラー発生の情報を通知することができます。

通知される情報
該当のユーザーのインストール一覧へのリンク
アプリ名
無効になったソリューションへのリンク
上記の情報を踏まえて、エンドユーザーに適切な案内を送付してください。
Anyflowからの自動メール
エンドユーザーに再認証を促すメールをAnyflowから自動送信できます。
(メールは [email protected]
から送信されます。)
チームインテグレーションを利用している場合、JWTペイロードの anyflow_team_email
に設定してあるメールアドレスに、ユーザーインテグレーションを利用している場合は anyflow_user_email
にメールが送信されます。
送信されるメールのテンプレートは、ベンダーにて設定することができます。
テンプレートで利用できる変数
エンドユーザーチーム名
{$end_user_team_name$}
Example Inc.
ソリューション名
{$solution_name$}
GoogleDriveにファイルがアップロードされたら請求書サービスに取り込む
認証エラーになったアプリ名
{$app_name$}
GoogleDrive, Salesforce, Slack等
ソリューションID
{$solution_id$}
6dcc67b8-9c8a-4c61-bc7d-f977272573d2
テンプレートの例
件名:
{$solution_name$}で認証エラーが発生しました。
本文:
いつも [サービス名] をご利用いただきありがとうございます。
お使いの「{$solution_name$}」の、「{$app_name$}」で認証エラーが発生しました。
認証の期限が切れた可能性があるため、連携をOFFにしています。
以下のリンクより再度認証いただくことで、連携ソリューションが再稼働します。
[連携を設定する画面のURL]
連携ソリューション: {$solution_name$}
認証エラーになったアプリ: {$app_name$}
-------------------------------------------------
このメールは [サービス名] の連携ソリューションをご利用いただいているお客さまに送信しています。
*このメールアドレスは送信専用のため、返信できませんのでご了承ください。
再認証の方法
認証エラーが発生した場合、エンドユーザーは改めてウィザードから認証を追加することができます。

エンドユーザーが複数のコネクションを作成している場合は、上記の「新しい認証を追加」の表示ではなく、 以下の通り別のコネクションの名前が表示されます。

別のコネクションで改めてウィザードの設定を行うか、別のコネクションでも認証エラーとなる場合は、プルダウンから「新しいコネクションを追加する」を選び、新規のコネクションを追加します。

上記のケースでは、ソリューションの有効状態がdisabled
(ソリューションはインストールされているが、有効にされていない)になっています。
エンドユーザーでのインストールが完了したら、SDKのenableSolution メソッドを使ってソリューションの有効状態をenabled
に変更してください。
再認証ボタンが表示されるケース
以下の様に再認証ボタンが表示される場合は、アクセストークン等の有効期限が切れていることが原因ではなく、許可されたスコープが不足していることが原因です。

例えばSlackを使った2つのソリューションをエンドユーザーに提供していたとします。
ソリューション1:Slackの「読み取り」を行う
ソリューション2:Slackの「読み取り」と「書き込み」を行う
エンドユーザーがソリューション1を利用する際に認証を行った場合、コネクションに付与されるスコープは「読み取り」となります。
その後、エンドユーザーがソリューション2を利用しようとした場合には、「書き込み」のスコープが不足しているため再認証のボタンが表示され、コネクションのスコープを変更することができます。
このケースではソリューションの有効状態は自動的には変更されません。 元々disabledであればdisabledのまま、enabledであればenabledのままとなります。
有効状態の変更は必要に応じてSDKのenableSolution / disableSolution メソッドを使って実施してください。
最終更新