| 5 | | As mentioned in [https://core.trac.wordpress.org/timeline?from=2017-04-12T16%3A59%3A59Z&precision=second a previous comment], I'm not sure if it's a good idea to roll this into the Heartbeat API. The API client might be a better place for it. [https://github.com/WordPress/gutenberg/pull/3006#issuecomment-337164660 A possible approach] could be to create [https://core.trac.wordpress.org/timeline?from=2016-08-04T12%3A17%3A50Z&precision=second a separate endpoint] for cookie auth only, either on the REST API root, or admin-ajax.php. I feel that setting it on the root would make it more official for other clients to adopt. With this endpoint, the client could get a new nonce if a request fails because of an invalid nonce. No need for Heartbeat. With this new nonce, the client should resend the same request (as if nothing happened). To the user of this API, the resolution of the promise will just take a bit longer, but it doesn't need to do anything. |
| | 5 | As mentioned in [https://core.trac.wordpress.org/ticket/37569#comment:11 a previous comment], I'm not sure if it's a good idea to roll this into the Heartbeat API. The API client might be a better place for it. [https://github.com/WordPress/gutenberg/pull/3006#issuecomment-337164660 A possible approach] could be to create [https://core.trac.wordpress.org/ticket/37569#comment:2 a separate endpoint] for cookie auth only, either on the REST API root, or admin-ajax.php. I feel that setting it on the root would make it more official for other clients to adopt. With this endpoint, the client could get a new nonce if a request fails because of an invalid nonce. No need for Heartbeat. With this new nonce, the client should resend the same request (as if nothing happened). To the user of this API, the resolution of the promise will just take a bit longer, but it doesn't need to do anything. |