Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.
SOLVED

403 error when saving in crx/de

Avatar

Level 2

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!

1 Accepted Solution

Avatar

Correct answer by
Level 2

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!

View solution in original post

5 Replies

Avatar

Employee Advisor

Which version of AEM are you trying with?

Avatar

Correct answer by
Level 2

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!

Avatar

Employee Advisor

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

Avatar

Level 2

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!