I'm working on my first Action on Google and having a headache trying to work out how to display unicode characters in my basic card and the spoken text.
For example "Beyoncé" renders as "Beyoncé" in the simulator and on my phone.
The data is coming from my Amazon API Gateway, which returns the result of my Lambda. The logging here shows the correct format, so I guess my Action isn't set up correctly?
Interestingly, emojis don't render either (hard-coded in the same lambda). Having followed this guide https://developers.google.com/actions/assistant/responses#rich-responses so I must be missing some configuration?
Im my DialogFlow Fulfilment setup for the Webhook, I've set the charset to UTF-8 and Content-Type to application/json
Is there anything else to configure?
My resolution was to add further configuration settings to my AWS API Gateway. It appears that DialogFlow v2 no longer assumes (or defaults to?) the utf-8 charset for the web hook response.
Just add content-type: application/json; charset=UTF-8 to your method response header, rather than relying on this value being persisted from the request header.
Related
I am using the following tutorial:
https://www.twilio.com/docs/sms/tutorials/how-to-receive-and-reply-python-amazon-lambda
When I test the api in aws I receive a 415 error, Unsupported Media Type.
I assume this is related to the fact that Twilio sends its data in the form of application/x-www-form-urlencoded and AWS wants json.
The tutorial takes this into account. However, its code does not work for me.
I have searched the web, and tried numerous fixes to no avail.
The raw data from Twilio is (with sensitive information changed)
ToCountry=US&ToState=AK&SmsMessageSid=SM7777777777777777777777&NumMedia=0&ToCity=AAA&FromZip=99999&SmsSid=SM9999999999999999999&FromState=AK&SmsStatus=received&FromCity=BBB&Body=Is+this+json+&FromCountry=US&To=%2B15555555555&ToZip=88888&NumSegments=1&ReferralNumMedia=0&MessageSid=SM888888888888888888&AccountSid=AC6666666666666666&From=%2B14444444444&ApiVersion=2010-04-01
I enter this information in the body section of the test, run the test and the error is thrown.
There is also the same error when I try the actual webhook through Twilio.
I have also entered with surrounded in {}
I have also tried a jsonified version with the ampersands changed to commas, and the equal signs changed to colons with the items in quotes.
I also have tried:
{
"to_number": "+14444444444",
"from_number": "+15555555555",
"message": "hello does this API work"
}
I have also tried to add the following to the header of the test
"Content-Type": ["application/x-www-form-urlencoded"]
Many of the fixes I have tried involve changing the Integration Request mapping.
None have worked.
The one from the tutorial is:
#set($httpPost = $input.path('$').split("&"))
{
#foreach( $kvPair in $httpPost )
#set($kvTokenised = $kvPair.split("="))
#if( $kvTokenised.size() > 1 )
"$kvTokenised[0]" : "$kvTokenised[1]"#if( $foreach.hasNext ),#end
#else
"$kvTokenised[0]" : ""#if( $foreach.hasNext ),#end
#end
#end
}
And is of content type application/x-www-form-urlencoded
There is a stack on this topic:
Amazon Api gateway integration with Twilio
None of its solutions worked for me.
I thought the following was very promising, but it also failed for me.
https://gist.github.com/199911/68a43f83fd933b1e3ac6
I have also tried to change the lambda function. However I do not think it is the source. Its tests work.
Any help would be much appreciated.
Quote from AWS console:
You can configure binary support for your API by specifying which media types should be treated as binary types. API Gateway will look at the Content-Type and Accept HTTP headers to decide how to handle the body.
It sounds like you should configure your specific media type "application/x-www-form-urlencoded" under API gateway settings (Binary Media Types), which will tell the API gateway to accept that body type.
Navigate to Api Gateway Console:
Click on your API
On the left select settings (under API menu)
Scroll down and click Add Binary Media Type
Type application/x-www-form-urlencoded Click save
Hoping this will help.
Google released this blog post which says:
If you authorize download requests to the Drive API using the access
token in a query parameter, you will need to migrate your requests to
authenticate using an HTTP header instead. Starting January 1, 2020,
download calls to files.get, revisions.get and files.export endpoints
which authenticate using the access token in the query parameter will
no longer be supported, which means you’ll need to update your
authentication method.
and then says:
For file downloads, redirect to the webContentLink which will instruct
the browser to download the content. If the application wants to
display the file to the user, they can simply redirect to the
alternateLink in v2 or webViewLink in v3.
however if we use webContentLink then we will hit the 100mb virus page mentioned here.
I can see that the migration has been delayed, however sooner or later this will happen, and we want to future-proof the application.
How will we be able to download content without hitting the 100mb virus limit, after this change is implemented?
If you authorize download requests to the Drive API using the access token in a query parameter, you will need to migrate your requests to authenticate using an HTTP header instead.
Example query param:
GET https://www.googleapis.com/drive/v3/files/[FILEID]?access_token=[YOUR_ACCESS_TOKEN] HTTP/1.1
Accept: application/json
Example requests header:
GET https://www.googleapis.com/drive/v3/files/[FILEID] HTTP/1.1
Authorization: Bearer [YOUR_ACCESS_TOKEN]
Accept: application/json
Assuming that you can do the http header option then you should not have any issues with the download as mentioned. The issues with download only come into play if you cant add the authorization header. In which case i think you would need to go with option number two and export the files directly.
Using Plugin Registration, I registered webhook, Power automate and sample webhook as well.
Json (Remote execution context) sent to webhook seems to be fine but when German characters appears in field values, it sends as rubbish.
I tried adding httpheader to webhook as Content-type: application/json; charset=utf-8 or Accept-Charset: utf-8
but this did not helped.
Did anyone previously faced similar issue?
I suspect there is bug from Dynamics-crm side especially plugin registration tool, but I might be wrong.
You can use IServiceEndpointNotificationService to encode the content before sending or alternatively what you can do is creating an Azure Function that you will invoke on your Webhook and inside the function you should encode the content to UTF-8 and make a second call to you final endpoint, you can do there also further transformation of data if needed.
I have a POST method exposed though an API in AWS API Gateway. It would process a certain JSON. But there is a weird requirement: I am supposed to accept anything and return always a 200 status code (as long as the service is available and working of course).
So if I receive a call with Content-Type: image/jpeg, application/xml or what/ever, I must be able to map the request to my Lambda function.
I have achieved to map any request to a custom type using the VTL (Velocity Template Language), the issue is that I must specify every single Content/Type I want to support in the Integration Request.
I would like to define a fallback mapping template for every Content-Type that is not among those that I have already defined. It is not allowed to specify "*/*" as Content-Type.
I can not use When no template matches the request Content-Type header option as passthrough because b y default the lambda function tries to deserialize the body from a JSON format.
Any ideas?
I think you should enable the When no template matches the request Content-Type header option. As documented your Lambda will get an API Gateway event. This event has a headers field that, on a POST should contain a content-type field. If your code understands the content-type then handle it. If not, return a response that has the correct status code and whatever is appropriate. This is not on the API gateway side but rather on the Lambda side.
See this blog for some additional ideas.
I have a problem while sending a message via Jersey client on Mandrill API. I use Jersey client as follows:
ClientBuilder.newClient()
.register(JacksonJsonProvider.class)
.target(“https://mandrillapp.com/api/1.0/messages/send.json”)
.request(MediaType.APPLICATION_JSON_TYPE)
.post(Entity.json(methodEntity));
Below you can see logged headers, method and content of the API request.
POST https://mandrillapp.com/api/1.0/messages/send.json
Accept: application/json
Content-Type: application/json
{"message":{"subject":"Hello World!","text":"Really, Im just saying hi from Mandrill!","to":[{"email":"marcel#xxxx.com","name":"Marcel cccc","type":"to"}],"headers":{},"tags":["test"],"from_email":"info#xxxxx.com","auto_text":true,"preserve_recipients":false},"async":false,"key":"EWIBVEIOVBVOIEBWIOVEB"}
In response to this request I keep receiving following message:
[{"email":"marcel#XXXX.com","status":"rejected","_id":"0ea5e40fc2f3413ba85b765acdc5f17a","reject_reason":"invalid-sender"}]
I do not know what the issue may be, from some posts I figured out I must use UTF-8 to encode my message and headers. But setting encoding to UTF-8 did not do much good. Otherwise the payload seems fine to me and moreover I found on forums that invalid sender can mean any other kind of issue (not just invalid sender which is sad).
I had exactly same problem with
"reject_reason":"invalid-sender"
You probably check already similar question Mandrill “reject_reason”: “invalid-sender”
Try it if it helps. I realize that you also missing header parameter in your request
e.g. User-Agent: Mandrill-myclient/1.0
Please try also add this parameter to your Jersey Client setup as following:
ClientBuilder.newClient()
.register(JacksonJsonProvider.class)
.target(“https://mandrillapp.com/api/1.0/messages/send.json”)
.request(MediaType.APPLICATION_JSON_TYPE)
.header("User-Agent", "Mandrill-myclient/1.0")
.post(Entity.json(methodEntity));
Does it help?