NetTalk Central

Author Topic: Approve Button in Email  (Read 1723 times)

kevin plummer

  • Hero Member
  • *****
  • Posts: 1195
    • View Profile
    • Production Accounting and Software Payroll
Approve Button in Email
« on: March 10, 2015, 05:20:41 PM »
Hi All,

I have a request that instead of logging into my web app a user wants to get an Email with an approve and reject button and be able to press either.

So on my web server I have created a form that takes 4 parameters (which are encrypted and base64 encoded).

In the HTML email buttons, is it as simple as just adding my url, form, and parameters? I presume this will open a browser which could be painful on a mobile device as you would need to re-open your emails after every approve or reject.

Am I on the right path or is there a better way of doing this?

Cheers,

Kevin

Bruce

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 11183
    • View Profile
Re: Approve Button in Email
« Reply #1 on: March 10, 2015, 10:04:38 PM »
Hi Kevin,

>> In the HTML email buttons, is it as simple as just adding my url, form, and parameters?

yes, but....

>>  to get an Email with an approve and reject button

most email clients will not allow you to have a button in an email. Too much phishing and spam etc. They require the user to be abls to see the link, in full, before they press it. So most will flag, or hide, emails that have buttons which hide the URL or links which don't show the whole URL.

>> So on my web server I have created a form that takes 4 parameters (which are encrypted and base64 encoded).

A slightly different approach is to create a table on the server side which contains,
a) a random unique ID
b) the 4 parameters (don't need to be encrypted)
c) a date & time field
d) a "status" field.

the status field is there so you can limit the link to "only working once".

the date and time are there so you can limit the link to some period of time. Old records can be cleaned out from time to time.

the random ID is there because that's all you then need to pass in the link. The form can use the random ID to fetch the record from your table, and populate the form based on the values in the table. This has the _big_ advantage of not allowing the client to specify them - and hence is more secure. Also with just the random ID the URL is much "friendlier". A 4 character random string would suffice (it would be easy to make sure the generated one is unique at generation time.)

Cheers
Bruce