ドキュメントExperience Cloud KCS

ADOBE EXPERIENCE MANAGER LTSでのRepoInitによるACLの順序付け

最終更新日： 2026年8月10日

この記事では、Adobe Experience Manager（AEM） LTS バージョンのRepoInitを使用したACL挿入順序の変更により、カスタムグループの許可の権限がデフォルトの拒否ルールで上書きされる可能性がある方法について説明し、ACLの順序を正しく保つための手順を説明します。

説明 description

環境

  • Adobe Experience Manager（AEM） 6.6.x （LTS SP2）
  • Adobe Experience Manager（AEM） 6.5.x

問題/症状

Sling RepoInitを使用してカスタム作成者グループとACLを作成する場合、AEM 6.5とAEM LTS （6.6.x）の間でアクセス制御エントリ（ACE）の順序が異なります。 AEM 6.5では、同じパスのdefault/product個のACEの後にカスタム ACEが追加されます。 AEM LTSでは、カスタム ACLはデフォルトのACEの前に挿入されます。 例えば、/content/projectsなどのパスでは、カスタムグループの許可エントリが、デフォルトの「全員を拒否」エントリの前に表示される場合があります。 すべてのユーザーはeveryone グループのメンバーであるため、「拒否」エントリはカスタムグループの権限を上書きし、これらのグループの削除および書き込み権限に影響を与える可能性があります。 エラーメッセージはログに記録されませんが、効果的な権限は影響を受けます。

原因

AEM LTSでRepoInit ACLの挿入順序が変更されると、カスタム許可エントリがデフォルトの拒否エントリの前に挿入され、拒否ルールがカスタム権限を上書きします。 RepoInitを介してACLを明示的に削除して再追加すると、正しい順序が保証されます。

解決策 resolution

問題を修正するには、次の手順に従います。

  1. RepoInit設定を更新して、影響を受けるパスから既存のカスタム ACLを明示的に削除してから再追加します。 次に例を示します。

    code language-none 
    set ACL for
remove * on /content/projects
allow jcr:lockManagement, jcr:read, jcr:versionManagement, jcr:write on /content/projects
end

<custom-group>を実際のグループ名に置き換えます。
​2. 更新されたRepoInit設定を標準デプロイメントパイプラインを通じてデプロイします。
​3. デプロイメント後、ACLの順序が期待どおりであり、カスタムグループ権限が効果的であることを確認します。 CRXDEまたはAEM セキュリティコンソールを使用して、カスタム許可エントリが、関連するパスのデフォルトの拒否エントリの後に表示されることを確認できます。
​4. 影響を受けるグループの削除および書き込み操作をテストして、権限が正しいことを確認します。
​5. CRXDEでは、本番環境向けのACLを手動で並べ替えるのは避けてください。これは、拡張性に優れた長期的なソリューションではなく、サポート対象の長期的なソリューションでもありません。

recommendation-more-help
experience-cloud-kcs-help-kbarticles