I am using googleAPI and Nodjs to fetch mails in details using oauth2.0.But I am not getting email's signature with image attached format.What is API to fetch incoming email with signature as image attached format?
A signature as an image is incorporated by Gmail not as an attachment or inline image, but rather as a download link assigned to img src within the text/html of your message body.
Here a snippet of the response you obtain if you log the body of the message retrieved in raw format (the domain name and file ID replaced with XXX for privacy reasons):
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br clear=3D"all"><div><div dir=3D"ltr" class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><img src=3D"htt=
ps://drive.google.com/a/XXXXXXXXXXXXXXXXX/uc?id=3DXXXXXXXXXXXXXXXXXX=
sYV-&export=3Ddownload"><br></div></div></div></div>
Keep in mind that the URL is quoted-printable encoded. You need to remove the soft line breaks = and replace =3D by = to obtain the correct URL - something like
https://drive.google.com/a/XXXXXXXXXXXXXXXXX/uc?id=XXXXXXXXXXXXXXXXXXsYV-&export=download
This link you can either open in your browser or access it programmatically by getting the body part of your message (filtering for Content-Type: text/html) and extracting the link e.g. with a Regex expression.
Related
My main objective is to upload .pptx/.docx/.pdf file to Microsoft Sharepoint using Microsoft Graph API.
Am able to upload to simple text files using the below "PUT" request, where the content-type is multipart/form-data
https://graph.microsoft.com/v1.0/drives/{drive-id}/root:/{simple.txt}:/content
But for .pptx/.docx/.pdf files, although am getting response as "200 ok", but no file is getting creating in sharepoint site document.
I have correctly configured File type with "File" as the key and selected the appropriate file in the value of the body of the request in postman.
Observation -> While uploading txt file, the response is "201 created" and the contents of the uploaded files is getting changed. For example, if the content was "Hello there". The upload file content is,
----------------------------404518839734975569926100
Content-Disposition: form-data; name="File"; filename="sample.txt"
Content-Type: text/plain
Hello there
----------------------------404518839734975569926100--
Can someone explain what's going on here and how to upload pptx/doc/pdf file in sharepoint using MS Graph API's.
You could upload the .docx file using Graph API in post man like this.
PUT drives/{drive-id}/root:/fileName.docx:/content
In Body, choose binary type.
Since DocuSign API have limitations on the max size of 25 MB per request, we have to split our envelope creation into multiple request, initially the envelope will be created as draft. Then the documents will be updated to the same envelope using envelope Documents update call.
However we are getting a 'FORMAT_CONVERSION_ERROR' error for each Word doc I add using multi part request. PDF docs can be added successfully
"errorDetails": {
"errorCode": "FORMAT_CONVERSION_ERROR",
"message": "The data could not be converted."
}
Is there a work around to make it work for multi-part request?
Here are the steps I followed:
I am creating envelope(without documents) in the first POST API call(https://demo.docusign.net/restapi/v2/accounts/{accountid}/envelopes)
Adding documents(both pdf and docx) to the envelope (multipart method) by making PUT API call for each document(https://demo.docusign.net/restapi/v2/accounts/{accountid}/envelopes/{envelopeId}/documents/{docId})
Only PDF files are uploaded to the docusign, whereas getting 400 error "FORMAT_CONVERSION_ERROR - The data could not be converted" error for docx type file upload
I am adding this header "Content-Disposition", "file; filename={filename};fileExtension={ext};documentId={id}"
Any suggestion/solution will be appreciated.
Log details:
PUT https://demo.docusign.net:7801/restapi/v2/accounts/{myaccountid}/envelopes/{myenvelopeid}/documents/1
TraceToken: d0d9eae1-01d3-4c56-928d-da38a7ac30fc
Timestamp: 2020-01-09T08:48:52.7616114Z
Content-Type: multipart/form-data; boundary=LV-qEHBRJq6zprmD52mUZfeNsrT5alHGfkE8w
Content-Disposition: file; filename=MyTemplate.docx; fileExtension=docx; documentId=1
Content-Length: 12998
Connection: Keep-Alive
Transfer-Encoding: chunked
Authorization: bearer [omitted]
Expect: 100-continue
Host: demo.docusign.net
User-Agent: Apache-HttpClient/4.0.3(java 1.5)
X-SecurityProtocol-Version: TLSv1.2
X-SecurityProtocol-CipherSuite: ECDHE-RSA-AES256-GCM-SHA384
x-forwarded-for: 106.51.84.53
--LV-qEHBRJq6zprmD52mUZfeNsrT5alHGfkE8w
Content-Disposition: form-data; name="MyTemplate.docx"; filename="MyTemplate.docx"
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
//Some binary data here.
--LV-qEHBRJq6zprmD52mUZfeNsrT5alHGfkE8w--
400 BadRequest
Content-Type: application/json; charset=utf-8
Content-Length: 96
X-DocuSign-TraceToken: d0d9eae1-01d3-4c56-928d-da38a7ac30fc
{
"errorCode": "FORMAT_CONVERSION_ERROR",
"message": "The data could not be converted."
}
Few things to check:
Does this happen with any word document or just a specific one?
Can you upload the same Word document directly to DocuSign web app and it works fine?
how large is the file in question? Is it possible it's still over 25M?
Consider using binary file transfer. Here is an example of code showing you how to do this:
https://developers.docusign.com/esign-rest-api/code-examples/code-example-send-binary
You can use multi-part mime encoding of the envelope with the individual files either BASE64 encoded or sent in binary format.
Check that you're using binary format and that the entire request to DocuSign is not over 25 MB.
Download and run a version of the eg-03- example software repository for your favorite language. These repos are stored in github.com/docusign they are documented here: https://developers.docusign.com/esign-rest-api/code-examples/code-example-send-binary.
Within the example code, workflow #10 shows how to send in binary mode. The example sends a Word document so you can substitute your own to check that it works ok.
I have configured SendGrid Inbound Parse webhook to get email content on my AWS API endpoint.
So I am getting email content in multipart/form-data format but in string which contains \n\r.
AWS API event.body= --xYzZY\r\nContent-Disposition: form-data; name="dkim"\r\n\r\n{#perficient.onmicrosoft.com : pass}\r\n--xYzZY\r\nContent-Disposition: form-data; name="subject"\r\n\r\nFW: Test email
I want to extract fields like FROM, TO, Subject, Body, Attachment technology using NodeJS
After replacing \n\r with \n & process body with structured multipart form data getting following error
{ "errorType": "Error", "errorMessage": "Unexpected end of multipart data", "stack": [ "Error: Unexpected end of multipart data", " at /var/task/node_modules/dicer/lib/Dicer.js:61:28", " at process._tickCallback (internal/process/next_tick.js:61:11)" ] }
Suggest using a node library like formidable to do all the hard work of parsing multipart/form-data for you. This will likely avoid the problem in the first place.
This has me baffled.
I can request the document content as base64 with curl , no problem.
curl https://demo.docusign.net/restapi/v2/accounts/<id>/envelopes/<id>/documents<id> -H"Authorization : Bearer <token>" -H "Content-Transfer-Encoding: base64" -o <filename>
Return headers are
Content-Disposition: file; filename="blah"; documentid="1"
Content-Transfer-Encoding: base64
and the file is returned in base64 format.
Using the Apache oltu oauth2 library which underneath uses HttpURLConnection I cannot get the response to be sent in base 64. I have the request headers set to
Content-Transfer-Encoding: base64
Accept : */*
Authorisation : Bearer <token>
But all I ever get back is the binary version of the file which ultimately bombs out because the library saves the stream as a string which screws up the pdf.
I can't trace the return header , but the request header definitely has the above fields set.
Is there anything in the Docusign endpoints which look at the User-Agent or anything else to determine whether to do the base 64 encoding ? Why else would it only ever return the binary stream ?
I suspect your Java output is not the same and the best way to confirm this is to capture exact JSON/SOAP request posted by your API calls via Java to DocuSign by following steps explained at this DocuSign support article https://support.docusign.com/guides/ndse-user-guide-api-request-logging
Please post these and I am sure it will be we will be able to deduce the library "add" that is changing the actual output.
OK thanks #david for the advice on logging the requests in docusign. I find that the "Transfer-Content-Encoding" header has mysteriously disappeared on arrival at the Docusign server. Some digging indicates that
a. this header is dodgy anyway for non-email uses and that
b. in the Java HttpUrlConnection class it is "removed" as security measure. You can apparently set some flags to revert to previous behaviour. See https://bugs.openjdk.java.net/browse/JDK-6996110
In any case I worked around the problem by implementing a class which reads the response as an InputStream and not worrying about base64.
Hopefully this helps a Java OAuth library user save a day of their lives banging their heads against a wall !
I noticed the Direct Line request url is like this: https://localhost:8011/api/ in the documention. What should replace it with?
I have deployed a todoBot example project from botbuilder Examples folder. And I have created a bot in My bots section, the ending point is: http://www.bigluntan.com:3978/api/messages. I have tested in Test connection to your bot section, it is working when I type something and send it. Right now, I want to give Direct Line a try. So I added Direct Line to Channels. But the most confused part is, how do I call this Direct Line api, cause the ending point is different than my bot's ending point.
The base URL is https://directline.botframework.com, so for instance, the POST request to get a new conversationId should be https://directline.botframework.com/api/conversations/
The request headers should include the Content-Type and also the following:
Authorization: BotConnector < Your secret >
where your secret is the code which was created when you created a Direct Line channel for your registered Bot (see image below). e.g.
Content-Type: application/json; charset=utf-8
Authorization: BotConnector pB7INWcXQjA.cwA.RF4.cglOUNHUOzWVv0Rlk3ovFNhtp1JPz1Zx9jmu8vX7zXs
Once you get a conversationId, you can POST a message using the URL https://directline.botframework.com/api/conversations/< conversationId >/messages
The body of the request should include the message text. You will not get the reply in the POST response. Instead, you need to get it by sending a GET to
https://directline.botframework.com/api/conversations/< conversationId >/messages. From there, you can get the "from" value in your first message, and use it in subsequent calls to the same conversation (otherwise the bot will not recognise the state, and just keep repeating the first reply message), e.g.
{
text: "yes",
from: "EQxvIzZOspA"
}
I found this out by trial and error. If you want to use the direct line api you should try https://directline.botframework.com
as the base URL