I'm sending an email with help of the sendgrid api v3 but got the warning/error:
Content with characters ', " or & may need to be escaped with three brackets
{{{ content }}}
in my api json i'm adding an link containing the & character:
{"dynamic_template_data": {"link":"...&..."}}
in my template i'm using the three brackets {{{ link }}}
Everything works as expected - email incl. link are send - but i always got the warning/error.
Do i miss something within the json?
I've looked at their code for node.js and as long as any content string has either a (",',&) it will console.warn the message your are seeing.
if (/['"&]/.test(value)) {
console.warn(DYNAMIC_TEMPLATE_CHAR_WARNING);
}
See: https://github.com/sendgrid/sendgrid-nodejs/blob/47b6a5cd583cc10544ac19434419bdda5272b107/packages/helpers/classes/mail.js
You can notice the difference with using 2 vs 3 brackets on sendgrid's email template below:
Related
I am calling a web activity in a pipeline that is sending out an email (via Logic App).
Body of the email is being sent as a parameter from the ADF pipeline.
I am forming this body dynamically and want to embed new line characters in the body when i pass the string to the web activity.
Please suggest how can this be done.
P.S. I've tried embedding "\n" characters already and it is not working
According to Replacing special characters, the answer is something like this:
uriComponentToString('%0A')
Open the json code, make sure you are using "\n", instead of "\n"
I am trying to get a value and use it in sendgrid email template. The JSON looks like this.
"productskumapping" : {
"created/updated" : 2,
"failed" : 0
}
{{productskumapping.created/updated}} does not give any value in the email template. the macro is not replaced. But the macro must replace with 2. How to make this work? the slash character("/") is causing the issue. Please sugggest any solution for this.
Twilio SendGrid developer evangelist here.
SendGrid uses handlebars style expressions to interpolate data. I just learned that slashes were a deprecated way that handlebars the library used to navigate objects. I don't know if SendGrid uses that exact handlebars library internally, but I thought it was important.
I believe the way to get around a slash in a key, like you have, is to surround the key with square brackets instead. This is known as literal segments and would look like this for you:
{{productskumapping.[created/updated]}}
I'm making requests to Twitter, using the OAuth1.0 signing process to set the Authorization header. They explain it step-by-step here, which I've followed. It all works, most of the time.
Authorization fails whenever special characters are sent without percent encoding in the query component of the request. For example, ?status=hello%20world! fails, but ?status=hello%20world%21 succeeds. But the change from ! to the percent encoded form %21 is only made in the URL, after the signature is generated.
So I'm confused as to why this fails, because AFAIK that's a legally encoded query string. Only the raw strings ("status", "hello world!") are used for signature generation, and I'd assume the server would remove any percent encoding from the query params and generate its own signature for comparison.
When it comes to building the URL, I let URLComponents do the work, so I don't add percent encoding manually, ex.
var urlComps = URLComponents()
urlComps.scheme = "https"
urlComps.host = host
urlComps.path = path
urlComps.queryItems = [URLQueryItem(key: "status", value: "hello world!")]
urlComps.percentEncodedQuery // "status=hello%20world!"
I wanted to see how Postman handled the same request. I selected OAuth1.0 as the Auth type and plugged in the same credentials. The request succeeded. I checked the Postman console and saw ?status=hello%20world%21; it was percent encoding the !. I updated Postman, because a nice little prompt asked me to. Then I tried the same request; now it was getting an authorization failure, and I saw ?status=hello%20world! in the console; the ! was no longer being percent encoded.
I'm wondering who is at fault here. Perhaps Postman and I are making the same mistake. Perhaps it's with Twitter. Or perhaps there's some proxy along the way that idk, double encodes my !.
The OAuth1.0 spec says this, which I believe is in the context of both client (taking a request that's ready to go and signing it before it's sent), and server (for generating another signature to compare against the one received):
The parameters from the following sources are collected into a
single list of name/value pairs:
The query component of the HTTP request URI as defined by
[RFC3986], Section 3.4. The query component is parsed into a list
of name/value pairs by treating it as an
"application/x-www-form-urlencoded" string, separating the names
and values and decoding them as defined by
[W3C.REC-html40-19980424], Section 17.13.4.
That last reference, here, outlines the encoding for application/x-www-form-urlencoded, and says that space characters should be replaced with +, non-alphanumeric characters should be percent encoded, name separated from value by =, and pairs separated by &.
So, the OAuth1.0 spec says that the query string of the URL needs to be decoded as defined by application/x-www-form-urlencoded. Does that mean that our query string needs to be encoded this way too?
It seems to me, if a request is to be signed using OAuth1.0, the query component of the URL that gets sent must be encoded in a way that is different to what it would normally be encoded in? That's a pretty significant detail if you ask me. And I haven't seen it explicitly mentioned, even in Twitter's documentation. And evidently the folks at Postman overlooked it too? Unless I'm not supposed to be using URLComponents to build a URL, but that's what it's for, no? Have I understood this correctly?
Note: ?status=hello+world%21 succeeds; it tweets "hello world!"
I ran into a similar issue.
put the status in post body, not query string.
Percent-encoding:
private encode(str: string) {
// encodeURIComponent() escapes all characters except: A-Z a-z 0-9 - _ . ! ~ * " ( )
// RFC 3986 section 2.3 Unreserved Characters (January 2005): A-Z a-z 0-9 - _ . ~
return encodeURIComponent(str)
.replace(/[!'()*]/g, c => "%" + c.charCodeAt(0).toString(16).toUpperCase());
}
Scenario: I have a custom entity with attachments in Dynamics CRM 2011. I want to query those attachments with file name that contains a hash tag ('#'). Say I have attached a few text documents. kdk#ie.txt, Report.txt, & k!ke.txt to the custom entity.
Here are my results to my Odata query.
Error Code:
//ORGANIATION/XRMServices/2011/OrganizationData.svc/AnnotationSet?$filter=ObjectId/Id eq guid'{GUID HERE}' and IsDocument eq true and substringof('#',FileName)
Return: Bad Request
Because it is a unicode I tried the following on the string parameter.
'\u0023'
'U+0021'
'w%u0023'
But return is either 0 or Bad Request
I tested '!' & 'Report' it was successful return 1 respectively. It seem it only does not work for the #.
Any ideas why I am not getting the result I expected?
Really appreciate it.
TIA
"#" sign is a special character in a URL. It has to be encoded to not create an invalid URL. msdn.microsoft.com/en-us/library/aa226544(SQL.80).aspx
What I'm trying to do is format the email address like so Foo Bar <foo#bar.com> so email clients (including web based like gmail) will show the sender as "Foo Bar" and not just "foo" since that is the prefix on the email.
Is this possible in Magento 1.5? If I try to put the formatting in the field itself I get an error message.
That's what the Sender Name field does. This is what my setup looks like and what it looks like in Thunderbird (my webmail client formats it similarly, too):
You may look at code/core/Mage/Core/Model/Email.php for the actual mail implementation. You may notice it uses Zend_Mail. Now, here is the catch:
For security reasons, Zend_Mail filters all header fields to prevent header
injection with newline (\n) characters. Double quotation is changed to single
quotation and angle brackets to square brackets in the name of sender and recipients.
If the marks are in email address, the marks will be removed.
What you can do though is to make a module to rewrite the current class Mage_Core_Model_Email and overwrite the send() function. I covered rewriting classes before in this question's answer. Then, in this new rewritten class, you could PHPmailer, invoke shell mail commands, or whatever PHP library you would happen to know that would allow this behaviour.
Best of luck.
I'm not sure if it can work. In magento inside is a Zend_Validate which does validation of such email addresses. And I dont think so that email like 'Foo Bar ' is valid. But I think the display in customer's email client depend on client, no?