機械翻訳について
  1. Oracle Linux Automation Manager CLIおよびAPIリファレンス・ガイド 2.1
  2. タスク
  3. 設定

ロギング構成のテスト

post

/api/v2/settings/logging/test/

リクエスト

サポートされているメディア・タイプ
本文()
ルート・スキーマ : schema
型: object
ソースを表示
  • アクティビティ・ストリームのアクティビティを取得できるようにします。
  • インベントリ同期化の実行時にアクティビティ・ストリームのアクティビティを取得できるようにします。
  • AD_HOC_COMMANDS
    アドホック・ジョブで使用できるモジュールのリスト。
  • Ansibleによって、--extra-varsについてJinja2テンプレート言語による変数の置換が許可されます。 これにより、ジョブの起動時に追加変数を指定できるユーザーがJinja2テンプレートを使用して任意のPythonを実行できるという潜在的なセキュリティ・リスクが発生します。 この値は"template"または"never"に設定することをお薦めします。
  • セキュリティ上の理由から、外部認証プロバイダ(LDAP、SAML、SSO、Radiusなど)のユーザーはOAuth2トークンを作成できません。 この動作を変更するには、この設定を有効にします。 この設定をオフに切り替えても、既存のトークンは削除されません。
  • 格納されたAnsibleファクトが、最後に変更されたときから最大何秒有効であるとみなすか。 プレイブックからは、古くなっていない有効なファクトにのみアクセスできます。 これは、データベースからのansible_factsの削除には影響しません。 タイムアウトが適用されないように指定するには、値0を使用します。
  • API 4XXエラーが発生した場合のログ・メッセージの書式。次の変数が置換されます: status_code - エラーuser_nameのHTTPステータス・コード - API url_pathを使用しようとしているユーザー名 - remote_addrというAPIエンドポイントへのURLパス - ユーザー・エラーに対して表示されるリモート・アドレス - apiエンドポイント変数で設定されるエラーは、 {}}の形式である必要があります。
  • APIブラウザについてHTTP Basic認証を有効にします。
  • すべての検索問合せについてバインドするユーザーのDN (識別名)。 これは、ログインして他のユーザー情報をLDAPに問い合せるために使用されるシステム・ユーザー・アカウントです。 構文の例は、ドキュメントを参照してください。
  • LDAPユーザー・アカウントをバインドするために使用されるパスワード。
  • AUTH_LDAP_1_CONNECTION_OPTIONS
    LDAP接続について設定する追加オプション。 LDAP参照はデフォルトで無効になっています(特定のLDAP問合せがADでハングしないようにするため)。 オプション名は文字列である必要があります(例: "OPT_REFERRALS")。 設定可能なオプションと値は、https://www.python-ldap.org/doc/html/ldap.html#optionsを参照してください。
  • ログインから拒否されるグループDN。 指定した場合、このグループのメンバーであるユーザーはログインを許可されません。 1つの拒否グループのみがサポートされています。
  • AUTH_LDAP_1_GROUP_SEARCH
    ユーザーは、LDAPグループのメンバーシップに基づいて組織にマップされます。 この設定では、グループを検索するためのLDAP検索問合せを定義します。 ユーザー検索とは異なり、グループ検索ではLDAPSearchUnionはサポートされていません。
  • LDAPサーバーのタイプに基づいて、グループ・タイプを変更する必要がある場合があります。 値は、https://django-auth-ldap.readthedocs.io/en/stable/groups.html#types-of-groupsにリストされています
  • AUTH_LDAP_1_GROUP_TYPE_PARAMS
    選択したグループ・タイプのinitメソッドを送信するためのキー値パラメータ。
  • AUTH_LDAP_1_ORGANIZATION_MAP
    組織の管理者/ユーザーとLDAPグループの間のマッピング。 これにより、LDAPグループのメンバーシップを基準にして、組織に配置するユーザーが制御されます。 構成の詳細は、ドキュメントを参照してください。
  • ログインするために必要なグループDN。 指定した場合、ユーザーがLDAPを介してログインするには、このグループのメンバーである必要があります。 設定しない場合、ユーザー検索と一致するLDAPのすべてのユーザーがサービスにログインできるようになります。 1つの必須グループのみがサポートされています。
  • "ldap://ldap.example.com:389" (非SSL)や"ldaps://ldap.example.com:636" (SSL)など、LDAPサーバーに接続するためのURI。 複数のLDAPサーバーを指定するには、スペースまたはカンマで区切ります。 このパラメータが空の場合、LDAP認証は無効です。
  • LDAP接続がSSLを使用していない場合にTLSを有効にするかどうか。
  • AUTH_LDAP_1_TEAM_MAP
    チーム・メンバー(ユーザー)とLDAPグループの間のマッピング。 構成の詳細は、ドキュメントを参照してください。
  • AUTH_LDAP_1_USER_ATTR_MAP
    LDAPユーザー・スキーマとAPIユーザー属性のマッピング。 デフォルト設定はActiveDirectoryについては有効ですが、他のLDAP構成を持つユーザーは値を変更する必要がある場合があります。 詳細は、ドキュメントを参照してください。
  • ユーザーDNがすべて同じ形式である場合のユーザー検索の代替手段。 組織の環境で使用可能な場合、ユーザー・ルックアップには検索よりもこのアプローチのほうが効率的です。 この設定に値がある場合は、AUTH_LDAP_USER_SEARCHのかわりに使用されます。
  • AUTH_LDAP_1_USER_FLAGS_BY_GROUP
    指定されたグループからユーザーを取得します。 現時点では、サポートされているグループはスーパーユーザーとシステム監査者のみです。 詳細は、ドキュメントを参照してください。
  • AUTH_LDAP_1_USER_SEARCH
    ユーザーを検索するためのLDAP検索問合せ。 指定されたパターンと一致するユーザーがサービスにログインできます。 また、ユーザーは、(AUTH_LDAP_ORGANIZATION_MAP設定で定義された)組織にマップされている必要があります。 複数の検索問合せをサポートする必要がある場合は、"LDAPUnion"を使用できます。 詳細は、ドキュメントを参照してください。
  • すべての検索問合せについてバインドするユーザーのDN (識別名)。 これは、ログインして他のユーザー情報をLDAPに問い合せるために使用されるシステム・ユーザー・アカウントです。 構文の例は、ドキュメントを参照してください。
  • LDAPユーザー・アカウントをバインドするために使用されるパスワード。
  • AUTH_LDAP_2_CONNECTION_OPTIONS
    LDAP接続について設定する追加オプション。 LDAP参照はデフォルトで無効になっています(特定のLDAP問合せがADでハングしないようにするため)。 オプション名は文字列である必要があります(例: "OPT_REFERRALS")。 設定可能なオプションと値は、https://www.python-ldap.org/doc/html/ldap.html#optionsを参照してください。
  • ログインから拒否されるグループDN。 指定した場合、このグループのメンバーであるユーザーはログインを許可されません。 1つの拒否グループのみがサポートされています。
  • AUTH_LDAP_2_GROUP_SEARCH
    ユーザーは、LDAPグループのメンバーシップに基づいて組織にマップされます。 この設定では、グループを検索するためのLDAP検索問合せを定義します。 ユーザー検索とは異なり、グループ検索ではLDAPSearchUnionはサポートされていません。
  • LDAPサーバーのタイプに基づいて、グループ・タイプを変更する必要がある場合があります。 値は、https://django-auth-ldap.readthedocs.io/en/stable/groups.html#types-of-groupsにリストされています
  • AUTH_LDAP_2_GROUP_TYPE_PARAMS
    選択したグループ・タイプのinitメソッドを送信するためのキー値パラメータ。
  • AUTH_LDAP_2_ORGANIZATION_MAP
    組織の管理者/ユーザーとLDAPグループの間のマッピング。 これにより、LDAPグループのメンバーシップを基準にして、組織に配置するユーザーが制御されます。 構成の詳細は、ドキュメントを参照してください。
  • ログインするために必要なグループDN。 指定した場合、ユーザーがLDAPを介してログインするには、このグループのメンバーである必要があります。 設定しない場合、ユーザー検索と一致するLDAPのすべてのユーザーがサービスにログインできるようになります。 1つの必須グループのみがサポートされています。
  • "ldap://ldap.example.com:389" (非SSL)や"ldaps://ldap.example.com:636" (SSL)など、LDAPサーバーに接続するためのURI。 複数のLDAPサーバーを指定するには、スペースまたはカンマで区切ります。 このパラメータが空の場合、LDAP認証は無効です。
  • LDAP接続がSSLを使用していない場合にTLSを有効にするかどうか。
  • AUTH_LDAP_2_TEAM_MAP
    チーム・メンバー(ユーザー)とLDAPグループの間のマッピング。 構成の詳細は、ドキュメントを参照してください。
  • AUTH_LDAP_2_USER_ATTR_MAP
    LDAPユーザー・スキーマとAPIユーザー属性のマッピング。 デフォルト設定はActiveDirectoryについては有効ですが、他のLDAP構成を持つユーザーは値を変更する必要がある場合があります。 詳細は、ドキュメントを参照してください。
  • ユーザーDNがすべて同じ形式である場合のユーザー検索の代替手段。 組織の環境で使用可能な場合、ユーザー・ルックアップには検索よりもこのアプローチのほうが効率的です。 この設定に値がある場合は、AUTH_LDAP_USER_SEARCHのかわりに使用されます。
  • AUTH_LDAP_2_USER_FLAGS_BY_GROUP
    指定されたグループからユーザーを取得します。 現時点では、サポートされているグループはスーパーユーザーとシステム監査者のみです。 詳細は、ドキュメントを参照してください。
  • AUTH_LDAP_2_USER_SEARCH
    ユーザーを検索するためのLDAP検索問合せ。 指定されたパターンと一致するユーザーがサービスにログインできます。 また、ユーザーは、(AUTH_LDAP_ORGANIZATION_MAP設定で定義された)組織にマップされている必要があります。 複数の検索問合せをサポートする必要がある場合は、"LDAPUnion"を使用できます。 詳細は、ドキュメントを参照してください。
  • すべての検索問合せについてバインドするユーザーのDN (識別名)。 これは、ログインして他のユーザー情報をLDAPに問い合せるために使用されるシステム・ユーザー・アカウントです。 構文の例は、ドキュメントを参照してください。
  • LDAPユーザー・アカウントをバインドするために使用されるパスワード。
  • AUTH_LDAP_3_CONNECTION_OPTIONS
    LDAP接続について設定する追加オプション。 LDAP参照はデフォルトで無効になっています(特定のLDAP問合せがADでハングしないようにするため)。 オプション名は文字列である必要があります(例: "OPT_REFERRALS")。 設定可能なオプションと値は、https://www.python-ldap.org/doc/html/ldap.html#optionsを参照してください。
  • ログインから拒否されるグループDN。 指定した場合、このグループのメンバーであるユーザーはログインを許可されません。 1つの拒否グループのみがサポートされています。
  • AUTH_LDAP_3_GROUP_SEARCH
    ユーザーは、LDAPグループのメンバーシップに基づいて組織にマップされます。 この設定では、グループを検索するためのLDAP検索問合せを定義します。 ユーザー検索とは異なり、グループ検索ではLDAPSearchUnionはサポートされていません。
  • LDAPサーバーのタイプに基づいて、グループ・タイプを変更する必要がある場合があります。 値は、https://django-auth-ldap.readthedocs.io/en/stable/groups.html#types-of-groupsにリストされています
  • AUTH_LDAP_3_GROUP_TYPE_PARAMS
    選択したグループ・タイプのinitメソッドを送信するためのキー値パラメータ。
  • AUTH_LDAP_3_ORGANIZATION_MAP
    組織の管理者/ユーザーとLDAPグループの間のマッピング。 これにより、LDAPグループのメンバーシップを基準にして、組織に配置するユーザーが制御されます。 構成の詳細は、ドキュメントを参照してください。
  • ログインするために必要なグループDN。 指定した場合、ユーザーがLDAPを介してログインするには、このグループのメンバーである必要があります。 設定しない場合、ユーザー検索と一致するLDAPのすべてのユーザーがサービスにログインできるようになります。 1つの必須グループのみがサポートされています。
  • "ldap://ldap.example.com:389" (非SSL)や"ldaps://ldap.example.com:636" (SSL)など、LDAPサーバーに接続するためのURI。 複数のLDAPサーバーを指定するには、スペースまたはカンマで区切ります。 このパラメータが空の場合、LDAP認証は無効です。
  • LDAP接続がSSLを使用していない場合にTLSを有効にするかどうか。
  • AUTH_LDAP_3_TEAM_MAP
    チーム・メンバー(ユーザー)とLDAPグループの間のマッピング。 構成の詳細は、ドキュメントを参照してください。
  • AUTH_LDAP_3_USER_ATTR_MAP
    LDAPユーザー・スキーマとAPIユーザー属性のマッピング。 デフォルト設定はActiveDirectoryについては有効ですが、他のLDAP構成を持つユーザーは値を変更する必要がある場合があります。 詳細は、ドキュメントを参照してください。
  • ユーザーDNがすべて同じ形式である場合のユーザー検索の代替手段。 組織の環境で使用可能な場合、ユーザー・ルックアップには検索よりもこのアプローチのほうが効率的です。 この設定に値がある場合は、AUTH_LDAP_USER_SEARCHのかわりに使用されます。
  • AUTH_LDAP_3_USER_FLAGS_BY_GROUP
    指定されたグループからユーザーを取得します。 現時点では、サポートされているグループはスーパーユーザーとシステム監査者のみです。 詳細は、ドキュメントを参照してください。
  • AUTH_LDAP_3_USER_SEARCH
    ユーザーを検索するためのLDAP検索問合せ。 指定されたパターンと一致するユーザーがサービスにログインできます。 また、ユーザーは、(AUTH_LDAP_ORGANIZATION_MAP設定で定義された)組織にマップされている必要があります。 複数の検索問合せをサポートする必要がある場合は、"LDAPUnion"を使用できます。 詳細は、ドキュメントを参照してください。
  • すべての検索問合せについてバインドするユーザーのDN (識別名)。 これは、ログインして他のユーザー情報をLDAPに問い合せるために使用されるシステム・ユーザー・アカウントです。 構文の例は、ドキュメントを参照してください。
  • LDAPユーザー・アカウントをバインドするために使用されるパスワード。
  • AUTH_LDAP_4_CONNECTION_OPTIONS
    LDAP接続について設定する追加オプション。 LDAP参照はデフォルトで無効になっています(特定のLDAP問合せがADでハングしないようにするため)。 オプション名は文字列である必要があります(例: "OPT_REFERRALS")。 設定可能なオプションと値は、https://www.python-ldap.org/doc/html/ldap.html#optionsを参照してください。
  • ログインから拒否されるグループDN。 指定した場合、このグループのメンバーであるユーザーはログインを許可されません。 1つの拒否グループのみがサポートされています。
  • AUTH_LDAP_4_GROUP_SEARCH
    ユーザーは、LDAPグループのメンバーシップに基づいて組織にマップされます。 この設定では、グループを検索するためのLDAP検索問合せを定義します。 ユーザー検索とは異なり、グループ検索ではLDAPSearchUnionはサポートされていません。
  • LDAPサーバーのタイプに基づいて、グループ・タイプを変更する必要がある場合があります。 値は、https://django-auth-ldap.readthedocs.io/en/stable/groups.html#types-of-groupsにリストされています
  • AUTH_LDAP_4_GROUP_TYPE_PARAMS
    選択したグループ・タイプのinitメソッドを送信するためのキー値パラメータ。
  • AUTH_LDAP_4_ORGANIZATION_MAP
    組織の管理者/ユーザーとLDAPグループの間のマッピング。 これにより、LDAPグループのメンバーシップを基準にして、組織に配置するユーザーが制御されます。 構成の詳細は、ドキュメントを参照してください。
  • ログインするために必要なグループDN。 指定した場合、ユーザーがLDAPを介してログインするには、このグループのメンバーである必要があります。 設定しない場合、ユーザー検索と一致するLDAPのすべてのユーザーがサービスにログインできるようになります。 1つの必須グループのみがサポートされています。
  • "ldap://ldap.example.com:389" (非SSL)や"ldaps://ldap.example.com:636" (SSL)など、LDAPサーバーに接続するためのURI。 複数のLDAPサーバーを指定するには、スペースまたはカンマで区切ります。 このパラメータが空の場合、LDAP認証は無効です。
  • LDAP接続がSSLを使用していない場合にTLSを有効にするかどうか。
  • AUTH_LDAP_4_TEAM_MAP
    チーム・メンバー(ユーザー)とLDAPグループの間のマッピング。 構成の詳細は、ドキュメントを参照してください。
  • AUTH_LDAP_4_USER_ATTR_MAP
    LDAPユーザー・スキーマとAPIユーザー属性のマッピング。 デフォルト設定はActiveDirectoryについては有効ですが、他のLDAP構成を持つユーザーは値を変更する必要がある場合があります。 詳細は、ドキュメントを参照してください。
  • ユーザーDNがすべて同じ形式である場合のユーザー検索の代替手段。 組織の環境で使用可能な場合、ユーザー・ルックアップには検索よりもこのアプローチのほうが効率的です。 この設定に値がある場合は、AUTH_LDAP_USER_SEARCHのかわりに使用されます。
  • AUTH_LDAP_4_USER_FLAGS_BY_GROUP
    指定されたグループからユーザーを取得します。 現時点では、サポートされているグループはスーパーユーザーとシステム監査者のみです。 詳細は、ドキュメントを参照してください。
  • AUTH_LDAP_4_USER_SEARCH
    ユーザーを検索するためのLDAP検索問合せ。 指定されたパターンと一致するユーザーがサービスにログインできます。 また、ユーザーは、(AUTH_LDAP_ORGANIZATION_MAP設定で定義された)組織にマップされている必要があります。 複数の検索問合せをサポートする必要がある場合は、"LDAPUnion"を使用できます。 詳細は、ドキュメントを参照してください。
  • すべての検索問合せについてバインドするユーザーのDN (識別名)。 これは、ログインして他のユーザー情報をLDAPに問い合せるために使用されるシステム・ユーザー・アカウントです。 構文の例は、ドキュメントを参照してください。
  • LDAPユーザー・アカウントをバインドするために使用されるパスワード。
  • AUTH_LDAP_5_CONNECTION_OPTIONS
    LDAP接続について設定する追加オプション。 LDAP参照はデフォルトで無効になっています(特定のLDAP問合せがADでハングしないようにするため)。 オプション名は文字列である必要があります(例: "OPT_REFERRALS")。 設定可能なオプションと値は、https://www.python-ldap.org/doc/html/ldap.html#optionsを参照してください。
  • ログインから拒否されるグループDN。 指定した場合、このグループのメンバーであるユーザーはログインを許可されません。 1つの拒否グループのみがサポートされています。
  • AUTH_LDAP_5_GROUP_SEARCH
    ユーザーは、LDAPグループのメンバーシップに基づいて組織にマップされます。 この設定では、グループを検索するためのLDAP検索問合せを定義します。 ユーザー検索とは異なり、グループ検索ではLDAPSearchUnionはサポートされていません。
  • LDAPサーバーのタイプに基づいて、グループ・タイプを変更する必要がある場合があります。 値は、https://django-auth-ldap.readthedocs.io/en/stable/groups.html#types-of-groupsにリストされています
  • AUTH_LDAP_5_GROUP_TYPE_PARAMS
    選択したグループ・タイプのinitメソッドを送信するためのキー値パラメータ。
  • AUTH_LDAP_5_ORGANIZATION_MAP
    組織の管理者/ユーザーとLDAPグループの間のマッピング。 これにより、LDAPグループのメンバーシップを基準にして、組織に配置するユーザーが制御されます。 構成の詳細は、ドキュメントを参照してください。
  • ログインするために必要なグループDN。 指定した場合、ユーザーがLDAPを介してログインするには、このグループのメンバーである必要があります。 設定しない場合、ユーザー検索と一致するLDAPのすべてのユーザーがサービスにログインできるようになります。 1つの必須グループのみがサポートされています。
  • "ldap://ldap.example.com:389" (非SSL)や"ldaps://ldap.example.com:636" (SSL)など、LDAPサーバーに接続するためのURI。 複数のLDAPサーバーを指定するには、スペースまたはカンマで区切ります。 このパラメータが空の場合、LDAP認証は無効です。
  • LDAP接続がSSLを使用していない場合にTLSを有効にするかどうか。
  • AUTH_LDAP_5_TEAM_MAP
    チーム・メンバー(ユーザー)とLDAPグループの間のマッピング。 構成の詳細は、ドキュメントを参照してください。
  • AUTH_LDAP_5_USER_ATTR_MAP
    LDAPユーザー・スキーマとAPIユーザー属性のマッピング。 デフォルト設定はActiveDirectoryについては有効ですが、他のLDAP構成を持つユーザーは値を変更する必要がある場合があります。 詳細は、ドキュメントを参照してください。
  • ユーザーDNがすべて同じ形式である場合のユーザー検索の代替手段。 組織の環境で使用可能な場合、ユーザー・ルックアップには検索よりもこのアプローチのほうが効率的です。 この設定に値がある場合は、AUTH_LDAP_USER_SEARCHのかわりに使用されます。
  • AUTH_LDAP_5_USER_FLAGS_BY_GROUP
    指定されたグループからユーザーを取得します。 現時点では、サポートされているグループはスーパーユーザーとシステム監査者のみです。 詳細は、ドキュメントを参照してください。
  • AUTH_LDAP_5_USER_SEARCH
    ユーザーを検索するためのLDAP検索問合せ。 指定されたパターンと一致するユーザーがサービスにログインできます。 また、ユーザーは、(AUTH_LDAP_ORGANIZATION_MAP設定で定義された)組織にマップされている必要があります。 複数の検索問合せをサポートする必要がある場合は、"LDAPUnion"を使用できます。 詳細は、ドキュメントを参照してください。
  • すべての検索問合せについてバインドするユーザーのDN (識別名)。 これは、ログインして他のユーザー情報をLDAPに問い合せるために使用されるシステム・ユーザー・アカウントです。 構文の例は、ドキュメントを参照してください。
  • LDAPユーザー・アカウントをバインドするために使用されるパスワード。
  • AUTH_LDAP_CONNECTION_OPTIONS
    LDAP接続について設定する追加オプション。 LDAP参照はデフォルトで無効になっています(特定のLDAP問合せがADでハングしないようにするため)。 オプション名は文字列である必要があります(例: "OPT_REFERRALS")。 設定可能なオプションと値は、https://www.python-ldap.org/doc/html/ldap.html#optionsを参照してください。
  • ログインから拒否されるグループDN。 指定した場合、このグループのメンバーであるユーザーはログインを許可されません。 1つの拒否グループのみがサポートされています。
  • AUTH_LDAP_GROUP_SEARCH
    ユーザーは、LDAPグループのメンバーシップに基づいて組織にマップされます。 この設定では、グループを検索するためのLDAP検索問合せを定義します。 ユーザー検索とは異なり、グループ検索ではLDAPSearchUnionはサポートされていません。
  • LDAPサーバーのタイプに基づいて、グループ・タイプを変更する必要がある場合があります。 値は、https://django-auth-ldap.readthedocs.io/en/stable/groups.html#types-of-groupsにリストされています
  • AUTH_LDAP_GROUP_TYPE_PARAMS
    選択したグループ・タイプのinitメソッドを送信するためのキー値パラメータ。
  • AUTH_LDAP_ORGANIZATION_MAP
    組織の管理者/ユーザーとLDAPグループの間のマッピング。 これにより、LDAPグループのメンバーシップを基準にして、組織に配置するユーザーが制御されます。 構成の詳細は、ドキュメントを参照してください。
  • ログインするために必要なグループDN。 指定した場合、ユーザーがLDAPを介してログインするには、このグループのメンバーである必要があります。 設定しない場合、ユーザー検索と一致するLDAPのすべてのユーザーがサービスにログインできるようになります。 1つの必須グループのみがサポートされています。
  • "ldap://ldap.example.com:389" (非SSL)や"ldaps://ldap.example.com:636" (SSL)など、LDAPサーバーに接続するためのURI。 複数のLDAPサーバーを指定するには、スペースまたはカンマで区切ります。 このパラメータが空の場合、LDAP認証は無効です。
  • LDAP接続がSSLを使用していない場合にTLSを有効にするかどうか。
  • AUTH_LDAP_TEAM_MAP
    チーム・メンバー(ユーザー)とLDAPグループの間のマッピング。 構成の詳細は、ドキュメントを参照してください。
  • AUTH_LDAP_USER_ATTR_MAP
    LDAPユーザー・スキーマとAPIユーザー属性のマッピング。 デフォルト設定はActiveDirectoryについては有効ですが、他のLDAP構成を持つユーザーは値を変更する必要がある場合があります。 詳細は、ドキュメントを参照してください。
  • ユーザーDNがすべて同じ形式である場合のユーザー検索の代替手段。 組織の環境で使用可能な場合、ユーザー・ルックアップには検索よりもこのアプローチのほうが効率的です。 この設定に値がある場合は、AUTH_LDAP_USER_SEARCHのかわりに使用されます。
  • AUTH_LDAP_USER_FLAGS_BY_GROUP
    指定されたグループからユーザーを取得します。 現時点では、サポートされているグループはスーパーユーザーとシステム監査者のみです。 詳細は、ドキュメントを参照してください。
  • AUTH_LDAP_USER_SEARCH
    ユーザーを検索するためのLDAP検索問合せ。 指定されたパターンと一致するユーザーがサービスにログインできます。 また、ユーザーは、(AUTH_LDAP_ORGANIZATION_MAP設定で定義された)組織にマップされている必要があります。 複数の検索問合せをサポートする必要がある場合は、"LDAPUnion"を使用できます。 詳細は、ドキュメントを参照してください。
  • データ収集間の間隔(秒)。
  • この設定は、Red Hat Insightsのデータ収集のアップロードURLを構成するために使用されます。
  • AWX_ANSIBLE_CALLBACK_PLUGINS
    ジョブの実行時に使用される追加のコールバック・プラグインを検索するパスのリスト。 1行にパスを1つずつ入力します。
  • SCMプロジェクトについてrequirements.ymlファイルからコレクションを動的にダウンロードすることを許可します。
  • サービスがジョブの実行および分離のために新しい一時ディレクトリを作成するディレクトリ(資格証明ファイルなど)。
  • AWX_ISOLATION_SHOW_PATHS
    本来なら非表示にするパスのうち、分離されたジョブに公開するパスのリスト。 1行にパスを1つずつ入力します。
  • SCMプロジェクトについてrequirements.ymlファイルからロールを動的にダウンロードすることを許可します。
  • プレイブックをスキャンするときにシンボリック・リンクに従います。 リンクがそれ自体の親ディレクトリを指す場合、これをTrueに設定すると、無限再帰が発生する可能性があります。
  • AWX_TASK_ENV
    プレイブックの実行、インベントリの更新、プロジェクトの更新および通知の送信について設定された追加の環境変数。
  • 必要に応じて、この設定を使用してログイン・モーダルのテキスト・ボックスに特定の情報(法律上の注意点や免責条項など)を追加できます。 追加する内容はプレーン・テキストまたはHTMLフラグメントである必要があります。他のマークアップ言語はサポートされていません。
  • カスタム・ロゴを設定するには、作成したファイルを指定します。 カスタム・ロゴを最も効果的に表示するには、背景が透明な.pngファイルを使用します。 GIF、PNGおよびJPEG形式がサポートされています。
  • CUSTOM_VENV_PATHS
    Towerが(/var/lib/awx/venv/に加えて)カスタム仮想環境を検索するパス。 1行にパスを1つずつ入力します。
  • ジョブ・テンプレート用に構成されていない場合に使用される実行環境。
  • インベントリの更新の実行を許可する最大時間(秒)。 タイムアウトが適用されないように指定するには、値0を使用します。 個々のインベントリ・ソースで設定されたタイムアウトは、これよりも優先されます。
  • この秒数でansibleからの出力が検出されない場合、実行は終了します。 デフォルトidle_timeoutを使用する場合は値0を600にします。
  • ジョブの実行を許可する最大時間(秒)。 タイムアウトが適用されないように指定するには、値0を使用します。 個々のジョブ・テンプレートで設定されたタイムアウトは、これよりも優先されます。
  • プロジェクトの更新の実行を許可する最大時間(秒)。 タイムアウトが適用されないように指定するには、値0を使用します。 個々のプロジェクトで設定されたタイムアウトは、これよりも優先されます。
  • ユーザーが組込み認証システムを使用できないようにするかどうかを制御します。 LDAPまたはSAML統合を使用する場合は、これを実行することをお薦めします。
  • 単一のジョブまたはアド・ホック・コマンド・イベントについて標準出力が表示される最大サイズ(バイト)。stdoutが切り捨てられたときには、???で終わります。
  • trueに設定した場合、Galaxyサーバーからコンテンツをインストールするときに証明書の検証が行われません。
  • サービスが自動化に関するデータを収集してRed Hat Insightsに送信できるようにします。
  • ログを外部ログ・アグリゲータに送信できるようにします。
  • 外部ログの送信先となるホスト名/IP。
  • 設定した場合、スキャンで見つかったそれぞれのパッケージ、サービスまたは他の項目についてシステム・トラッキング・ファクトが送信されるため、検索問合せの粒度が向上します。 設定しない場合、ファクトは単一の辞書として送信されるため、ファクト処理の効率が向上します。
  • ログ・ハンドラで使用されるレベルしきい値。 重大度は、最も低いものから最も高いものへ順にDEBUG、INFO、WARNING、ERROR、CRITICALとなります。 重大度がしきい値より低いメッセージは、ログ・ハンドラによって無視されます。(カテゴリawx.anlyticsのメッセージでは、この設定は無視されます)
  • LOG_AGGREGATOR_LOGGERS
    HTTPログをコレクタに送信するロガーのリスト。これには、awx - サービス・ログ、activity_stream - アクティビティ・ストリーム・レコード、job_events - Ansibleジョブ・イベントからのコールバック・データ、system_tracking - スキャン・ジョブから収集されたファクトのいずれかまたはすべてを含めることができます。
  • 外部ログ・アグリゲータの停止中に格納するデータの量(GB) (デフォルトは1)。 rsyslogdのqueue.maxdiskspace設定に相当します。
  • 外部ログ・アグリゲータの停止後に再試行する必要があるログを保持する場所(デフォルトは/var/lib/awx)。 rsyslogdのqueue.spoolDirectory設定に相当します。
  • 外部ログ・アグリゲータのパスワードまたは認証トークン(必要な場合。HTTP/sのみ)。
  • ログの送信先となるロギング・アグリゲータのポート(ロギング・アグリゲータで必要で、かつ指定されていない場合)。
  • ログ・アグリゲータとの通信に使用されるプロトコル。 ロギング・アグリゲータのホスト名でhttp://が明示的に使用されていないかぎり、HTTPS/HTTPはHTTPSとみなされます。
  • rsyslogdの高冗長度デバッグを有効にします。 外部ログ集計に関する接続の問題をデバッグするのに便利です。
  • 外部ログ・アグリゲータへのTCP接続がタイムアウトするまでの秒数。 HTTPSおよびTCPログ・アグリゲータ・プロトコルに適用されます。
  • インスタンスを一意に識別するのに便利です。
  • 選択したログ・アグリゲータのメッセージの形式を設定します。
  • 外部ログ・アグリゲータのユーザー名(必要な場合。HTTP/sのみ)。
  • LOG_AGGREGATOR_PROTOCOLが"https"である場合に証明書検証の有効化/無効化を制御するフラグ。 有効にすると、ログ・ハンドラは、接続を確立する前に外部ログ・アグリゲータによって送信された証明書を検証します。
  • 認可されていないユーザーがログインするようにリダイレクトされるURL。 空白の場合、ユーザーはログイン・ページに送られます。
  • ユーザーとチームを作成および管理する権限を組織管理者が持つかどうかを制御します。 LDAPまたはSAML統合を使用する場合は、この機能を無効にすることをお薦めします。
  • 分岐がこの数より多いジョブ・テンプレートを保存すると、エラーが発生します。 0に設定すると、制限は適用されません。
  • UIが1つのリクエスト内で取得するジョブ・イベントの最大数。
  • 1秒当たりのUIライブ・ジョブ出力を更新するメッセージの最大数。 値0は制限がないことを示します。
  • OAUTH2_PROVIDER
    OAuth 2のタイムアウトをカスタマイズするための辞書。使用可能な項目はACCESS_TOKEN_EXPIRE_SECONDS (アクセス・トークンの期間(秒数))、AUTHORIZATION_CODE_EXPIRE_SECONDS (認可コードの期間(秒数))およびREFRESH_TOKEN_EXPIRE_SECONDS (期限切れアクセス・トークンの後のリフレッシュ・トークンの期間(秒数))です。
  • 組織管理者がすべてのユーザーとチーム(自分の組織に関連付けられていないものも含む)を表示できるかどうかを制御します。
  • プロジェクトの更新に使用されるproject_update.ymlのansible-playbook実行にCLI -vvvフラグを追加します。
  • PROXY_IP_ALLOWED_LIST
    サービスがリバース・プロキシ/ロード・バランサの背後にある場合は、この設定を使用して、サービスがカスタムのREMOTE_HOST_HEADERSヘッダー値を信頼するプロキシIPアドレスを構成します。 この設定が空のリスト(デフォルト)である場合は、REMOTE_HOST_HEADERSで指定されたヘッダーが無条件に信頼されます
  • RADIUSサーバーのポート。
  • RADIUSサーバーに対して認証するための共有シークレット。
  • RADIUSサーバーのホスト名/IP。 この設定が空の場合、RADIUS認証は無効です。
  • このパスワードは、Ansible自動化プラットフォームのデータをインサイトに送信するために使用されます
  • このユーザー名は、Ansible自動化プラットフォームのデータをインサイトに送信するために使用されます
  • REMOTE_HOST_HEADERS
    リモート・ホスト名またはIPを特定するために検索するHTTPヘッダーおよびメタ・キー。 リバース・プロキシの背後にある場合は、"HTTP_X_FORWARDED_FOR"などの項目をこのリストに追加します。 詳細は、管理者ガイドのプロキシ・サポートの項を参照してください。
  • 有効にした場合(デフォルト)、SAMLログインに成功すると、マップされた組織およびチームが自動的に作成されます。
  • スケジュールから起動するとき、同じジョブ・テンプレートが最大でいくつ実行を待機でき、それ以上は作成されないようにするか。(整数)
  • ユーザーが非アクティブになって何秒後に再度ログインすることが必要になるか。
  • ユーザーが持つことができる同時ログイン・セッションの最大数。 無効にするには、-1を入力します。
  • Azure ADアプリケーションからのOAuth2キー(クライアントID)。
  • SOCIAL_AUTH_AZUREAD_OAUTH2_ORGANIZATION_MAP
    ソーシャル認証アカウントから組織の管理者/ユーザーへのマッピング。 この設定によって、ユーザー名とEメール・アドレスに基づいて、どのユーザーがどの組織に配置されるかを制御します。 構成の詳細は、ドキュメントを参照してください。
  • Azure ADアプリケーションからのOAuth2シークレット(クライアント・シークレット)。
  • SOCIAL_AUTH_AZUREAD_OAUTH2_TEAM_MAP
    ソーシャル認証アカウントからのチーム・メンバー(ユーザー)のマッピング。 構成の詳細は、ドキュメントを参照してください。
  • GitHubエンタープライズ・インスタンスのAPI URL。たとえば: http(s)://hostname/api/v3/。 詳細はGithub Enterpriseのドキュメントを参照してください。
  • GitHub Enterprise開発者アプリケーションからのOAuth2キー(クライアントID)。
  • GitHubエンタープライズ・インスタンスのAPI URL。たとえば: http(s)://hostname/api/v3/。 詳細はGithub Enterpriseのドキュメントを参照してください。
  • GitHub Enterprise組織アプリケーションからのOAuth2キー(クライアントID)。
  • 組織URLで使用されるGitHub Enterprise組織の名前: https://github.com//.
  • SOCIAL_AUTH_GITHUB_ENTERPRISE_ORG_ORGANIZATION_MAP
    ソーシャル認証アカウントから組織の管理者/ユーザーへのマッピング。 この設定によって、ユーザー名とEメール・アドレスに基づいて、どのユーザーがどの組織に配置されるかを制御します。 構成の詳細は、ドキュメントを参照してください。
  • GitHub Enterprise組織アプリケーションのOAuth2シークレット(クライアント・シークレット)。
  • SOCIAL_AUTH_GITHUB_ENTERPRISE_ORG_TEAM_MAP
    ソーシャル認証アカウントからのチーム・メンバー(ユーザー)のマッピング。 構成の詳細は、ドキュメントを参照してください。
  • Github EnterpriseインスタンスのURL。たとえば: http(s)://hostname/。 詳細はGithub Enterpriseのドキュメントを参照してください。
  • SOCIAL_AUTH_GITHUB_ENTERPRISE_ORGANIZATION_MAP
    ソーシャル認証アカウントから組織の管理者/ユーザーへのマッピング。 この設定によって、ユーザー名とEメール・アドレスに基づいて、どのユーザーがどの組織に配置されるかを制御します。 構成の詳細は、ドキュメントを参照してください。
  • GitHub Enterprise開発者アプリケーションからのOAuth2シークレット(クライアント・シークレット)。
  • GitHubエンタープライズ・インスタンスのAPI URL。たとえば: http(s)://hostname/api/v3/。 詳細はGithub Enterpriseのドキュメントを参照してください。
  • Github Enterprise APIを使用した数値のチームIDの検索: http://fabian-kostadinov.github.io/2015/01/16/how-to-find-a-github-team-id/。
  • GitHub Enterprise組織アプリケーションからのOAuth2キー(クライアントID)。
  • SOCIAL_AUTH_GITHUB_ENTERPRISE_TEAM_MAP
    ソーシャル認証アカウントからのチーム・メンバー(ユーザー)のマッピング。 構成の詳細は、ドキュメントを参照してください。
  • SOCIAL_AUTH_GITHUB_ENTERPRISE_TEAM_ORGANIZATION_MAP
    ソーシャル認証アカウントから組織の管理者/ユーザーへのマッピング。 この設定によって、ユーザー名とEメール・アドレスに基づいて、どのユーザーがどの組織に配置されるかを制御します。 構成の詳細は、ドキュメントを参照してください。
  • GitHub Enterprise組織アプリケーションのOAuth2シークレット(クライアント・シークレット)。
  • SOCIAL_AUTH_GITHUB_ENTERPRISE_TEAM_TEAM_MAP
    ソーシャル認証アカウントからのチーム・メンバー(ユーザー)のマッピング。 構成の詳細は、ドキュメントを参照してください。
  • Github EnterpriseインスタンスのURL。たとえば: http(s)://hostname/。 詳細はGithub Enterpriseのドキュメントを参照してください。
  • Github EnterpriseインスタンスのURL。たとえば: http(s)://hostname/。 詳細はGithub Enterpriseのドキュメントを参照してください。
  • GitHub開発者アプリケーションからのOAuth2キー(クライアントID)。
  • GitHub組織アプリケーションからのOAuth2キー(クライアントID)。
  • 組織のURL: https://github.com//で使用されているGitHub組織の名前。
  • SOCIAL_AUTH_GITHUB_ORG_ORGANIZATION_MAP
    ソーシャル認証アカウントから組織の管理者/ユーザーへのマッピング。 この設定によって、ユーザー名とEメール・アドレスに基づいて、どのユーザーがどの組織に配置されるかを制御します。 構成の詳細は、ドキュメントを参照してください。
  • GitHub組織アプリケーションからのOAuth2シークレット(クライアント・シークレット)。
  • SOCIAL_AUTH_GITHUB_ORG_TEAM_MAP
    ソーシャル認証アカウントからのチーム・メンバー(ユーザー)のマッピング。 構成の詳細は、ドキュメントを参照してください。
  • SOCIAL_AUTH_GITHUB_ORGANIZATION_MAP
    ソーシャル認証アカウントから組織の管理者/ユーザーへのマッピング。 この設定によって、ユーザー名とEメール・アドレスに基づいて、どのユーザーがどの組織に配置されるかを制御します。 構成の詳細は、ドキュメントを参照してください。
  • GitHub開発者アプリケーションからのOAuth2シークレット(クライアント・シークレット)。
  • Github API: http://fabian-kostadinov.github.io/2015/01/16/how-to-find-a-github-team-id/を使用して、数値のチームIDを探します。
  • GitHub組織アプリケーションからのOAuth2キー(クライアントID)。
  • SOCIAL_AUTH_GITHUB_TEAM_MAP
    ソーシャル認証アカウントからのチーム・メンバー(ユーザー)のマッピング。 構成の詳細は、ドキュメントを参照してください。
  • SOCIAL_AUTH_GITHUB_TEAM_ORGANIZATION_MAP
    ソーシャル認証アカウントから組織の管理者/ユーザーへのマッピング。 この設定によって、ユーザー名とEメール・アドレスに基づいて、どのユーザーがどの組織に配置されるかを制御します。 構成の詳細は、ドキュメントを参照してください。
  • GitHub組織アプリケーションからのOAuth2シークレット(クライアント・シークレット)。
  • SOCIAL_AUTH_GITHUB_TEAM_TEAM_MAP
    ソーシャル認証アカウントからのチーム・メンバー(ユーザー)のマッピング。 構成の詳細は、ドキュメントを参照してください。
  • SOCIAL_AUTH_GOOGLE_OAUTH2_AUTH_EXTRA_ARGUMENTS
    Google OAuth2ログインの追加引数。 ユーザーが複数のGoogleアカウントでログインしている場合でも、1つのドメインのみを認証できるように制限できます。 詳細は、ドキュメントを参照してください。
  • WebアプリケーションからのOAuth2キー。
  • SOCIAL_AUTH_GOOGLE_OAUTH2_ORGANIZATION_MAP
    ソーシャル認証アカウントから組織の管理者/ユーザーへのマッピング。 この設定によって、ユーザー名とEメール・アドレスに基づいて、どのユーザーがどの組織に配置されるかを制御します。 構成の詳細は、ドキュメントを参照してください。
  • WebアプリケーションからのOAuth2シークレット。
  • SOCIAL_AUTH_GOOGLE_OAUTH2_TEAM_MAP
    ソーシャル認証アカウントからのチーム・メンバー(ユーザー)のマッピング。 構成の詳細は、ドキュメントを参照してください。
  • SOCIAL_AUTH_GOOGLE_OAUTH2_WHITELISTED_DOMAINS
    この設定を更新して、Google OAuth2を使用してログインできるドメインを制限します。
  • SOCIAL_AUTH_ORGANIZATION_MAP
    ソーシャル認証アカウントから組織の管理者/ユーザーへのマッピング。 この設定によって、ユーザー名とEメール・アドレスに基づいて、どのユーザーがどの組織に配置されるかを制御します。 構成の詳細は、ドキュメントを参照してください。
  • SOCIAL_AUTH_SAML_ENABLED_IDPS
    使用している各アイデンティティ・プロバイダ(IdP)のエンティティID、SSO URLおよび証明書を構成します。 複数のSAML IdPがサポートされています。 一部のIdPは、デフォルトのOIDとは異なる属性名を使用してユーザー・データを提供することがあります。 それぞれのIdPについて属性名を上書きできます。 詳細および構文は、Ansibleのドキュメントを参照してください。
  • SOCIAL_AUTH_SAML_EXTRA_DATA
    IDP属性をextra_attributesにマップするタプルのリスト。 各属性は、値が1つのみの場合でも値リストになります。
  • SOCIAL_AUTH_SAML_ORG_INFO
    アプリケーションのURL、表示名および名前を指定します。 構文の例は、ドキュメントを参照してください。
  • SOCIAL_AUTH_SAML_ORGANIZATION_ATTR
    ユーザー組織メンバーシップの翻訳に使用されます。
  • SOCIAL_AUTH_SAML_ORGANIZATION_MAP
    ソーシャル認証アカウントから組織の管理者/ユーザーへのマッピング。 この設定によって、ユーザー名とEメール・アドレスに基づいて、どのユーザーがどの組織に配置されるかを制御します。 構成の詳細は、ドキュメントを参照してください。
  • SOCIAL_AUTH_SAML_SECURITY_CONFIG
    基礎となるpython-samlセキュリティ設定(https://github.com/onelogin/python-saml#settings)に渡されるキー値ペアの辞書
  • SAMLサービス・プロバイダ(SP)構成のオーディエンスとして使用されるアプリケーション定義の一意の識別子。 これは通常、サービスのURLです。
  • SOCIAL_AUTH_SAML_SP_EXTRA
    基礎となるpython-samlサービス・プロバイダ構成設定に渡されるキー値ペアの辞書。
  • サービス・プロバイダ(SP)として使用するキー・ペアを作成し、秘密キーの内容をここに含めます。
  • サービス・プロバイダ(SP)として使用するキー・ペアを作成し、ここに証明書の内容を含めます。
  • SOCIAL_AUTH_SAML_SUPPORT_CONTACT
    サービス・プロバイダのサポート担当者の名前と電子メール・アドレスを指定します。 構文の例は、ドキュメントを参照してください。
  • SOCIAL_AUTH_SAML_TEAM_ATTR
    ユーザー・チーム・メンバーシップの翻訳に使用されます。
  • SOCIAL_AUTH_SAML_TEAM_MAP
    ソーシャル認証アカウントからのチーム・メンバー(ユーザー)のマッピング。 構成の詳細は、ドキュメントを参照してください。
  • SOCIAL_AUTH_SAML_TECHNICAL_CONTACT
    サービス・プロバイダの技術担当者の名前と電子メール・アドレスを指定します。 構文の例は、ドキュメントを参照してください。
  • SOCIAL_AUTH_SAML_USER_FLAGS_BY_ATTR
    SAMLからスーパー・ユーザーおよびシステム監査者をマップするために使用されます。
  • SOCIAL_AUTH_TEAM_MAP
    ソーシャル認証アカウントからのチーム・メンバー(ユーザー)のマッピング。 構成の詳細は、ドキュメントを参照してください。
  • SOCIAL_AUTH_USER_FIELDS
    空のリスト[]に設定すると、この設定では新しいユーザー・アカウントを作成できません。 以前にソーシャル認証を使用してログインしたことがあるか、電子メール・アドレスが一致するユーザー・アカウントを持っているユーザーのみがログインできます。
  • 標準出力が最大何バイト表示され、そのサイズを超えると出力のダウンロードが必要になるようにするか。(整数)
  • このパスワードは、サブスクリプションおよびコンテンツ情報を取得するために使用されます
  • このユーザー名は、サブスクリプションおよびコンテンツ情報を取得するために使用されます
  • TACACS+クライアントによって使用される認証プロトコルを選択します。
  • TACACS+サーバーのホスト名。
  • TACACS+サーバーのポート番号。
  • TACACS+サーバーに対して認証するための共有シークレット。
  • TACACS+セッションのタイムアウト値(秒)。0の場合、タイムアウトは無効になります。
  • この設定は、サービスに対して有効なURLをレンダリングする通知などのサービスで使用されます。
  • 無効にすると、イベントを受信したときにページがリフレッシュされません。 最新の詳細を取得するには、ページを再ロードする必要があります。
ネストされたスキーマ : AD_HOC_COMMANDS
型: array
アドホック・ジョブで使用できるモジュールのリスト。
ソースを表示
ネストされたスキーマ : AUTH_LDAP_1_CONNECTION_OPTIONS
型: object
LDAP接続について設定する追加オプション。 LDAP参照はデフォルトで無効になっています(特定のLDAP問合せがADでハングしないようにするため)。 オプション名は文字列である必要があります(例: "OPT_REFERRALS")。 設定可能なオプションと値は、https://www.python-ldap.org/doc/html/ldap.html#optionsを参照してください。
ネストされたスキーマ : AUTH_LDAP_1_GROUP_SEARCH
型: array
ユーザーは、LDAPグループのメンバーシップに基づいて組織にマップされます。 この設定では、グループを検索するためのLDAP検索問合せを定義します。 ユーザー検索とは異なり、グループ検索ではLDAPSearchUnionはサポートされていません。
ソースを表示
ネストされたスキーマ : AUTH_LDAP_1_GROUP_TYPE_PARAMS
型: object
選択したグループ・タイプのinitメソッドを送信するためのキー値パラメータ。
ネストされたスキーマ : AUTH_LDAP_1_ORGANIZATION_MAP
型: object
組織の管理者/ユーザーとLDAPグループの間のマッピング。 これにより、LDAPグループのメンバーシップを基準にして、組織に配置するユーザーが制御されます。 構成の詳細は、ドキュメントを参照してください。
ネストされたスキーマ : AUTH_LDAP_1_TEAM_MAP
型: object
チーム・メンバー(ユーザー)とLDAPグループの間のマッピング。 構成の詳細は、ドキュメントを参照してください。
ネストされたスキーマ : AUTH_LDAP_1_USER_ATTR_MAP
型: object
LDAPユーザー・スキーマとAPIユーザー属性のマッピング。 デフォルト設定はActiveDirectoryについては有効ですが、他のLDAP構成を持つユーザーは値を変更する必要がある場合があります。 詳細は、ドキュメントを参照してください。
ネストされたスキーマ : AUTH_LDAP_1_USER_FLAGS_BY_GROUP
型: object
指定されたグループからユーザーを取得します。 現時点では、サポートされているグループはスーパーユーザーとシステム監査者のみです。 詳細は、ドキュメントを参照してください。
ネストされたスキーマ : AUTH_LDAP_1_USER_SEARCH
型: array
ユーザーを検索するためのLDAP検索問合せ。 指定されたパターンと一致するユーザーがサービスにログインできます。 また、ユーザーは、(AUTH_LDAP_ORGANIZATION_MAP設定で定義された)組織にマップされている必要があります。 複数の検索問合せをサポートする必要がある場合は、"LDAPUnion"を使用できます。 詳細は、ドキュメントを参照してください。
ソースを表示
ネストされたスキーマ : AUTH_LDAP_2_CONNECTION_OPTIONS
型: object
LDAP接続について設定する追加オプション。 LDAP参照はデフォルトで無効になっています(特定のLDAP問合せがADでハングしないようにするため)。 オプション名は文字列である必要があります(例: "OPT_REFERRALS")。 設定可能なオプションと値は、https://www.python-ldap.org/doc/html/ldap.html#optionsを参照してください。
ネストされたスキーマ : AUTH_LDAP_2_GROUP_SEARCH
型: array
ユーザーは、LDAPグループのメンバーシップに基づいて組織にマップされます。 この設定では、グループを検索するためのLDAP検索問合せを定義します。 ユーザー検索とは異なり、グループ検索ではLDAPSearchUnionはサポートされていません。
ソースを表示
ネストされたスキーマ : AUTH_LDAP_2_GROUP_TYPE_PARAMS
型: object
選択したグループ・タイプのinitメソッドを送信するためのキー値パラメータ。
ネストされたスキーマ : AUTH_LDAP_2_ORGANIZATION_MAP
型: object
組織の管理者/ユーザーとLDAPグループの間のマッピング。 これにより、LDAPグループのメンバーシップを基準にして、組織に配置するユーザーが制御されます。 構成の詳細は、ドキュメントを参照してください。
ネストされたスキーマ : AUTH_LDAP_2_TEAM_MAP
型: object
チーム・メンバー(ユーザー)とLDAPグループの間のマッピング。 構成の詳細は、ドキュメントを参照してください。
ネストされたスキーマ : AUTH_LDAP_2_USER_ATTR_MAP
型: object
LDAPユーザー・スキーマとAPIユーザー属性のマッピング。 デフォルト設定はActiveDirectoryについては有効ですが、他のLDAP構成を持つユーザーは値を変更する必要がある場合があります。 詳細は、ドキュメントを参照してください。
ネストされたスキーマ : AUTH_LDAP_2_USER_FLAGS_BY_GROUP
型: object
指定されたグループからユーザーを取得します。 現時点では、サポートされているグループはスーパーユーザーとシステム監査者のみです。 詳細は、ドキュメントを参照してください。
ネストされたスキーマ : AUTH_LDAP_2_USER_SEARCH
型: array
ユーザーを検索するためのLDAP検索問合せ。 指定されたパターンと一致するユーザーがサービスにログインできます。 また、ユーザーは、(AUTH_LDAP_ORGANIZATION_MAP設定で定義された)組織にマップされている必要があります。 複数の検索問合せをサポートする必要がある場合は、"LDAPUnion"を使用できます。 詳細は、ドキュメントを参照してください。
ソースを表示
ネストされたスキーマ : AUTH_LDAP_3_CONNECTION_OPTIONS
型: object
LDAP接続について設定する追加オプション。 LDAP参照はデフォルトで無効になっています(特定のLDAP問合せがADでハングしないようにするため)。 オプション名は文字列である必要があります(例: "OPT_REFERRALS")。 設定可能なオプションと値は、https://www.python-ldap.org/doc/html/ldap.html#optionsを参照してください。
ネストされたスキーマ : AUTH_LDAP_3_GROUP_SEARCH
型: array
ユーザーは、LDAPグループのメンバーシップに基づいて組織にマップされます。 この設定では、グループを検索するためのLDAP検索問合せを定義します。 ユーザー検索とは異なり、グループ検索ではLDAPSearchUnionはサポートされていません。
ソースを表示
ネストされたスキーマ : AUTH_LDAP_3_GROUP_TYPE_PARAMS
型: object
選択したグループ・タイプのinitメソッドを送信するためのキー値パラメータ。
ネストされたスキーマ : AUTH_LDAP_3_ORGANIZATION_MAP
型: object
組織の管理者/ユーザーとLDAPグループの間のマッピング。 これにより、LDAPグループのメンバーシップを基準にして、組織に配置するユーザーが制御されます。 構成の詳細は、ドキュメントを参照してください。
ネストされたスキーマ : AUTH_LDAP_3_TEAM_MAP
型: object
チーム・メンバー(ユーザー)とLDAPグループの間のマッピング。 構成の詳細は、ドキュメントを参照してください。
ネストされたスキーマ : AUTH_LDAP_3_USER_ATTR_MAP
型: object
LDAPユーザー・スキーマとAPIユーザー属性のマッピング。 デフォルト設定はActiveDirectoryについては有効ですが、他のLDAP構成を持つユーザーは値を変更する必要がある場合があります。 詳細は、ドキュメントを参照してください。
ネストされたスキーマ : AUTH_LDAP_3_USER_FLAGS_BY_GROUP
型: object
指定されたグループからユーザーを取得します。 現時点では、サポートされているグループはスーパーユーザーとシステム監査者のみです。 詳細は、ドキュメントを参照してください。
ネストされたスキーマ : AUTH_LDAP_3_USER_SEARCH
型: array
ユーザーを検索するためのLDAP検索問合せ。 指定されたパターンと一致するユーザーがサービスにログインできます。 また、ユーザーは、(AUTH_LDAP_ORGANIZATION_MAP設定で定義された)組織にマップされている必要があります。 複数の検索問合せをサポートする必要がある場合は、"LDAPUnion"を使用できます。 詳細は、ドキュメントを参照してください。
ソースを表示
ネストされたスキーマ : AUTH_LDAP_4_CONNECTION_OPTIONS
型: object
LDAP接続について設定する追加オプション。 LDAP参照はデフォルトで無効になっています(特定のLDAP問合せがADでハングしないようにするため)。 オプション名は文字列である必要があります(例: "OPT_REFERRALS")。 設定可能なオプションと値は、https://www.python-ldap.org/doc/html/ldap.html#optionsを参照してください。
ネストされたスキーマ : AUTH_LDAP_4_GROUP_SEARCH
型: array
ユーザーは、LDAPグループのメンバーシップに基づいて組織にマップされます。 この設定では、グループを検索するためのLDAP検索問合せを定義します。 ユーザー検索とは異なり、グループ検索ではLDAPSearchUnionはサポートされていません。
ソースを表示
ネストされたスキーマ : AUTH_LDAP_4_GROUP_TYPE_PARAMS
型: object
選択したグループ・タイプのinitメソッドを送信するためのキー値パラメータ。
ネストされたスキーマ : AUTH_LDAP_4_ORGANIZATION_MAP
型: object
組織の管理者/ユーザーとLDAPグループの間のマッピング。 これにより、LDAPグループのメンバーシップを基準にして、組織に配置するユーザーが制御されます。 構成の詳細は、ドキュメントを参照してください。
ネストされたスキーマ : AUTH_LDAP_4_TEAM_MAP
型: object
チーム・メンバー(ユーザー)とLDAPグループの間のマッピング。 構成の詳細は、ドキュメントを参照してください。
ネストされたスキーマ : AUTH_LDAP_4_USER_ATTR_MAP
型: object
LDAPユーザー・スキーマとAPIユーザー属性のマッピング。 デフォルト設定はActiveDirectoryについては有効ですが、他のLDAP構成を持つユーザーは値を変更する必要がある場合があります。 詳細は、ドキュメントを参照してください。
ネストされたスキーマ : AUTH_LDAP_4_USER_FLAGS_BY_GROUP
型: object
指定されたグループからユーザーを取得します。 現時点では、サポートされているグループはスーパーユーザーとシステム監査者のみです。 詳細は、ドキュメントを参照してください。
ネストされたスキーマ : AUTH_LDAP_4_USER_SEARCH
型: array
ユーザーを検索するためのLDAP検索問合せ。 指定されたパターンと一致するユーザーがサービスにログインできます。 また、ユーザーは、(AUTH_LDAP_ORGANIZATION_MAP設定で定義された)組織にマップされている必要があります。 複数の検索問合せをサポートする必要がある場合は、"LDAPUnion"を使用できます。 詳細は、ドキュメントを参照してください。
ソースを表示
ネストされたスキーマ : AUTH_LDAP_5_CONNECTION_OPTIONS
型: object
LDAP接続について設定する追加オプション。 LDAP参照はデフォルトで無効になっています(特定のLDAP問合せがADでハングしないようにするため)。 オプション名は文字列である必要があります(例: "OPT_REFERRALS")。 設定可能なオプションと値は、https://www.python-ldap.org/doc/html/ldap.html#optionsを参照してください。
ネストされたスキーマ : AUTH_LDAP_5_GROUP_SEARCH
型: array
ユーザーは、LDAPグループのメンバーシップに基づいて組織にマップされます。 この設定では、グループを検索するためのLDAP検索問合せを定義します。 ユーザー検索とは異なり、グループ検索ではLDAPSearchUnionはサポートされていません。
ソースを表示
ネストされたスキーマ : AUTH_LDAP_5_GROUP_TYPE_PARAMS
型: object
選択したグループ・タイプのinitメソッドを送信するためのキー値パラメータ。
ネストされたスキーマ : AUTH_LDAP_5_ORGANIZATION_MAP
型: object
組織の管理者/ユーザーとLDAPグループの間のマッピング。 これにより、LDAPグループのメンバーシップを基準にして、組織に配置するユーザーが制御されます。 構成の詳細は、ドキュメントを参照してください。
ネストされたスキーマ : AUTH_LDAP_5_TEAM_MAP
型: object
チーム・メンバー(ユーザー)とLDAPグループの間のマッピング。 構成の詳細は、ドキュメントを参照してください。
ネストされたスキーマ : AUTH_LDAP_5_USER_ATTR_MAP
型: object
LDAPユーザー・スキーマとAPIユーザー属性のマッピング。 デフォルト設定はActiveDirectoryについては有効ですが、他のLDAP構成を持つユーザーは値を変更する必要がある場合があります。 詳細は、ドキュメントを参照してください。
ネストされたスキーマ : AUTH_LDAP_5_USER_FLAGS_BY_GROUP
型: object
指定されたグループからユーザーを取得します。 現時点では、サポートされているグループはスーパーユーザーとシステム監査者のみです。 詳細は、ドキュメントを参照してください。
ネストされたスキーマ : AUTH_LDAP_5_USER_SEARCH
型: array
ユーザーを検索するためのLDAP検索問合せ。 指定されたパターンと一致するユーザーがサービスにログインできます。 また、ユーザーは、(AUTH_LDAP_ORGANIZATION_MAP設定で定義された)組織にマップされている必要があります。 複数の検索問合せをサポートする必要がある場合は、"LDAPUnion"を使用できます。 詳細は、ドキュメントを参照してください。
ソースを表示
ネストされたスキーマ : AUTH_LDAP_CONNECTION_OPTIONS
型: object
LDAP接続について設定する追加オプション。 LDAP参照はデフォルトで無効になっています(特定のLDAP問合せがADでハングしないようにするため)。 オプション名は文字列である必要があります(例: "OPT_REFERRALS")。 設定可能なオプションと値は、https://www.python-ldap.org/doc/html/ldap.html#optionsを参照してください。
ネストされたスキーマ : AUTH_LDAP_GROUP_SEARCH
型: array
ユーザーは、LDAPグループのメンバーシップに基づいて組織にマップされます。 この設定では、グループを検索するためのLDAP検索問合せを定義します。 ユーザー検索とは異なり、グループ検索ではLDAPSearchUnionはサポートされていません。
ソースを表示
ネストされたスキーマ : AUTH_LDAP_GROUP_TYPE_PARAMS
型: object
選択したグループ・タイプのinitメソッドを送信するためのキー値パラメータ。
ネストされたスキーマ : AUTH_LDAP_ORGANIZATION_MAP
型: object
組織の管理者/ユーザーとLDAPグループの間のマッピング。 これにより、LDAPグループのメンバーシップを基準にして、組織に配置するユーザーが制御されます。 構成の詳細は、ドキュメントを参照してください。
ネストされたスキーマ : AUTH_LDAP_TEAM_MAP
型: object
チーム・メンバー(ユーザー)とLDAPグループの間のマッピング。 構成の詳細は、ドキュメントを参照してください。
ネストされたスキーマ : AUTH_LDAP_USER_ATTR_MAP
型: object
LDAPユーザー・スキーマとAPIユーザー属性のマッピング。 デフォルト設定はActiveDirectoryについては有効ですが、他のLDAP構成を持つユーザーは値を変更する必要がある場合があります。 詳細は、ドキュメントを参照してください。
ネストされたスキーマ : AUTH_LDAP_USER_FLAGS_BY_GROUP
型: object
指定されたグループからユーザーを取得します。 現時点では、サポートされているグループはスーパーユーザーとシステム監査者のみです。 詳細は、ドキュメントを参照してください。
ネストされたスキーマ : AUTH_LDAP_USER_SEARCH
型: array
ユーザーを検索するためのLDAP検索問合せ。 指定されたパターンと一致するユーザーがサービスにログインできます。 また、ユーザーは、(AUTH_LDAP_ORGANIZATION_MAP設定で定義された)組織にマップされている必要があります。 複数の検索問合せをサポートする必要がある場合は、"LDAPUnion"を使用できます。 詳細は、ドキュメントを参照してください。
ソースを表示
ネストされたスキーマ : AWX_ANSIBLE_CALLBACK_PLUGINS
型: array
ジョブの実行時に使用される追加のコールバック・プラグインを検索するパスのリスト。 1行にパスを1つずつ入力します。
ソースを表示
ネストされたスキーマ : AWX_ISOLATION_SHOW_PATHS
型: array
本来なら非表示にするパスのうち、分離されたジョブに公開するパスのリスト。 1行にパスを1つずつ入力します。
ソースを表示
ネストされたスキーマ : AWX_TASK_ENV
型: object
プレイブックの実行、インベントリの更新、プロジェクトの更新および通知の送信について設定された追加の環境変数。
ネストされたスキーマ : CUSTOM_VENV_PATHS
型: array
Towerが(/var/lib/awx/venv/に加えて)カスタム仮想環境を検索するパス。 1行にパスを1つずつ入力します。
ソースを表示
ネストされたスキーマ : LOG_AGGREGATOR_LOGGERS
型: array
HTTPログをコレクタに送信するロガーのリスト。これには、awx - サービス・ログ、activity_stream - アクティビティ・ストリーム・レコード、job_events - Ansibleジョブ・イベントからのコールバック・データ、system_tracking - スキャン・ジョブから収集されたファクトのいずれかまたはすべてを含めることができます。
ソースを表示
ネストされたスキーマ : OAUTH2_PROVIDER
型: object
OAuth 2のタイムアウトをカスタマイズするための辞書。使用可能な項目はACCESS_TOKEN_EXPIRE_SECONDS (アクセス・トークンの期間(秒数))、AUTHORIZATION_CODE_EXPIRE_SECONDS (認可コードの期間(秒数))およびREFRESH_TOKEN_EXPIRE_SECONDS (期限切れアクセス・トークンの後のリフレッシュ・トークンの期間(秒数))です。
ネストされたスキーマ : PROXY_IP_ALLOWED_LIST
型: array
サービスがリバース・プロキシ/ロード・バランサの背後にある場合は、この設定を使用して、サービスがカスタムのREMOTE_HOST_HEADERSヘッダー値を信頼するプロキシIPアドレスを構成します。 この設定が空のリスト(デフォルト)である場合は、REMOTE_HOST_HEADERSで指定されたヘッダーが無条件に信頼されます
ソースを表示
ネストされたスキーマ : REMOTE_HOST_HEADERS
型: array
リモート・ホスト名またはIPを特定するために検索するHTTPヘッダーおよびメタ・キー。 リバース・プロキシの背後にある場合は、"HTTP_X_FORWARDED_FOR"などの項目をこのリストに追加します。 詳細は、管理者ガイドのプロキシ・サポートの項を参照してください。
ソースを表示
ネストされたスキーマ : SOCIAL_AUTH_AZUREAD_OAUTH2_ORGANIZATION_MAP
型: object
ソーシャル認証アカウントから組織の管理者/ユーザーへのマッピング。 この設定によって、ユーザー名とEメール・アドレスに基づいて、どのユーザーがどの組織に配置されるかを制御します。 構成の詳細は、ドキュメントを参照してください。
ネストされたスキーマ : SOCIAL_AUTH_AZUREAD_OAUTH2_TEAM_MAP
型: object
ソーシャル認証アカウントからのチーム・メンバー(ユーザー)のマッピング。 構成の詳細は、ドキュメントを参照してください。
ネストされたスキーマ : SOCIAL_AUTH_GITHUB_ENTERPRISE_ORG_ORGANIZATION_MAP
型: object
ソーシャル認証アカウントから組織の管理者/ユーザーへのマッピング。 この設定によって、ユーザー名とEメール・アドレスに基づいて、どのユーザーがどの組織に配置されるかを制御します。 構成の詳細は、ドキュメントを参照してください。
ネストされたスキーマ : SOCIAL_AUTH_GITHUB_ENTERPRISE_ORG_TEAM_MAP
型: object
ソーシャル認証アカウントからのチーム・メンバー(ユーザー)のマッピング。 構成の詳細は、ドキュメントを参照してください。
ネストされたスキーマ : SOCIAL_AUTH_GITHUB_ENTERPRISE_ORGANIZATION_MAP
型: object
ソーシャル認証アカウントから組織の管理者/ユーザーへのマッピング。 この設定によって、ユーザー名とEメール・アドレスに基づいて、どのユーザーがどの組織に配置されるかを制御します。 構成の詳細は、ドキュメントを参照してください。
ネストされたスキーマ : SOCIAL_AUTH_GITHUB_ENTERPRISE_TEAM_MAP
型: object
ソーシャル認証アカウントからのチーム・メンバー(ユーザー)のマッピング。 構成の詳細は、ドキュメントを参照してください。
ネストされたスキーマ : SOCIAL_AUTH_GITHUB_ENTERPRISE_TEAM_ORGANIZATION_MAP
型: object
ソーシャル認証アカウントから組織の管理者/ユーザーへのマッピング。 この設定によって、ユーザー名とEメール・アドレスに基づいて、どのユーザーがどの組織に配置されるかを制御します。 構成の詳細は、ドキュメントを参照してください。
ネストされたスキーマ : SOCIAL_AUTH_GITHUB_ENTERPRISE_TEAM_TEAM_MAP
型: object
ソーシャル認証アカウントからのチーム・メンバー(ユーザー)のマッピング。 構成の詳細は、ドキュメントを参照してください。
ネストされたスキーマ : SOCIAL_AUTH_GITHUB_ORG_ORGANIZATION_MAP
型: object
ソーシャル認証アカウントから組織の管理者/ユーザーへのマッピング。 この設定によって、ユーザー名とEメール・アドレスに基づいて、どのユーザーがどの組織に配置されるかを制御します。 構成の詳細は、ドキュメントを参照してください。
ネストされたスキーマ : SOCIAL_AUTH_GITHUB_ORG_TEAM_MAP
型: object
ソーシャル認証アカウントからのチーム・メンバー(ユーザー)のマッピング。 構成の詳細は、ドキュメントを参照してください。
ネストされたスキーマ : SOCIAL_AUTH_GITHUB_ORGANIZATION_MAP
型: object
ソーシャル認証アカウントから組織の管理者/ユーザーへのマッピング。 この設定によって、ユーザー名とEメール・アドレスに基づいて、どのユーザーがどの組織に配置されるかを制御します。 構成の詳細は、ドキュメントを参照してください。
ネストされたスキーマ : SOCIAL_AUTH_GITHUB_TEAM_MAP
型: object
ソーシャル認証アカウントからのチーム・メンバー(ユーザー)のマッピング。 構成の詳細は、ドキュメントを参照してください。
ネストされたスキーマ : SOCIAL_AUTH_GITHUB_TEAM_ORGANIZATION_MAP
型: object
ソーシャル認証アカウントから組織の管理者/ユーザーへのマッピング。 この設定によって、ユーザー名とEメール・アドレスに基づいて、どのユーザーがどの組織に配置されるかを制御します。 構成の詳細は、ドキュメントを参照してください。
ネストされたスキーマ : SOCIAL_AUTH_GITHUB_TEAM_TEAM_MAP
型: object
ソーシャル認証アカウントからのチーム・メンバー(ユーザー)のマッピング。 構成の詳細は、ドキュメントを参照してください。
ネストされたスキーマ : SOCIAL_AUTH_GOOGLE_OAUTH2_AUTH_EXTRA_ARGUMENTS
型: object
Google OAuth2ログインの追加引数。 ユーザーが複数のGoogleアカウントでログインしている場合でも、1つのドメインのみを認証できるように制限できます。 詳細は、ドキュメントを参照してください。
ネストされたスキーマ : SOCIAL_AUTH_GOOGLE_OAUTH2_ORGANIZATION_MAP
型: object
ソーシャル認証アカウントから組織の管理者/ユーザーへのマッピング。 この設定によって、ユーザー名とEメール・アドレスに基づいて、どのユーザーがどの組織に配置されるかを制御します。 構成の詳細は、ドキュメントを参照してください。
ネストされたスキーマ : SOCIAL_AUTH_GOOGLE_OAUTH2_TEAM_MAP
型: object
ソーシャル認証アカウントからのチーム・メンバー(ユーザー)のマッピング。 構成の詳細は、ドキュメントを参照してください。
ネストされたスキーマ : SOCIAL_AUTH_GOOGLE_OAUTH2_WHITELISTED_DOMAINS
型: array
この設定を更新して、Google OAuth2を使用してログインできるドメインを制限します。
ソースを表示
ネストされたスキーマ : SOCIAL_AUTH_ORGANIZATION_MAP
型: object
ソーシャル認証アカウントから組織の管理者/ユーザーへのマッピング。 この設定によって、ユーザー名とEメール・アドレスに基づいて、どのユーザーがどの組織に配置されるかを制御します。 構成の詳細は、ドキュメントを参照してください。
ネストされたスキーマ : SOCIAL_AUTH_SAML_ENABLED_IDPS
型: object
使用している各アイデンティティ・プロバイダ(IdP)のエンティティID、SSO URLおよび証明書を構成します。 複数のSAML IdPがサポートされています。 一部のIdPは、デフォルトのOIDとは異なる属性名を使用してユーザー・データを提供することがあります。 それぞれのIdPについて属性名を上書きできます。 詳細および構文は、Ansibleのドキュメントを参照してください。
ネストされたスキーマ : SOCIAL_AUTH_SAML_EXTRA_DATA
型: array
IDP属性をextra_attributesにマップするタプルのリスト。 各属性は、値が1つのみの場合でも値リストになります。
ソースを表示
ネストされたスキーマ : SOCIAL_AUTH_SAML_ORG_INFO
型: object
アプリケーションのURL、表示名および名前を指定します。 構文の例は、ドキュメントを参照してください。
ネストされたスキーマ : SOCIAL_AUTH_SAML_ORGANIZATION_ATTR
型: object
ユーザー組織メンバーシップの翻訳に使用されます。
ネストされたスキーマ : SOCIAL_AUTH_SAML_ORGANIZATION_MAP
型: object
ソーシャル認証アカウントから組織の管理者/ユーザーへのマッピング。 この設定によって、ユーザー名とEメール・アドレスに基づいて、どのユーザーがどの組織に配置されるかを制御します。 構成の詳細は、ドキュメントを参照してください。
ネストされたスキーマ : SOCIAL_AUTH_SAML_SECURITY_CONFIG
型: object
基礎となるpython-samlセキュリティ設定(https://github.com/onelogin/python-saml#settings)に渡されるキー値ペアの辞書
ネストされたスキーマ : SOCIAL_AUTH_SAML_SP_EXTRA
型: object
基礎となるpython-samlサービス・プロバイダ構成設定に渡されるキー値ペアの辞書。
ネストされたスキーマ : SOCIAL_AUTH_SAML_SUPPORT_CONTACT
型: object
サービス・プロバイダのサポート担当者の名前と電子メール・アドレスを指定します。 構文の例は、ドキュメントを参照してください。
ネストされたスキーマ : SOCIAL_AUTH_SAML_TEAM_ATTR
型: object
ユーザー・チーム・メンバーシップの翻訳に使用されます。
ネストされたスキーマ : SOCIAL_AUTH_SAML_TEAM_MAP
型: object
ソーシャル認証アカウントからのチーム・メンバー(ユーザー)のマッピング。 構成の詳細は、ドキュメントを参照してください。
ネストされたスキーマ : SOCIAL_AUTH_SAML_TECHNICAL_CONTACT
型: object
サービス・プロバイダの技術担当者の名前と電子メール・アドレスを指定します。 構文の例は、ドキュメントを参照してください。
ネストされたスキーマ : SOCIAL_AUTH_SAML_USER_FLAGS_BY_ATTR
型: object
SAMLからスーパー・ユーザーおよびシステム監査者をマップするために使用されます。
ネストされたスキーマ : SOCIAL_AUTH_TEAM_MAP
型: object
ソーシャル認証アカウントからのチーム・メンバー(ユーザー)のマッピング。 構成の詳細は、ドキュメントを参照してください。
ネストされたスキーマ : SOCIAL_AUTH_USER_FIELDS
型: array
空のリスト[]に設定すると、この設定では新しいユーザー・アカウントを作成できません。 以前にソーシャル認証を使用してログインしたことがあるか、電子メール・アドレスが一致するユーザー・アカウントを持っているユーザーのみがログインできます。
ソースを表示
先頭に戻る

レスポンス

サポートされているメディア・タイプ

201レスポンス

403レスポンス

本文
レスポンスの例(application/json)
{
    "detail":"You do not have permission to perform this action."
}

409レスポンス

本文
レスポンスの例(application/json)
{
    "error":"Logging not enabled"
}
先頭に戻る