We cover things like this in our "Office Hours" webinars, held each Tuesday and Friday at 1pm Eastern time. To register: http://quickbase.com/webinars/
Hey Ryan - if the users are in Quick Base and logged in, it is up to your mail client/browser to retain the session. For example, I often click links from Outlook and remain logged into QB. If the users are't QB users... you can achieve this with a custom everyone on the internet (EOTI) implementation. You would first want to evaluate the risk internally of the type of data you are putting at risk but it can be done. The role needs to be managed carefully. Would look something like
The only attack vector here is someone maliciously adding records to the logs table. One way to reduce the opening there is using Custom Data Rules (CDR) to not allow the record to be added unless it has the necessary parameters passed in, like a "Related...". If you are really worried about the security, you could consider a staging application that is used for you to write the approval/rejection records to, kind of like a message queue. From there, an Automation or Webhook could push the data to production. This approach will reduce the attack possibilities by a wide margin since EOTI won't exist in your main app.You'll want to stay away from approaches that suggest embedding authentication in the button because these are easily compromised. If you need more customization, you could put a small server-side script into the process here that authenticates with an intranet, IP filtering, or something similar and have your script manage the API calls to Quick Base.Hope this helps.