9

Currently, part of my application sends out emails to users reminding them of events or tasks. When clicking a MarkComplete link in the email client, an HTTP Get request is made to my ActionHandler.ashx (an HTTPHandler) where the QueryString parameters are inputs allowing for the update of the event/task. New emails are then emitted back to the client signalling completion. This works.

An unwanted side-effect of this HTTP GET to the handler is the launching of the browser (i.e. at this point, the opening of the browser is unneeded and a nuisance).

Premise: As I study up on the ASP.Net Web Api, I am thinking I might be able to refactor the small amount of code in my HTTPHandler into a PUT method in a Web API controller. My understanding is that this controller could respond with void return (HTTP status code 204) after doing the required processing described above.

Question: Can the above approach in a newly written PUT method in a Web API controller return 204 and will this prevent the browser from launching completely? I want the end-user to click the link in his first email and only get the newly constructed email message signaling "completion" (no browser at all here).

EDITs to clarify 22 May 2016:

  • I do NOT NEED "user interaction". Ideally, the user clicks and nothing happens to the user than a new "answering email" indicating successful completion of the task.
  • Option 2 listed in proposed answer below has already been tried unsuccessfully and some major email programs do not allow this - see: Submit to HttpHandler results in RequestType GET instead of POST
  • Please note the HTML email content currently emitted does NOT contain any HTML form tag(s) bracketing the link tags in the message.
  • Do I still indeed have NO options? I have read that HTTP PUT can process a querystring (I just don't know exactly how to do so yet...)
Community
  • 1
  • 1
John Adams
  • 4,773
  • 25
  • 91
  • 131

3 Answers3

5

Short answer: No.

If you need user interaction, then there is no way to execute an HTTP request from an Email client without opening the browser.

The majority of Email clients (web mails included) do not allows you to execute JavaScript code and thus you have no option on executing something in the background.

This means that you have two options:

  1. Create a link inside your Email that will result into a GET request to your web server (this is what you have already done). This, of course, results in the browser opening to that page.
  2. Create a HTML form inside your Email, with an hidden field containing your data, that will target a POST enabled endpoint inside your web server. This will also cause the web browser to be opened (and may also show a warning message in some scenarios), but lets you better handle what kind of data to send. BUT it appears that this approach is tightly bounded to the specific client behavior (e.g. Thunderbird turns every form submit into a GET request), so I do not believe it is doable.

Apart from those two options I believe you have no possibilities. The reason behind this is purely related to security: it would be very insecure if you could be able to execute JavaScript code inside an Email message.

The 204 Response

What you can do, is to turn the response of your endpoint into a 204 (like you proposed). Please note that this will also cause your browser to open but it will almost immediately close the tab that responded with a 204 (the exact behavior depends on the Email client and Web browser combination). I think this can easily be done even if you do not change your code base and keep using your ActionHandler.ashx, but if you want, is of course easily done in ASP.NET Web API by just returning void from an ActionMethod.

Regarding the PUT method:

In HTML forms only GET and POST are allowed methods, while any kind of <a href="... ">...</a> tag will always generate a GET request. This means that you will not be able to execute the PUT method inside an email message (no matter in which environment the email is read).

Community
  • 1
  • 1
Federico Dipuma
  • 17,655
  • 4
  • 39
  • 56
  • thanks for your thoughtful response. Please see my EDIT at bottom of original post. – John Adams May 22 '16 at 17:04
  • I saw your edit, and even after that my answer remains unchanged (apart from the HTML form option that appears to be bounded to the Email client specific behavior). When I say *user interaction* I mean exactly what you are asking: e.g. a user clicks on something. This *is* an interaction. Also I do not know where you read about the differences in `PUT` method, because query string parameters can be read from ANY request (`GET`, `POST`, `PUT`, `DELETE`, `WHATEVER`) because they are part of the URI. – Federico Dipuma May 22 '16 at 17:14
  • Regarding the querystring issue above, apparently I cannot access Request.Querystring("SomeKeyword") to parse values and need to use the FromURI attribute to break apart the querystring. If I can learn how to do that, I think I could try to port my HTTPhandler code to a webservice that returns HTTP status 204. – John Adams May 23 '16 at 20:17
  • Maybe you are looking for `Request.GetQueryNameValuePairs();` – Federico Dipuma May 23 '16 at 21:00
1

Having an action within an email needs to open a web browser. otherwise it would be a big security concern on the clients side. If this was an option this would open the door to spammers, and hacks to have an email where you click anywhere and automatically download an application (BIG SECURITY CONCERN).

There are other ways to handle this type of application, we use Text messaging as well as PDF forms that can reply to an application request, SharePoint will do this as long as the client is part of your infrastructure. Google is now doing this with with markup for a kind of RSVP and highlight emails but only works on clients that will look at the markup language and google with their apps. Most email clients will ignore markup and scripts in an email.I really do not know of anyone that does not have a cell phone in today's age, even my grandmother at 75 years of age has a cell phone. I would recommend using twilio and SignalR. another way would be to setup a few email accounts that your application will monitor, let say accept@yourdomain.com and deniy@yourdomain.com. Now when the client accepts it will send response to that email and your application can look at the email address in the header to mark that account, this also gives you records to look back on if there was a problem with the client.

As for the browser opening i do not believe this is a bad thing, This will send them back to your application and force them to see new information, events or tasks you have posted (Marketing).

pool pro
  • 2,084
  • 12
  • 21
  • Thank you for your response, Rich. If the href URL within the email msg points to webservice (that processes data on the webserver) and returns HTTP status 204, why would the browser need to be opened? One component of the application controls the "notification" email(s). The target of the link would be a webservice (that would process but would require no display). The end user would be "comforted" that a confirmation email would arrive shortly to the inbox of the email client. Your whole first paragraph sounds dire. In a way, you imply it is indeed possible but has a security smell about it. – John Adams May 23 '16 at 19:21
  • Also, I have taken a brief look at SignalR and I cannot see how it could respond to a clicked link in an email message. Perhaps you suggested it as an alternative to email? This would likely mean a massive rewrite of my application. – John Adams May 23 '16 at 19:56
  • sorry for the late reply, as for the browser opening, the browser sends the data. without the browser what program would send your data back to you. now you could do this through telnet, but that would mean all clients need telnet clients installed. – pool pro May 24 '16 at 05:31
  • Another option would be to create an App for windows and phone systems to alert the client. So many ways, but as you have your code set i can only recommend setting up email addresses to accept the return from the client and add logic to your application to read the email headers. as said so many correct ways to do this with out being non compliant to email regulations, – pool pro May 24 '16 at 05:31
  • With that said i never mind being redirected from email to my account information on a browser to accept or denied information on my account and that keeps the client records more updated as they will likely update any changes to their information if forced to login, if they never have to login the client information gets stale. Hope this helps you. – pool pro May 24 '16 at 05:32
  • Take a look at MailSystem.NET, Has great functionality and should be easy enough to add to your project to run in background to auto update your data from email recieved from accounts accept@yourdomain.com or reject@yourdomain.com. http://mailsystem.codeplex.com/ – pool pro May 24 '16 at 06:21
0

First of all in order to send any HTTP request regardless of the verb you use (GET, POST, PUT, DELETE, HEAD, etc.) you need an external program (browser, shell, etc.) to do that because email clients will not do this.

If you want to avoid using a Web Browser you can think on other ways to do it, for example configure the first email you sent to the user with a specific subject like: "Appointment Confirmation" and tell the user to reply this email as is, this will send you an email including the original subject you sent to the user, next you can configure your application to expect this kind of incoming emails and react upon this event by sending the second email. You will have even as much information of the user as you included in the first email, this can be used to configure the second email.

Georgggg
  • 564
  • 3
  • 7