403 error when saving in crx/de | Community
Skip to main content
B
bkowalk2
December 2, 2019
Solved

403 error when saving in crx/de

  • December 2, 2019
  • 5 replies
  • 3142 views

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 <script> 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!

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by bkowalk2

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!

5 replies

U
Adobe Employee
user05162Adobe Employee
Adobe Employee
December 2, 2019

Which version of AEM are you trying with?

B
bkowalk2Author
December 2, 2019

I'm in AEM 6.4.0

B
bkowalk2AuthorAccepted solution
December 2, 2019

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!

U
Adobe Employee
user05162Adobe Employee
Adobe Employee
December 2, 2019

You can change the dispatcher log level to DEBUG and try to find what might be causing this issue.

B
bkowalk2Author
December 6, 2019

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 <script> tag. We disabled that function and all is well. Hopefully that helps some random person out there!

Terms & ConditionsAccessibility statement

Loading footer...