How to authorize an AJAX update in a recall dashboard

Consider a dashboard where a staff member marks a recipient as contacted. The browser sends an asynchronous request containing the recipient record identifier and the proposed status. Those values describe the requested change; they do not establish that the person sending it has permission to make it.

The server should first validate the user's session or other authentication credentials. It should then load the relevant record within the user's permitted scope and check whether that user can change contact status for the associated campaign. Checking a general staff role alone is insufficient when staff members have access to different campaigns or organizations.

Validate the proposed change as well as the user's permission. Accept only supported status values, reject unexpected fields, and enforce any required transition rules. For example, a delivery failure should not automatically become a confirmed receipt merely because a request supplies that value. When authentication relies on cookies sent automatically by the browser, state-changing requests also need appropriate protection against cross-site request forgery.

Return a clear result that the interface can handle. An expired session should prompt authentication, while insufficient permission should leave the record unchanged and explain that the action is unavailable. Choose a consistent policy for inaccessible records so error responses do not unnecessarily reveal whether those records exist.

Finally, account for retries and simultaneous edits. A disabled button can reduce accidental clicks, but server-side duplicate handling or version checks may still be needed. Record the actor, time, affected record, and meaningful change in an audit trail, while keeping credentials and unnecessary personal information out of logs.