I did some more research. ACTool can't handle the duplicates, but if I
remove the duplicate using CRX/DE before running ACTool it works fine. I
can remove the duplicate ACL. After that ACTool has no more issues
either. If I bump into the problem again I will try the Access Control
Hi all,I hit this roadblock today. 🙁I have a duplicate ACE on
/content/cq:tags and there seems to be no way to remove it.Here is a
screenshot from CRX/DE:I'm running AEM 126.96.36.199.When I click the red (-)
icon on either one of the duplicate ACL to remove it, I get the
following error: Caused by:
OakAccessControl0013: Duplicate ACE '/content/cq:tags/rep:policy/allow7'
found in policy at
Indeed sameerb50449612 you are correct.I didn't follow up on this
thread, but you need to do 2 things:install the VanityURLS-Components
package on the publisherapply your own ACL to allow read access to
/libs/granite/dispatcher/content/vanityUrls for anonymousRegardsWim
Hi community,I just published a new Medium article where we share the
knowledge we gathered at VRT on how we have developed a safe way to
install AEM packages, after 5 years of perfecting the process.Read it at
Hope you like it!Wim
It looks like there is no release yet for crx2oak for AEM 6.5.Normally,
this should match the oak repository major version. So something like
1.10.x, but no trace of it in Index of
/groups/public/com/adobe/granite/crx2oak , nor does the release notes
page exist for AEM 6.5:
there be such a release soon?We have used crx2oak 3x successfully now
for upgrading AEM using an offline content copy.Would be nice to keep
My guess is that it used by the replication agent to check whether or
not you are connected to the correct shared datastore. If the secret
matches with the one in the datastore, binaryless replication is
allowed. If it doesn't match, binaryless replication is denied.
I would create a user group which has access to the particular area
(/content/custom-folder). You can regular user accounts to that group
for users who need access. Also create a service user, add it to the
group and let your custom consoles use the service user to access and
control the content instead of the logged in user.
After installing the vanityurls-components package 1.0.2 the content
appeared in CRX/DE, but the URL was not accessible for "everyone".When I
added an ACL to allow read on
/libs/granite/dispatcher/content/vanityUrls, the unauthenticated http
works as expected.Strange the package doesn't contain such an ACL
rule.On the other hand, I read the Replication agent configuration
documentation again. There, they speak of an "...
Hi all,According to the documentation at Configuring Dispatcher we no
longer need to install the VanityURLS-Components package anymore on AEM
instances > 6.3.I just setup an AEM 6.4.3 instance and there is no
/libs/granite/dispatcher/content/vanityUrls.html to be found.Is the
documentation just plain wrong?Has it been moved to another path? Or
must we still install the VanityURLS-Components package on AEM 6.4
Looks totally fine. (We have similar settings).But your suspects are
strange as they consume so little heap space. (214 MB for suspect 1, 79
MB for suspect 2).Are you sure you didn't miss something else?When we
have OOM's on AEM, we find suspects holding 6 GB or more.
Strange. Looks legit to me.Can you take a look at
http://:4502/system/console/memoryusage (the URL, not the
path) and paste the content?That should show your current memory
configuration and free space.
Don’t work with fixed ip’s in auto scaling groups. Use something like
Consul. But there is much more to it than that. There is the issue of
configuring your replication agents whenever a new Instance is added and
when an instance is removed. You also need a way to copy your repository
from live instances to new instances. Not something to take lightly.
There were some good presentations about this in the last two Adobe
According to what I see, is that you only have 800mb of heap space.
Seems to me you did not pass Xms and Xmx parameters to your publish
instance. A production instance needs more than 1gb ram. Give it some
more breathing room. For example 4gb.
You can’t use remote paths. You must use local paths. To to do what you
want to do, copy the full repository from box1 to box2 using for example
scp or rsync to another location, like /data/source. Then run the
crx2oak tool on box2 using /data/source as input and
/opt/aem/crx-quickstart/repository/segmentstore.After that, you can
delete /data/source on box2.
Have you tried following the best practice as described in
?I mean, deny access to everything in your first filter rule, and then
gradually allowing access to whatever is needed?If you deny access to
everything all POSTs will be blocked.
I would upgrade to the latest version of the AEM dispatcher first. See
AEM Dispatcher Release Notes . If I remember correctly we had the same
issue in an earlier version of the dispatcher. About the testing tools,
there is The Dispatcher Security Checklist and the dispatcher health
checks in Operations Dashboard.
Does the same JSP trick work here? Just remove the newlines from the
source. For example:Etc.
If you are delivering content through the dispatcher and it does gzip
encoding most of the white space bytes would be removed in the
compressed version, so the overhead over the wire would be relatively
When you architect and implement your application, you know exactly
which selectors you use, so it should not be rocket science to only
allow those selectors in the dispatcher filter rules. The idea is to
whitelist only what is needed. By default AEM allows for example to
export your entire content tree as JSON. That on itself would require so
much resources you would kill your instance.
Make sure your sslfilter is configured correctly if you are using ssl
termination in the dispatcher or load balancer. See AEM redirecting user
back to http if accessed through SSL terminated Load Balancer for
details. We experienced the same issue. When the sslfilter is set
correctly, the cookie becomes secure as well.