ACL-Sortierung mit RepoInit in Adobe Experience Manager LTS
In diesem Artikel wird beschrieben, wie Änderungen an der Einfügereihenfolge der ACL mit RepoInit in Adobe Experience Manager (AEM) LTS-Versionen dazu führen können, dass benutzerdefinierte Gruppenzulassungsberechtigungen durch Standardregeln vom Typ „Ablehnen“ überschrieben werden. Außerdem werden Schritte beschrieben, um die richtige ACL-Reihenfolge sicherzustellen.
Beschreibung description
Umgebung
- Adobe Experience Manager (AEM) 6.6.x (LTS SP2)
- Adobe Experience Manager (AEM) 6.5.x
Problem/Symptome
Wenn benutzerdefinierte Autorengruppen und ACLs mit Sling RepoInit erstellt werden, unterscheidet sich die Reihenfolge der Zugriffssteuerungseinträge (ACEs) zwischen AEM 6.5 und AEM LTS (6.6.x). In AEM 6.5 werden benutzerdefinierte ACEs nach default/product ACEs auf denselben Pfaden angehängt. In AEM LTS werden benutzerdefinierte ACLs vor Standard-ACEs eingefügt. Auf einem Pfad wie /content/projects kann beispielsweise ein benutzerdefinierter Gruppeneintrag „Zulassen“ vor einem standardmäßigen Eintrag „Alle verweigern“ angezeigt werden. Da alle Benutzenden Mitglieder der Gruppe „Alle“ sind, kann der Eintrag „Ablehnen“ die benutzerdefinierten Gruppenberechtigungen außer Kraft setzen, was sich auf die Lese- und Schreibberechtigungen für diese Gruppen auswirkt. Es werden keine Fehlermeldungen protokolliert, aber wirksame Berechtigungen sind betroffen.
Ursache
Eine Änderung der Einfügereihenfolge der RepoInit-ACL in AEM LTS führt dazu, dass benutzerdefinierte Zulassungseinträge vor den standardmäßigen Ablehnungseinträgen eingefügt werden. Dies führt dazu, dass benutzerdefinierte Berechtigungen durch Ablehnungsregeln überschrieben werden. Durch das explizite Entfernen und erneute Hinzufügen von ACLs über RepoInit wird die richtige Reihenfolge sichergestellt.
Lösung resolution
Gehen Sie wie folgt vor, um das Problem zu beheben:
-
Aktualisieren Sie Ihre RepoInit-Konfiguration, um vorhandene benutzerdefinierte ACLs explizit aus den betroffenen Pfaden zu entfernen, bevor Sie sie erneut hinzufügen. Beispiel:
code language-none set ACL for remove * on /content/projects allow jcr:lockManagement, jcr:read, jcr:versionManagement, jcr:write on /content/projects end
Ersetzen Sie <custom-group> durch den tatsächlichen Gruppennamen.
2. Stellen Sie die aktualisierte RepoInit-Konfiguration über Ihre standardmäßige Bereitstellungs-Pipeline bereit.
3. Überprüfen Sie nach der Bereitstellung, ob die ACL-Reihenfolge erwartungsgemäß ist und ob die benutzerdefinierten Gruppenberechtigungen wirksam sind. Sie können CRXDE oder die AEM-Sicherheitskonsole verwenden, um zu bestätigen, dass benutzerdefinierte Zulassungseinträge nach den standardmäßigen Ablehnungseinträgen für die entsprechenden Pfade angezeigt werden.
4. Testen Sie Lösch- und Schreibvorgänge für betroffene Gruppen, um sicherzustellen, dass die Berechtigungen korrekt sind.
5. Vermeiden Sie die manuelle Neuanordnung von ACLs in CRXDE für Produktionsumgebungen, da dies keine skalierbare oder unterstützte langfristige Lösung ist.