v3(GA)
Post-login
最高のユーザーエクスペリエンスを実現するために、post-login(ログイン後)フローを最新のGAバージョン(v3)にアップグレードすることを強くお勧めします。
破壊的変更(Breaking Change)
api.redirect.canRedirect()
は廃止としてマークされました。api.redirect.sendUserTo()
は、非対話型フローでリダイレクトをスキップしなくなりました。つまり、api.redirect.sendUserTo()
への呼び出しでは、リダイレクトを発行する前に、リダイレクトが必要かどうかを確認する必要があります。event.authentication.methods
のような情報を参照すると、リダイレクトが正常に完了し、api.authentication.recordMethod()
を通じて記録されたかどうかを確認できます。非対話型フローでリダイレクトのトリガーを試みると、interaction_required
エラーが正しくトリガーされます。
新機能
-
event.authentication.methods
に、そのセッション内でユーザーによって完了され、onContinuePostLogin
ハンドラーのapi.authentication.recordMethod()
を使用して記録されたカスタムメソッドも含めることができるようになりました。 -
ユーザーのセッションでカスタムメソッドの完了レコードを保存する方法として、
api.authentication.recordMethod()
が追加されました。これらのAPIを使用すると、特定のシナリオでカスタム要素を厳密に要求できるようになります。(特定の端末の)ユーザーには、対話型ログインが発生したかどうかにかかわらず、カスタム要素の完了が求められます。 カスタム要素の必須化の条件を満たし、ユーザーのセッションに完了のレコードがない場合には、フローが対話型かどうかは要素が必須かどうかに影響しません。 たとえば、必須のカスタム要素を実装する場合は、以下のようにセットアップできます。onExecutePostLogin
で、 カスタムメソッドの識別子URLのあるevent.authentication.methods
配列のレコードを検索します。このメソッドが存在し、充分に新しいタイムスタンプがある場合は、ログインを続行できます。そうでない場合は、api.redirect.sendUserTo()
を使用して、カスタム要素を実装するURLへのリダイレクトをトリガーします。カスタムデータはapi.redirect.encodeToken()
を使用してJWTにエンコードし、署名することができます。- ユーザーが
/continue
にリダイレクトされる際には、onContinuePostLogin
ハンドラーが呼び出されます。このハンドラー内で、カスタム要素から返されるすべてのデータを検証し(必要な場合)、api.authentication.recordMethod()
を呼び出して完了を知らせます。
v2(GA)
Post-login
破壊的変更(Breaking Change)
副作用の実行
ログイン後トリガーのGA前のバージョンでは、副作用は、Actionからオブジェクトを返すことで実行されました。Actions GAでは、これらの変更をカプセル化し、より良いエディター内ヒントおよびインラインドキュメントを提供するために、api
オブジェクトが用意されています。
ユーザーのuser_metadataの更新
GA前のトリガー:
このメソッドを実行してもすぐにはメタデータが更新されないため、コールバックでこのメソッドを使用しないでください。代わりに、同じフローに含まれる複数のアクションでこのメソッドを複数回呼び出します(1つのアクションで設定されたメタデータが一時オブジェクトに適用され、後続のアクションで使用できるようになります)。エンジンによって変更が集約され、フローの完了前にすべてのメタデータが一度に更新されます。
このメソッドを実行してもすぐにはメタデータが更新されないため、コールバックでこのメソッドを使用しないでください。代わりに、同じフローに含まれる複数のアクションでこのメソッドを複数回呼び出します(1つのアクションで設定されたメタデータが一時オブジェクトに適用され、後続のアクションで使用できるようになります)。エンジンによって変更が集約され、フローの完了前にすべてのメタデータが一度に更新されます。
エラーをスローしてログインを拒否することもできますが、方法としては
api.access.deny
の呼び出しをお勧めします。