has anyone seen error
[error_key] => json.invalid.value.no_script_tags
[error_message] => #/email_content: Field does not support script content.
when sending HTML email through API?
That's really good feedback. We'll take a look at the error message and add some additional color to it to give better direction in the future. Thanks again for your patience and great feedback along the way. Let us know anything else you think we can do better on or add, always interested in feedback!
I used this HTML and was able to create the campaign in my account. Are you able to do the same or still having problems? https://gist.github.com/daveberard/6174108
Here is the JSON payload I used as well if you want to compare: https://gist.github.com/daveberard/6174147
If you update some of the information in that JSON payload you should be able to use that directly and compare with your JSON payload. The last link to HTML you posted didn't actually contain a link to your HTML, so if you could update that we can run that through as well and see if there is something else failing validation that we didn't catch.
I'm not getting any errors on validation on that HTML. I can use it in my test campaign creation JSON just by encoding it and using it, see this Gist example JSON for a working example using your exact HTML: https://gist.github.com/daveberard/6184633
Do you have a sample of your JSON that is failing the validation you can put up on Gist or somewhere else? Please make sure any personal information is removed in anything you publish on the forums. I'm wondering if there is some sort of JSON encoding issue that is going on that is manifesting in a strange way here.
As it stands, this issue is still unresolved for about 3 weeks now (just from my knowledge). We self-diagnosed one issue that had to do with a mis-spelling (stye instead of style). This shouldn't have caused an issue, but for whatever reason, it did. Now, the issue has reoccurred in multiple places and is ultimately causing our system to fail.
I've targeted the simplest code I could find in order to eliminate any other potential issues and found that this is failing: https://gist.github.com/sdover102/6308314 . At this point, my hope is that you guys can take care of it in some fashion, although I feel it's a bit too late. Unfortunately, we've invested a lot in your system, with at least a weekly email going out to 60,000 users...and are stumped by this "unsolvable" issue.
Any help you can provide today would be much appreciated. As a side note, a previous post on this thread went into a fair amount of detail about how my html could look askew in Outlook / etc. While this advice is appreciated, it is a distraction from the true problem, which is the fact that emails are not making it into your system because of an erroneous "Field does not support script content" error.
Tested out your HTML, looks like it is cellborder="0" which is causing the problem (ran the HTML through a validator to find the invalid tags, that came up as a non-standard tag). Once I removed that, had no problems. Here is the sample JSON I used: https://gist.github.com/daveberard/265237089cbf20c418aa
We are more than happy to add any valid tags and attributes to our validator, we will even add non-standard ones that are browser specific or used for specific browser hacks, tricks or otherwise. However, we do validate based on HTML/XHTML standards by default and have chosen to put specific exceptions for non-standard HTML instead of allowing anything in. This is to prevent anyone from using any sort of hacks or tricks that could cause injection attacks, rendering hacks in our product or other email clients or any other behavior that could be considered malicious. We also took your feedback on the error message and will be updating it in our next release to better explain the failure.
I apologize for the furstration and inconvenience here. There is a balance between security and developer flexibility that we are trying to work though. I know this doesn't help you with your specific experience, but I did want to make sure you understand why we are being conservative and restrictive. Since we are allowing 3rd parties to provide us with content that is both sent out from our servers to end users as well as display this content in our UI, we are very cautious to make sure everything coming into our product and sent out from our mailers contain nothing that could be malicious.
Here's my html: https://gist.github.com/anonymous/68cca1409e78a6903f15
Thanks for submitting that, we'll take a look and see what we can find. Will update soon.
Update from our engineering staff below. Regarding the HTML5/CSS3 items, we don't have an ETA on the overal HTML5/CSS3 compatibility as a whole, especially because the spec for both of those standards is far from complete and still in comity. However, we will definitely work on upgrading our support for any of the portions that are in a Draft Standard state according to IETF workflows.
Examining the email_content attribute in the payload specified in the https://gist.github.com/anonymous/ef8c82cc63549ad90ac2
I noticed that the unescaped html content differed from the payload specified in https://gist.github.com/anonymous/68cca1409e78a6903f15.
In particular, the email_content html attribute did not seem to be proper html, with extra or placed incorrectly tags.
This caused our html/css parser to choke and as a result, flag some errors that should not have occurred.
However, after testing with the valid html specified in https://gist.github.com/anonymous/68cca1409e78a6903f15, we did notice that our parser did lake support for certain
html5/css3 tags. For your particular payload, the style attribute that was causing issues was "border-radius". We are working to update our parser to enable more coverage
of the html5/css3 attributes, and support for the border-radius tag should be coming soon.
I'm experiencing the same issue. Email is content is valid HTML 4.01 Transitional per W3 Validator. Using PHP v2 SDK. With a minimal HTML body everything works but something in the newsletter is causing problems.
Json request is at : http://pastebin.com/zN7SkeMX
Any help would be much appreciated.
Hi Jessica, I'm trying to look into the issue that you are having, but it appears the Paste Bin is no longer valid. Can you repost that so we can take a look at it?
What kind of error message are you getting? I've done some testing, and I'm not getting the error message
json.invalid.value.no_script_tags:#/email_content: Field does not support script content.
I am, however, getting this error message:
Which is most likely because instead of angle brackets e.g. "<" or ">" you have escaped your html. Your html should only be json escaped, as opposed to html and json escaped.
I made this change and did some additional testing, and it looks like we need to add additional support for html5 attributes like "vertical-align" on the "img" tag. I am continuing to investigate.
Thanks. I had been trying a few things since my original post one of which was escaping the HTML. I should have disabled that before sending the JSON data to you.
Well, I was able to figure out what was causing our validation to fail based on your payload. Our validation was failing since it didn't support "center" for the "vertical-align" css attribute. We also had some issues with the meta tag as we didn't support the "name" attribute on that tag, and the value of the content "HTML Tidy for Linux/x86 (vers 25 March 2009), see www.w3.org" had some characters that we weren't supporting for this attribute.
I've updated our code base, and a fix should be coming out in the next couple days.
Still not working with this JSON:
I'm fed up. I'm not using your terrible v2 API anymore. I'm going back to XML since it at least works. This is just bad development. Why you feel you need to parse style tags is beyond me. Frankly, it's an embarrasment.
Sorry about the frustrations you're having. We are continuously trying to improve the validation to ensure that we are only catching malicious code. As for the reasons we are doing this, I would like to re-emphasize those we previously mentioned.
In the new API, which will at some point replace the old XML one, we are taking security very seriously. While we can't go back and retrofit the old API with this security, we have and will continue to use it going forward. This is to ensure we minimize all potential threats we can regarding SQL injection, partial HTML injection and other script/css hacks from getting into our product. The HTML which comes through our API can be displayed in our UI and we do have a number of individuals who try to abuse that UI and hack us.
While I certainly understand that this is frustrating, we will at some point require developers to move to this new API. We appreciate anyone who is running into these problems working with us to move forward and we do take this very seriously. Whenever one of these reports comes in, we immediately have a developer take a look at the report and identify any exceptions we need to add to the filtering we run. Anything that is legitimate CSS/HTML or reasonable to exclude, we do. Generally speaking, from a security perspective it is always safer to have an inclusive filter than an exclusive filter. This is the direction we are moving with all of our products and services.
If you're going to perform validation or filtering of the HTML we're submitting (which is understandable), you absolutely need to provide either the specifics of what you're validating against, or a tool for developers to use outside of the API to manually validate our HTML and point out any speficic issues. Otherwise we're just wandering around in the dark. You need to provide a flashlight.