I have a file available through an URL (need authorization). I created a mailto: link and would like to attach this file in the mail. How can I do that ?
Something like "mailto:toto#gmail.fr&attachment=site.com/file.pdf"
mailto: doesn't support attachments, but there are various ways you could achieve a similar effect:
Link to the file in a message body
You mentioned that the link needs authorisation, you could generate temporary urls that last 30 minutes (or more/less) which allow for downloads (users can then attach the file themselves)
Send the email yourself
Your service could send an email to your user (or on behalf of your user) with the attachment using something like Amazon SES, or Mailchimp, etc...
Render your PDF into HTML
It seems you are planning on attaching PDF files. Depending on the complexity of the PDF files, you could attempt to convert the PDF into email-friendly HTML using one of many tools, such as pdf2htmlEX or Pandoc.
If you're hoping for an universal solution, you can't. The mailto protocol described in the RFC 2368 tells us :
The creator of a mailto URL cannot expect the resolver of a URL to
understand more than the "subject" and "body" headers.
Even though other headers might be used and understood by some mail clients, this isn't an universally compatible solution. Unless you tell your clients to open these links specifically with a specific mail client that you know supports more headers (like a hypothetical attachment header), you should consider this to not be doable.
Related
I have a PDF like like this:
"http://centraldata.s3.amazonaws.com/.....pdf?AWSAccessKeyId=...."
which I get from an api call. Then I pass it into an link so that users can click and download it.
<a href={pdfUrl} />
So, my question is, is there a way to let user view the PDF without downloading it? Except passing the Url into an tag, I don't know if there is any other way to use this link
When you place a page of HTML in the Public Domain (World Wide Web) you are offering a service with Dis-positions (Download to later view this page after decoding download).
If you include images, text, audio, video or even a PDF via link, then you are offering to disposition a copy of the page content (be dispossessed of all with its content) from the server to the browser.
A web site can indicate to the browser that the download need not be viewed in the browser, (many browsers do not have a PDF viewer, or the browser may be secured to a safer setting such as Download Media ONLY) the HTTP response could include the html attachment headers:
Content-Type: application/pdf
Content-Disposition: attachment; filename="file.pdf"
A web site can indicate to the browser that the download need not be viewed in the browser, but there is a possibility if the user settings allow for inline viewing, (many browsers do not have a PDF viewer or it may be secured to a safer setting such as Download ONLY) the HTTP response should include the html attachment headers:
Content-Type: application/pdf
Content-Disposition: inline; filename="file.pdf"
To avoid problems with the text parsing of the optional filename (blob: or anything will be saved to filename at the discretion of the client dispossesser) then the proffered optional filename should be "double quoted".
User security settings should ideally be set to no-popups, like blanks, open secondary windows or target tabs, since those are unfriendly, anti-social server actions.
W3 Recommendation says
< a href="download-file.pdf" download >right click here for your options including view now< /a>
If you as my client have an inline PDF viewer active, here is an iframe should you wish to use it. (Your servant)
The next two related questions are
How can I stop that content I duplicated, from being duplicated as a copy by the client?, well clearly you cannot, since you willingly gave it away and once decrypted and decoded by the receiver it belongs to them as editable dis possessed content.
How can I mask the source URL ?, generally you can not since to decode the whole file and maintain it (if required) the sending caller ID must be maintained as an open comms channel during viewing. (Much like satellite download or Netflix recordings on demand.)
just use this
MyPDF
Describe the bug
The use of relative paths render broken links on the email recipient
The use of links from images on the web generate broken links on the email, except for the case that these links have a termination which explicitly names an image, with its type (jpg, etc), e.g src="http:://somelink....jpg"
To Reproduce
Relative path does not work:
<MjmlImage
width="400px"
src="./public/Book/Book.png"
></MjmlImage>
Only this kind of link that works:
<MjmlImage
width="400px"
src="https://image.shutterstock.com/image-photo/bright-spring-view-cameo-island-260nw-1048185397.jpg"
></MjmlImage>
Expected behavior
The image should show on the email of the recipient.
MJML environment (please complete the following information):
OS: Windows
MJML Version 4.7.1
MJML tool used: mjml-react 1.0.61
Email sending environment(for rendering issues):
Platform used to send the email: Gmail
Affected email clients (for rendering issues):
Email Client: Gmail
OS: Windows
Browser: Google Chrome
Screenshots
Additional context
I tried using this package and followed the steps for webpack on my next.config.js file (I am using NextJs) but it did not work also.
In the general case:
Relative addresses work on your system as you're developing your email.
Sadly, there's no way to send external files with your email. Hence, files you can find with relative addresses on your system are unlikely to be present on your recipient's system.
You'll want to put your files at Internet-reachable URLs and refer to them that way in your emails.
As you observed, that works well when you reference the entire path and filename, including the extension.
In your case:
The package you're using strives to be a way to send images with your email. Nifty. If it works, it hides lots of complexity.
I notice about that package that it hasn't been updated in two years or more. If it worked then, it'd be no surprise that it no longer works. Good luck!
Extras: Be careful with sending your email. Every email client I've heard about changes your HTML if you use cut-and-paste to put the HTML in their editor for sending. If they change your HTML, you're not sending what you thought you were sending. Bummer. The fix is to use an email service provider. Some are free for a limited number of emails sent. Pick one that doesn't change your HTML; some do!
You can test your HTML by pasting it into the free service https://putsmail.com (don't click the option to inline your CSS). They'll send the email to the email account of your choice and you can check it in the email client of your choice.
By the way, a great source of MJML support is https://slack.mjml.io/.
I have a PDF file as a blob object. I want to serve to my users, and right now I'm doing:
html = '<iframe src="' + URL.createURL(blob) + '">';
That works fine for people that want to use their in-browser PDF tool.
But...some people have their browser set to automatically download PDFs. For those people, the name of the downloaded file is some random string based on the blob URL. That's a bad experience for them.
I know I can also do:
<a href="blobURL" download="some-filename.pdf">
But that's a bad experience for the people who want to use in-browser PDF readers, since it forces them to download the file.
Is there a way to make everybody have good file names and to allow everybody to read the PDF the way they want to (in their browser or in their OS's reader)?
Thanks
At least looking at Google Chrome, if the user disables the PDF Viewer (using the option "Download PDF files instead of automatically opening them in Chrome") then window.navigator.plugins will show neither "Chromium PDF Plugin" nor "Chromium PDF Viewer". If the option is left at the default setting, the viewer will show in the plugin list.
Using this method, one can utilize window.navigator.plugins to check if any of the elements' names are either of the aforementioned plugins. Then, depending upon that result, either display a <iframe> or a <a href="blobUrl" download="file.pdf">. For other browsers I imagine that different methods would have to be used. You can also check for a "Acrobat Reader" plugin, which some machines may have instead, or even just the word "PDF".
On a side note, it does look like it is possible to detect if the default Firefox PDF viewer is enabled by using http://www.pinlady.net/PluginDetect/PDFjs/ .
Try to append &filename=thename.pdf to the binary, metadata or http header:
Content-Disposition: attachment; filename="thename.pdf"
I have looked through the documentation of createObjectURL(blob), it will always return a unique and specific format of url. It is not possible to change the URL here.
The plugin thing is not consistent across browsers.
Now here is my radical idea
Find or create(if not available) a js library that can create and save PDF files to server from blob. (I looked through some of them like 'jsPDF','pdfkit' but none of them use blob)
Save the file to server with a valid name
use the above name in the iframe.
I am attaching file in html web app using following code but it is not working
<div class="email_pot">
</div>
For attach file i use following procedure as it is given below
{
"toEmail": "ToAddressEmail"
,"toName": "ToAddressName"
,"subject": "SubjectLine"
,"body":"BodyText"
,"bodyHtml":"HTML Body Text"
,"attachments":["AttachmentPath","
AttachmentPath"],"titleColour":"Hex Colour (i.e.FF0000)"
}
So, what's your question? I will assume that you are getting some error when you tried to send the email. I have answered a very similar question before:
According to RFC 2368 you can't add an attachment to a message with the mailto: URL scheme due security reasons:
The user agent interpreting a mailto URL SHOULD choose not to create a message if any of the headers are considered dangerous (...) Only the Subject, Keywords, and Body headers are believed to be both safe and useful.
Whether you can put a file attached to an e-mail depends on the mailer.
(but many mailers can't add attachement file from maito:protocol)
I think I was able to put the attachments in some versions of Outlook, perhaps.
I want to let the user download the current content of a textarea into a text file on their computer. In the past I would create an iframe pointing to a URL with the data, which would trigger a file download dialog. However this time the data is client side.
So, is it possible to let the user download data without sending it server side?
If it does not need to work in "old browsers" like IE, you could open a new window with the location 'data:text/plain,' + yourTextarea.value. The user can then save that file using the File/Page menu or Ctrl+S.
is it possible to let the user download data without sending it server side?
In the general case no.
It is possible with a data: URL, as in janmoesen's answer (although you should be URL-encoding the value to include in the URL, or you may face corruption when a %nn sequence appears in the data).
However, this becomes impractical for very long data, and it's not available in old browsers or IE. (IE8 allows short data URLs to be used for images, but not direct navigation.) So whilst you can include a data-URL method to enhance the process on browsers that support it, you will still need a fallback solution of sending a formful of the data to the server side and having it spit back a file in response.
(For security reasons, this should only be allowed in a POST request, and the server should include Content-Disposition: attachment in the response. A content-echo script can give you cross-site-scripting problems otherwise.)
Check out how File and Blob types work.
You can create one and trigger a download programmaticaly:
https://www.bennadel.com/blog/3472-downloading-text-using-blobs-url-createobjecturl-and-the-anchor-download-attribute-in-javascript.htm
https://blog.logrocket.com/programmatic-file-downloads-in-the-browser-9a5186298d5c/