品質保証は、お客様に影響が及ぶ前に問題を特定するうえで重要です。また、プロジェクトの性質によっては、Auth0 との統合の一環として検討すべき品質保証テストがいくつかあります。
- 障害のある方を含め、誰にとってもアプリケーションは理解しやすく、使いやすいものになっていますか？
- アプリケーションは、さまざまなブラウザーやデバイスで動作する必要がありますか？
- アプリケーションは、多国籍および/または国際的な環境で動作する必要がありますか？
- 想定外の本番環境の負荷がかかったとき、アプリケーションのパフォーマンスはどうなりますか？
- アプリケーションをセキュリティ上の脆弱性から保護するには、どのようにすればよいでしょうか？
Auth0 の Universal Login と関連する UI ウィジェット (Lock など) は、すでにユーザビリティとアクセシビリティのベストプラクティスに従って設計・構築されており、多数の ブラウザーやデバイス に対するテスト済みの標準サポートを提供しています。国際化 (I18N) のサポートも標準で提供されており、カスタムの多言語対応やローカリゼーション (L10N) に対応できるよう、組み込みの拡張も備えています。
機能要件が満たされ、想定外の事象にも正しく対応できることを確実にするために、アプリケーションと Auth0 の間の連携テスト、および個々の拡張モジュール (Rules、Hooks、Custom Database スクリプトなど) の単体テストに関するガイダンスが提供されています。さらに、セキュリティ脆弱性のテストを行う際に役立つ Auth0 の侵入テストポリシーに関するガイダンスや、想定外の負荷がかかった場合でもアプリケーションが適切に動作するよう、モック テストを当社の負荷テストポリシーと組み合わせて活用する方法についてのガイダンスも提供されています。
単体テストの目的は、コードの個々の単位を検証することです。Auth0 内で Rules、Hooks、または Custom DB scripts としてカスタムコードを作成する場合は、Mocha などのテストフレームワークを使ってコードをテストすることを検討してください。Auth0 を特に効果的に活用している企業では、Auth0 のテナント設定や関連リソースを自動的にデプロイする前に、これらの単体テストを実行することが有効だとわかっています。
SDLC のサポート のアーキテクチャガイダンスで説明されているように、開発、テスト、本番用にそれぞれ別のテナントを設定することが推奨されています。Auth0 では、カスタムの 拡張 から利用できる変数を設定できます。これは、Auth0 テナントにおける環境変数のようなものです。開発、テスト、本番の各環境間でコードを移動するたびに変わる参照をハードコードするのではなく、テナントで設定し、カスタム 拡張 コードから参照する変数名を使用できます。これにより、実行時にテナント固有の値が設定される変数をコードから参照できるため、同じカスタムコードを変更せずに、異なるテナントでも動作させやすくなります。
- Rules で変数を使用する場合は、値を設定する方法 を参照してください
- Hooks で変数を使用する場合は、エディターで secrets を設定する方法を参照してください
- Actions で変数を使用する場合は、Explore Flows and Triggers を参照してください
- Custom DB Scripts で変数を使用する場合は、構成パラメーター を参照してください
テナント固有の値や、カスタムコード内で公開すべきでない機密の secrets を保持するために、変数を使用することをお勧めします。カスタムコードを GitHub にデプロイしている場合は、テナント固有の変数を使用することで、GitHub リポジトリを通じた機密値の漏えいを防げます。
