Develop Reference

HTML5 How to open the default email program without composing a new message

I know you can have someone open their local email application (like 'mail.app' on mac or outlook on windows) and compose a new message with the following
window.location.href = "mailto:mail#domain.com";
I was wondering if it is possible to open the local email application without also composing a new message?
The use-case is, after registration, people need to check their email to confirm their account. I do not need them to send a message.
UX notes outside the scope of this question
I do not force a redirect, but rather I have a 'check my email' and 'skip' button after logging in. I have coded, that 'if the email contains gmail.com' to redirect to mail.google.com, but there is no way to exhaustively hard-code all possible email addresses and to which url they should be redirected? therefore if the email address is not any of the major ones, I would like to opt to open the user's local email client (without composing an email message) - if this is possible.

This isn't possible from a technical perspective. There's no mechanism provided for it via JavaScript. The browser simply doesn't have that kind of permission to open a desktop app, and nor should it.
It may open a mail client specifically using the "mailto:" protocol for the single purpose of pasting the email address from the mailto link into the user's default mail client. Similarly, other protocols may (optionally) be matched to certain applications (e.g. tel: to start a phone call) on the device, but again only a very specific action can be carried out. It's not possible to simply open any arbitrary desktop application with no specific purpose in mind, no mechanism exists for it.

Any way to populate email body with Javascript?

I'm familiar with the limits and uses of the mailto link. It's pretty handy, but of course, my client would like to manipulate the body more than plain text will accommodate.
I've seen questions like this one: Send HTML code to Body of email application
But I want to expand on it. I can restrict my users to iPad and Outlook 2016+. So I wanted to know if there is a way to directly interact with apple mail and Outlook from a web app to generate a "pretty" email. I can detect if user is on iPad or not and run disparate code if needed for the two platforms.
I can even entertain throwing a server in the middle, but it's important that email ultimately opens on the client for additional personalization.
Thanks,
Wayne

How to check a web page request came from user inbox

I have a web application which sends a download link to subscribers. Subscribers are able to click the link from their inbox and get access to download a pdf document. It is fine but what I want is to allow the access to pdf document only when link is clicked from his inbox only. I mean if subscriber forwards this email to some one else or tries to paste the link in browser manually it should not work.

What you want is impossible.
Consider this situation: You email someone#example.com. They can view the email via:
a) Desktop mail client
b) Smartphone/tablet mail client
c) Webmail
All three will appear "different" to your server, depending on exactly which client they clicked on your link in. And if the user forwards the email to someone else, say otherperson#example.com, the EXACT same link will be in that person's mail file as well, and they can view it via the exact same options.
You MIGHT be able to extract a username or some other personally identifiable datum from the refer IF they used webmail and the webmail system is stupid enough to have webmail.example.com/readmail?userid=someone
But otherwise, no, you cannot assume anything about the incoming click, only that SOMEONE clicked on the link in SOME email.

There is no way to tell if a link was opened from an email client or if it was pasted into the address bar. There is no way to track if an email has been forwarded (webbug images in an HTML formatted email are blocked by most email clients).
If you want to limit who can download the file from your servers, then require that users login and then hope that none of them engage is password sharing.
Even that won't stop them redistributing the file directly.

Its not really possible to "protect" a link.
But if your web application require user to login, you can generate a unique link for each of your user, and require him to login before allowing download.
People will be less prone to share their login/password than a simple url.

I know this is an old question and I'm not sure why it was down-voted, but an idea occurred to me. If you put a common pixel tracker in your email with a token that identified the user and the email edition which, when requested, your server would note the time the email was opened and read (and successive reads). Then if the user clicks the link in the email, a token on the link identifies the same user and email edition. When the server receives this request it could compare it to the last time the matching tracking pixel was accessed. If the pixel was accessed within a few minutes before the link was requested, that implies that the email was opened and then the link was clicked.
If the user book marks the link and uses it the next day, there would be no recent tracking pixel history, which implies that the request was not from the inbox.
This would be easy to spoof, so it shouldn't be used for any kind of security concern. You wouldn't know if the email was forwarded to another person. Their email client would hit the tracking pixel as well.
Many email clients would block the pixel tracking for ever-increasing privacy concerns, so it isn't reliable.
If you're just looking for an indication of usage, this might work.

html: price listing based on email

I am building a website for a customer who may not be very computer literate. This person knows how to use email. How can I build a website (purely html, javascript) where he can email his latest prices and the website automatically updates itself. I dont think he would be literate enough to FTP file some where. Is it possible?
How to build a secure login page and redirect to order page using only javascript and html?
How to create secure administrative section on javascript/html only website?

I would advise you to create a nice admin web interface, and teach him how to use it. Or, agree some kind of Excel format for product prices, and teach the steps of uploading a csv file. Doing things by email would complicate things in my opinion.

As in the website receives the email as data input? That's probably not going to work very well. Also, if the client is as you imply, expect those emails to be poorly formatted, filled with typos, etc. It's not a very good data entry medium by any means.
The ideal solution would be to build an admin page into the website where the client can enter the information in as controlled a manner as possible, validating the information on the spot rather than through an email (would the server send a reply email for invalid data? that would get infuriating quickly). A simple and intuitive UI should be able to overcome any computer literacy issues he may have.

I don't think this can be done purely in HTML/Javascript. It would need a server component. You would have to set up some sort of POP3 or IMAP listener that polls a mail server for correctly formatted email then dumps that into a database to update the site. Certainly not trivial.
I would build an administration portion of the site to allow the customer to log in and enter the data...no matter how illiterate, they certainly can be trained. ;-)

