I am trying to use the "Send an email" on the office365 connector.
I am trying to send an email with a binary attachement. When i receive the email the content appears to be Base64 encoded. In order for my file to work, the content should not the raw binary payload.
How do i avoid the base64 encoding? I tried removing the base64 part: #{base64(body('binaryStuff'))} in the code, but that caused my app to fail, with a "BadRequest" message.
How do i send a binary attachement in my logic app?
After letting the function return Base64 string of the mail attachment instead of byte[], the logic app seems to be able to figure out that the contents is encoded.
Related
I'm trying to upload files from incoming e-mails to DevOps using the logic app's connector "HTTP request to Azure DevOps", to than attach them to a Work Item.
The flow works, but the files I attach results in base64 encoded form if I upload them in base64, and messed up binaries if I upload them in binary format.
Anyway, them are unusable.
Is there a way to correctly upload files to DevOps?
(docx, xlsx, pdf, images, and so on?)
I tried to upload files in base64 form and binary form with "HTTP request to Azure DevOps" but I can't get the file content correctly after the upload.
I'm expecting to download the correct file from the url property outputted from "HTTP request to Azure DevOps".
Solved putting
"Body": "#{binary(body('Get_Attachment_(V2)')?['contentBytes'])}"
as body :-)
The function to use is actually binary() and not base64().
however "Body is Base64" has to be set to true.
As per the API documentation here I formed my request with postman as follows:
. This is working fine.
But when it comes to binary content(encoded in base64 format), it uploads the file but that is not previewed when I try to open the same on OneDrive.
File gets uploaded successfully but not previewable.
What am I missing here? Any suggestions?
OneDrive doesn't support Content-Transfer-Encoding when using the multi-part upload method. In this case, we're ignoring the header (that seems like a bug) and just storing the base64 encoded data in the file stream (without decoding it).
You'll have to upload the raw bytes as the second part of the request, without any content-transfer-encoding, to have this work.
Since it seems like you are just uploading a file and not trying to set any custom metadata while doing it, you're better off using one of the other upload methods, like PUT or createUploadSession
Drive does not store the image in the base64 format it stores it in binary. you can directly select the image using postman and can upload as binary with the multipart request
Here is the link for adding blob in the postman
How to upload images using postman to azure blob storage
I'm pulling some mail from the Gmail API. I've got some sample body text here. This is after base-64 decoding. This is the body of a sample email from my inbox.
Mobile Web Developer - new
Moovweb
http://www.glassdoor.com/partner/jobListing.htm?pos=101&ao=77320&s=224&guid=00000152113cfb4fa8f086376239205e&src=GD_JOB_AD&t=JA&extid=13&exst=O&ist=&ast=O&vt=e&ja=23120341&uido=50A7E22F0FAE3A77415539AAADB05038&slr=false&cb=1451988155901&jobListingId=1579397251&utm_medium=email&utm_source=jobalert&utm_campaign=jobAlertAlert&utm_content=ja-viewjob&encryptedUserId=50A7E22F0FAE3A77415539AAADB05038
Web Developer - new
Applied Systems
http://www.glassdoor.com/partner/jobListing.htmÃœÃLL‰˜[ÃMŒŽIÅ“ÃLŒ￾ â„¢ÃZYLMLÅ’LLØÙ˜￾˜NÅ’
Å’ÃÃÅ’Å’ÃŽLÅ’
YIœÜ˜ÃQÑғ×ÃQ ￾R￾Iâ„¢^YLLÉ™^ÃSÉš\ÃIËœ\ÃSÉ￾￾YIÅ¡ËœOLÅ’ÃŒLÅ’ÃI￾ZYÃMLMÑLŒ‘Œ￾QLÃMÃÃMMLÃŽPPPQÅ’
LÎ œÛ￾Y˜[ÙI˜Ø￾LM
LNNMMNLŽIš›Ø“\Ã[™ÒYLMLN
LŽ
As you can see, after base-64 decoding it, part of it is decoded correctly, such as the title nad the url. The garbage bellow is the content that was originally html and css, I believe, so it makes sense that it would have been encoded differently on Google's side. Does anyone know what encoding this is?
I've tried:
`mb_convert_encoding($body_string, "UTF-8", "Windows-1252");`
and
`mb_convert_encoding($body_string, "UTF-8", "ISO-8859-1");`
With no luck.
We send out password-reset emails to business partners who use our intranet. The body of the email contains a hyperlink:
`http://www.ourdomain.com/ResetPassword.aspx?token=....`
But some of the people who receive these emails are saying there's an extra dot in the domain name:
`http://www.ourdomain..com/ResetPassword.aspx?token=....`
I do not see where that could be happening in the program I've written. I store the base url in the web.config:
`http://www.ourdomain.com`
and attach the name of the aspx page and append the token to it.
Are there any corporate anti-virus programs out there which deliberately mangle hyperlinks discovered in the body of emails, to render them invalid and thus unclickable?
This seems to be per the spec of quoted-printable encoding. It just so happens that the length of text in the message breaks to a new line right at the .com (72 characters maybe?). Please verify that this is the case by sending yourself a message and analyzing the quoted-printable source of the message.
System.Net.Mail creating invalid emails and eml files? Inserting extra dots in host names
The solution would be to not use quoted-printable encoding if some email programs cannot correctly interpret the spec.
plainText.TransferEncoding = System.Net.Mime.TransferEncoding.SevenBit;
//or base64
I'm trying to send a JPG attachment with a formatted HTML message. Of course I'm using [picker setMessageBody:emailBody isHTML:YES];
The rest of the code is what it is supposed to be, according to various messages on forums.
What I observe: the contents of the resulting e-mail message depends on the configured e-mail account on your iPhone.
E.g.: for a Yahoo mail account, setting isHTML to YES never results in an HTML message, but setting it to NO does! Bug in Apple stuff?
But, for a GMail account, I've never succeeded to send an HTML mail, it is always received as plain text.
The JPG file is sometimes shown inline, sometimes as an attachment.
All I want: send a JPG file, and a message containing some line breaks. Does anybody have some proven code that does just that, working for all kinds of e-mail accounts?
Even if you set isHTML param to YES, your message body can be sent as plain/text if the message body can be represented as such. And attachments in plain/text messages are not always recognized correctly by some email clients (Outlook).
In my case adding a link in the message body helped. Formatting text as bold with HTML tags works too. Tricky!
Tested on iPod 1G 3.1.3.