One-time password reset page should never be cached

Sounds sane, looks OK

Makes me wonder which of those issues we should consider as a backport for D7. Most don't make sense there, but this one might?

RTBC + 1

Given this is a legit bug fix, and it also is aiming to be backported to D7, let's get a test for this.

Added a test.

That test is for the wrong route.

This issue addresses a major bug and is allowed per https://www.drupal.org/core/beta-changes. Committed 9a0cea2 and pushed to 8.0.x. Thanks!

Patch for D7 attached.

This should use:

drupal_page_is_cacheable(FALSE);

instead of setting $conf directly ...

Made changes as suggested by #19.

#20: Can you upload the a test-only patch as well, please.

I want to make sure it fails ...

You likely will need to enable page cache for it to work though ...

I think this D7 part of this issue is no longer relevant, as the cache of the user_pass_reset() form was "turned off" in: #2803921: A valid one-time login link may be leaked by the referer header to 3rd parties

The form is not cached in browser:

$form['#action'] = url("user/reset/$uid/$timestamp/$session_reset_hash/login");
// Prevent the browser from storing this page so that the token will
// not be visible in the form action if the back button is used to
// revisit this page.
drupal_add_http_header('Cache-Control', 'no-store');

And it also does not have X-Drupal-Cache header, because the user has $_SESSION['pass_reset_hash'] set and thus Drupal is adding also $_COOKIE[session_name()] for that user, which causes the part where the X-Drupal-Cache header should be set to skip.

See: _drupal_bootstrap_page_cache()

// If there is no session cookie and cache is enabled (or forced), try
// to serve a cached page.
if (!isset($_COOKIE[session_name()]) && $cache_enabled) {

Verified also by manual testing that there is no X-Drupal-Cache header on that form at all. So I think this can be closed now as fixed in D8 and thats all.