1

Original post:

This web application sends out emails which contain a link to a URL.

Correction-Clarification 9/17/2014:

An .EXE running as a scheduled task on a server (in "support" of the web app and connecting to same database) sends out emails which contain a link to a URL. The nature of the email content is essentially a "reminder"; the link when clicked is essentially an acknowledgement signaling "done".

Resumption of original post follows:

Clicking the link in the email does 2 things at the target .ASPX page:

  1. the page logic updates a database and sends another email to the same user
  2. the page finishes by displaying a "success" message in the browser

Would it be bad design to eliminate the success message sent by the browser?

I'm thinking the opening of the web page just to announce "success" is not needed. If the target URL were replaced with something with no user interface (e.g. HTTPHandler, webservice) then I'm thinking the email sent back to the same user confirming "success" would be adequate.

Yet, part of that approach "feels awkward", I guess because normally clicking on links in emails causes web pages to open. Given these requirements, would this be bad design to eliminate the browser?

UPDATE - 10-17-2014:

see: Submit to HttpHandler results in RequestType GET instead of POST

Community
  • 1
  • 1
John Adams
  • 4,773
  • 25
  • 91
  • 131

1 Answers1

1

update below

Actually, it's bad design to have a state change occur based on a GET request. A number of email systems (and virus scanning software) will follow the link in order to determine whether it should be quarantined or not.

Never mind that a GET request causing a change in state is pretty much against how the web is supposed to work anyway.

What should happen is they click the link, then the mail program opens the browser. You then show a page asking them to confirm the action by clicking a button. That buttons makes a POST request which you then act on.

Finally, I'm not entirely sure how you would eliminate the browser anyway. The mail program detects that it's a link and opens the browser once the user clicks on it. This is no different than how things like opening word documents or zip files. The email program just asks the OS what program is supposed to handle the action and passes it off to that program.

With your update, I think there's a much cleaner way. However this is dependent on the capabilities of the email client that'll be receiving the messages. Should be good for the vast majority of them.

In the body of the email, instead of sending a link, include an HTML form that contains a button which performs a postback to your server. See this ( link ) for samples of how some other companies have done it.

This way the action is a single step instead of two AND you aren't doing things the Wrong Way(tm).

NotMe
  • 87,343
  • 27
  • 171
  • 245
  • Thanks, Chris. I clarified my question above. I could insert a page with a button and convert the original querystring parms in the clicked URL to hidden form variables and POST the webserver when the button is clicked. There is a "randomID" in the querystring data that has to match a column in the database table row to be updated. Would insertion of a button to effect a POST be sufficient to eliminate the "quarantine" issue and implied security concerns? Is there any other technique to accomplish this user feedback to the server? – John Adams Sep 18 '14 at 03:01