We're on AEM 6.4. And correct, they all seem to be INFO or unrelated
WARN level messages. Noticed a traversal warning on line 20 here (this
is the log at the very start of the error happening). Does that help
with any clues? Here's that line separated out so you don't have to
hunt:06.12.2019 14:41:00.258 *WARN* [Thread-108]
Traversed 1000 nodes with filter Filter(query=select e.[jcr:path] as
[jcr:path], e.[jcr:score] as [jcr:score]...
Wanted to add an update here in case anyone else sees the same thing.
This was actually because we recently moved our AEM instances behind
CloudFlare so that we can block any malicious traffic. The CloudFlare
WAF has a function in place for XSS that blocks POST requests that
include a tag. We disabled that function and all is well.
Hopefully that helps some random person out there!
Hoping someone has seen this before.If we try to explore doing a revert
by doing a past version preview on any page in our system, we see a
massive server spike for several hours as the logs fill with messages
like this, for every single page on the server. Not even just child
pages - just seems that clicking "preview" on any version of anything
causes the server to suddenly rethink its entire life Makes the version
preview feature entirely fail for us, obviously... even if we let it run
Well, never mind. Looks like the issue only shows up when we're using
AEM author through a dispatcher instance. Not sure what on the
dispatcher is stripping out those scripts, but it doesn't look like this
is an AEM problem. Never mind! Closing my question. Thanks!
As part of debugging, I'll sometimes make a quick change to a component
HTL file in CRX/DE. Lately, however, whenever I try to save an HTL file
that includes a tag anywhere in it, I get back the error "Could
not save changes. Received 403 () for saving changes in workspace
crx.default. Unknown error (Error Code: 403)".I've noticed, further,
that I can't add an HTML file to the DAM that has a <script> tag in it,
or create that type of file anywhere on the system in CRX/DE and try to
save. Seems like anywhere on the system, if I'm uploading HTML with JS
in it, AEM gets angry. I can only deploy these types of files in
packages right now. Remove the script tags from the files, and all of
the above cases are solved. But this doesn't help our broken workflow
for files that need scripts in them. Which is... you know... somewhat
often... Has anyone seen this behavior before? Is there a security rule
somewhere that somehow got switched on?Thanks in advance!
I think it could probably happen similarly to any of the config
nodes.Seems to have been an issue with the permissions set with our
contentimport when we moved to 6.3. We’ve found a few other weird
permissionsissues, so we just keep this in mind when checking things
now.Good luck!On Tue, Nov 21, 2017 at 5:53 AM dixitp96985602
Super strange solution that Daycare helped us find - if you browse all
the way down our /apps/ tree in crxde until you get to the actual
rtePlugins node from up above and then switch to the permissions tab and
explicitly grant read access to the content-authors group, it fixes the
issue. Seems to be an issue with AEM not carrying the content-authors
access to the parent /apps/ folder down to that specific node. Not sure
of the cause yet, but we were able to reproduce on a vanilla instance in
Our text component's RTE has a few extra style options and source mode
enabled. When I log into the system as an administrator, they display
fine. When our authors (content-authors group with full
read/write/replicate access to the content folder, among other things)
log in, though, they're not able to see the additional buttons. The RTE
only displays in its default layout. I've tried unlocking read access to
the whole tree and even that doesn't seem to fix it... nothing short of
adding them to ...