You could make the mail your prices thing work by just regulary checking a specific mailbox (over POP3 for example).
But that's something you won't be able to do in only pure html / javascript (and consider this: you would also need to store the mailbox credentials in client side code then!)

Email is a store-and-forward, asynchronous transport. You can use it to transport:
plain text (the body of an email)
styled text (the html body of a MIME email)
attached files
But none of those options will work well in your use case. You'd have to try to parse the body of the email if you were looking in the body for update information. -- Bad idea
And if you're using email to transport ordered data such as csv or Excel files, uploading the files directly to the website would enable a much better user interface.
You shouldn't use Excel files either since it will be too complicated for your user--he'd need to get the column (field) names exactly right, the content cells would also need to be exactly right, etc. Eg I use an excel file for input on one of my systems and a constant problem is zip/postal codes since they look like numbers but can have significant leading zeroes. Few users know how to enter them...
Recommendation create a set of web forms in the administrative section of the website. Your customer will be happy and you'll be even happier due to lower volume of support calls.

Is javascripts access to a password fields value considered a security risk?

If it is good style and security to store passwords securely and properly, then shouldn't the same be for web pages that require a user to enter a password?
consider this example
<script>
function copy() {
var text = document.getElementsById('text');
var pass = document.getElementsById('pass');
text.value = pass.value;
}
</script>
<input type=text id=text>
<input type=password id=pass>
<button onclick="copy();">copy</button>
type something into the password box and click the copy button and voila, it is exposed to the world. However if you copy and paste from the password box then you will get useless data.
Consider the number of pieces of javascript that are included on your login page that are not controlled by you (analytics, pageflow trackers, hosted scripts in the cloud). Does it make sense for a web browser to prevent this sort of programmatic access to password fields and instead provide it's own password validation API?

This vulnerability is intrinsic to the [traditional implementation of] application level authentication, whereby the login/password pair has to be collected and transmitted over the wire. (And the web browser is not the only place where this secret is threatened).
A few safeguards at the level of the javascript hosts and/or of http are in place to prevent some of the danger you foresee, but anyway there's always the risk of code injection...
The bottom line is that if effective security is required you may consider alternative authentication methods, such as OS integrated security, other forms of challenge-based security, and also non-password based approaches (eg: captcha-like challenges showing series of photos, some of which are pre-learned by the person being authenticated.)

Does it make sense for a web browser to prevent this sort of programmatic access to password fields and instead provide it's own password validation API?
No. <input type="password"> is a convenience feature to not show text while you're typing it. It is not intended as any kind of security measure.
Everything inside the browser window is completely controlled by the web site. It could easily fake a password field, or sniff keypresses in the window, to circumvent any possible protection of .value for password fields. There is no way to reign this is, so there would be no point trying to disallow access to password fields.
What's more this would break several very useful features of password fields, like being able to have client-side-script check that you've typed a non-trivial password when signing up (and warn you about eg. using the same password as your username), or having a login system based on the client-side script hashing a password before sending it.
Consider the number of pieces of javascript that are included on your login page that are not controlled by you (analytics, pageflow trackers, hosted scripts in the cloud).
0, unless you're totally doing it wrong. You need to stop that.
Any script you include on your page has complete access to script your entire site. Hiding a typed password from a rogue script executing in your security context is utterly fruitless given that it could, say, drop an iframe into the document's innerHTML with the delete-account form in it, then fake a click on the submit button. Or log every keypress you make on the site.
If you include someone else's script on your page you are effectively giving them admin access, so you have better trust them. To put a tracker or advertising script on a site that has anything sensitive on it at all is an act of pathological optimism.
Yes, Stack Overflow includes a script from google-analytics.com. And yes, Google could, if they wanted to, include code in that script to make everyone edit all their answers to say “i like bottoms lol”, or make the admins delete everything. Maybe they won't, if they're in a good mood today. Are you feeling lucky?
i like bottoms lol

It wouldn't make any difference to have a validation API, since any malicious JavaScript in the page could simply listen to keystrokes and log the password as you type it into the field.
Online banking sites sometimes have interesting password mechanisms, such as asking for 2nd and the 7th character of your password to be entered via a select box (which makes it harder to capture).
Ultimately, it's the responsibility of the web developer to make sure that all privileged code (e.g. JavaScript in the document) is secure. It's the same when installing browser extensions, Greasemonkey scripts or desktop applications - you have to check it's from a trusted source.
You might want to use OpenID instead of a password field (as with StackOverflow itself). Not only is it one less password for the user to remember, but it also delegates security to a more specialised identity broker, which hopefully has the tightest security possible.

Consider the number of pieces of javascript that are included on your login page that are not controlled by you.
Why would you let anyone put JS on your login page that is not controlled by you?
You shoul have control over what is on your login page, so there is no reason the browser should intervene.

Cross domain JS access is already prohibited so that scripts outside of the domain of the login page have no access to your password field.

It's an interesting point but I feel that is the security of your web site is such that this becomes an issue then you won't be including any javascript that is outside of your control.
While I think that browsers providing a password validation API is a good idea, regardless of how you approach it, at some point some code outside your control, javascript or otherwise, is going to have access to the unencrypted password text. Where do you draw the line?

So we're supposed to prevent the client from writing javascript that exposes their own passwords? I don't see the problem here.
What would you do for web developers who want to be able to access the contents of a password field? It needs to be accessible.

Get your sensitive data away from JavaScript. I know people hate PHP, but believe me it's way more secure than JavaScript when it comes to forms.
$_POST['text'] salted, hashed and registered post, and use binary type for password in the database. Keep JavaScript as a client away from the server side; at least for sensitive data.