Bingpreview invalidates one time login links

The Needs Review Queue Bot → tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

One ore more mail service providers decided to "read" mails and follow links inside. This is a "bug" of this mail providers especially when they made this behavior default and didn't provide a switch for this. On Drupal it's a feature request to deal with such "mail services".

This issue is 7 years old now, someone with authority has to take a decision.

"this is a bug of the mail provider"

Seriously, Drupal community bring less and less value. Time for me to delete my D.O. account.

It's a critical issue that can lead to the impossibility for user to log-in. In the real world, nobody care if Microsft server "should" act differently.

But if we want to be theoretical: Drupal use a HTTP GET to change data witch is not how HTTP protocol is supposed to be work. A HTTP POST request should be used to change an account from blocked to active. It's a bug and a ugly one.

Putting this back to normal priority (see https://www.drupal.org/docs/develop/issues/fields-and-other-parts-of-an-... → .). No data is altered, a blocked user can't use the one-time-login link. As can be seen in e.g. \Drupal\user\Controller\UserController::determineErrorRedirect

Small update from my side: we currently have a problem that some users who use Microsoft Office 365 do not receive emails. Even with our additional module, which works well, this is not remedied. It seems that MS Office 365 has introduced new crawlers or ways of accessing the link.

However, it does not affect all MS Office 365 users, at the moment only 4... nevertheless, of course, it's obvious that these users can't log in.

In my eyes it is also a problem of Drupal.... you cant tell the email providers how to define their own services to access a, in comparison, small Drupal site, which you have released yourself. I am absolutely with @gagarine, and a feature request is definitely NOT.

perspective, i think something should be done actively on the Drupal side. more and more services crawl all links, whether it's microsoft, slack or other services. That's the future right now and if we don't change something, you're going to exclude users from Drupal who can't log in.

A small update, the " Shy One Time → " module has been updated to version 2.x. Via the Drupal state API you can now block unwanted user agents that access the route 'user.reset'. The users I mentioned in comment 40 can now log in without problems.