How can you replace the single-use access tokens in an action-xhr header without using amp-bind?

Question

Problem

How is it possible to insert a new token (that's returned in the response) into the action-xhr , if we can't use amp-bind ?

Background

From the Gmail markup docs on Limited Use Access Tokens , requests should be signed with an object ID and a unique token.

http://www.example.com/approve?requestId=123&accessToken=xyz

This combination of id + token should be used once. The docs state:

Once this request gets through, any future request with the same id and access token should be rejected too

After completing a successful request, we need to create a new token for a subsequent write.

However, the AMP for Email docs indicate that we can't change the action-xhr for a <form> tag:

The src attribute of amp-list, action-xhr of amp-form, the src for amp-img, or the href attribute of an tag cannot be mutated by amp-bind.

Answer 1

Limited Use Access Tokens is for the Email Markup feature, which is unrelated to AMP for Email. The documentation recommends rejecting "future request with the same id and access token" probably due to the nature of the One Click Actions feature, where the actions rendered from the markup are mostly one-time action that shouldn't be done repeatedly:

ConfirmAction can only be interacted with once.

https://developers.google.com/gmail/markup/reference/one-click-action#confirm_action

SaveAction can only be interacted with once.

https://developers.google.com/gmail/markup/reference/one-click-action#save_action

This is in contrast to the Go-To Actions feature, where the action can be done multiple times, although obviously only recommended for a simple link without any mutation of states.

There's no such universal recommendation for AMP for Email. It's up to the email sender whether certain actions will be rejected after the first success or can be done repeatedly. You are right that the AMP for Email format doesn't even allow generating dynamic access tokens from within the email, so if the email sender rejects the request after the first success, the sender should probably render some kind of error message (eg, by using a <div submit-error> element under amp-form ) if the user tries to perform some action for a second time. The access token should be hardcoded in the URL of the original email payload. It should still be for limited use by expiring it after 30 days or less.