Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Outlook.com now uses the BingPreview crawler to crawl links in emails.
This means that one-time login links send to outlook email addresses are marked as used/expired before the user gets the chance to use them, effectively locking them out of the site/their account.
BingPreview currently uses this user agent:
"Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534+ (KHTML, like Gecko) BingPreview/1.0b"
Comment | File | Size | Author |
---|---|---|---|
#34 | 2828034-nr-bot.txt | 169 bytes | needs-review-queue-bot |
#28 | 2828034-26-remove-reset-login-route.patch | 5.46 KB | gagarine |
#26 | 2828034-25-remove-reset-login-route.patch | 5.25 KB | gagarine |
#7 | interdiff-2828034-3-7.txt | 736 bytes | Jelle_S |
#7 | 2828034-7-fix-bingpreview-one-time-login-mail.patch | 1.01 KB | Jelle_S |
Issue fork drupal-2828034
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
Jelle_SComment #3
Jelle_SPatch returns access denied for BingPreview bot.
Comment #4
Jelle_SComment #6
daften CreditAttribution: daften at District09 commentedMaybe this can be enhanced with a deny for slack also? :)
Comment #7
Jelle_SComment #8
cilefen CreditAttribution: cilefen commentedDo these mail clients actually submit the confirmation form? I do not understand how execution could be in the code path that was patched.
Comment #9
Jelle_SHmm it seems we have altered that form to redirect straight to the /login path. Nevertheless it is still valid for slack and mail. Sometimes site admins send
drush uli
's to their devs or clients or whatnot. If you send in through mail or slack, the link will still get invalidatedComment #10
gagarine CreditAttribution: gagarine as a volunteer commentedIt seem I stumble on this issue using https://www.drupal.org/project/passwordless/issues/3062482 on D8.
Comment #11
Kristen PolWhile this code may work as desired, IMO it feels like the wrong approach to hardcode these. I think we need a different approach so this is configurable instead. I'll check in with the bugsmash team for additional thoughts.
Comment #12
quietone CreditAttribution: quietone as a volunteer commentedI think this should be 9.3.x
Comment #13
gagarine CreditAttribution: gagarine as a volunteer commentedAnother approach could be an intermediary page with a form with a button "reset my password"?
or is using
<a>
for links ==><a href="[user:one-time-direct-login-url]">click here to reset your password</a>
. Apparently outlook do not create link preview when they are proper HTML link.Perhaps adding a nofollow to this link?
Are we sure robots.txt is configured correctly to handle one time login?
Comment #14
cilefen CreditAttribution: cilefen commentedHold on, isn't that what #2515050: A valid one-time login link may be leaked by the referer header to 3rd parties does?
Comment #15
cilefen CreditAttribution: cilefen commentedI think this may be related to, and perhaps may be fixable by #3188375: Fix direct-login links (referer header leakage / UX) when already logged in.
Comment #16
roderikI welcome reviews to #3188375: Fix direct-login links (referer header leakage / UX) when already logged in but it won't solve this issue. It just fixes a confusion/security issue if
user/reset/UID/TIMESTAMP/HASH/login
is accessed while a user was already logged-in to the browser.#3097238 may, though.
It doesn't;
user/reset
is not present in robots.txt. #3097238: Protect initial login link against abuse and username leaking fixes that plus one other thing. Please review.Already exists.
user/reset/UID/TIMESTAMP/HASH
has a form.user/reset/UID/TIMESTAMP/HASH/login
directly logs users in.Core mails use a link to the form.
So, as far as I can tell right now, we might decide either of the following points:
.../login
links..../login
links openly. (Core never uses.../login
links. 'drush uli
' does print.../login
links on the terminal.)As an illustration here's blunt stub example responses to #9 - but again, these are invalid if we know the robots.txt change fixes everything:
We have two types of login links: "safe to spread" links, and "direct login (without button)" links. Don't conflate the two. Core only uses the first type in its mails.
Don't alter the form to log in directly. Invalidation is a direct result of that alteration. If you do, you're responsible for putting the "rel=nofollow" in mails (if that makes a difference).
Sending drush uli's through mail or slack should not be done. Chop off the "/login" part.
Comment #17
roderikComment #20
zcht CreditAttribution: zcht at TRENDKRAFT commentedFor me on the platform I tested a different approach, therefore also only now a feedback. Condition: over 4000 registered users with different email addresses, test period > 6 months, environment production, so far 100% worked with the created Shy One-Time module. The One Time Login links are no longer invalidated. Maybe you could implement this solution directly in Drupal itself. Test and feedback are welcome.
Comment #21
cilefen CreditAttribution: cilefen commentedThis is needs work for #11.
Comment #22
gagarine CreditAttribution: gagarine as a volunteer commentedI'm now convinced this should be marked has "work as designed". A link using a HTTP GET request should not modifies a resource (in that case, change user to active), period.
I think the route /user/reset/UID/TIMESTAMP/HASH/login should be deleted to avoid confusion. Even when you use drush you can click on a button. It's also a better UX.
Someone think HTTP GET request to modify a resource is a good idea? Is their a legitimate use case?
Comment #23
rgpublicNo, I also think this is bad design by Microsoft that this happens in the first place, but nevertheless, this problem is widespread enough to cause many people to think that the reset password feature doesn't work. We have now blocked these calls server-side but it's very difficult to get behind this and not everyone has the ability and experience to reconfigure their webserver. Many people were reporting that their one-time login links always seem to have already expired. The patch in #7 is a very simple solution with no likely side effects as it only kicks in when the UserAgent is BingPreview (and Slackbot). It should be considered to go in, IMHO.
Comment #24
rgpublicAh, perhaps I misunderstood you, @gagarine as I realize now. You mean we should remove the "/login" route altogether so you are always force to go via the form. Yes, if no one comes up with a valid use case, then why not? I wonder though: Why are you calling this solution "work as designed". It would still need a patch to remove that route, wouldn't it? IMO it'd be a valid fix and a change in the codebase.
Comment #25
gagarine CreditAttribution: gagarine as a volunteer commented@rbpublic yes, I mean remove the "/login" route altogether so you are always force to go via the form. You are right, "work as designed" was certainly inappropriate in this situation (even if it does works has designed, but people use the direct login when they should not).
We should also inform module maintainers that using direct link to login is never ok. See #3298635: Bingpreview/Slack preview invalidates one time login links
Comment #26
gagarine CreditAttribution: gagarine as a volunteer commentedA simple patch that remove the reset login route.
Comment #27
cilefen CreditAttribution: cilefen commentedCan we remove routes in minor releases?
Comment #28
gagarine CreditAttribution: gagarine as a volunteer commentedForget to remove unused use statement.
Comment #29
gagarine CreditAttribution: gagarine as a volunteer commentedIn that case I would say yes, because it's a major bug that is not possible to fix properly otherwise. It's also a very easy change. But others will certainly disagree.
Comment #30
gagarine CreditAttribution: gagarine as a volunteer commentedTheir was a much more test than anticipated...
I would be happy to clean all unused tests if the direction to remove the /login route is validated by the community and/or someone than can commit on the core.
Comment #31
zcht CreditAttribution: zcht at TRENDKRAFT commentedi would be in favor of adding this function as an option. some modules use the one time login link for authentication in the system itself. or another technical solution must be worked out for this, so that a login is possible without reconfirming the login on the site itself.
often the link is generated by drush uli and sent by email in the plan text, but is then invalidated by the bingbot.
i am primarily thinking about usability and user-friendly handling of the login process.
removing the route is a hard intrusion into the core, which has been working in this form for years. this could cause various other problems.
Comment #32
gagarine CreditAttribution: gagarine as a volunteer commentedDo we have an example of this?
In my experience people don't really understand the "auto login". It seem a much better UX to have a click on a "activate my account" button.
I agree it may be a bit hard for a minor version. But for Drupal 10 that would be a nice cleanup. So we mark the route and related function as deprecated already.
This issue is 7 years old now, someone with authority has to take a decision.
It's not only about a feature or not, it's about following the HTTP protocol or not => https://httpwg.org/specs/rfc7231.html#GET
Comment #34
needs-review-queue-bot CreditAttribution: needs-review-queue-bot as a volunteer commentedThe 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.
Comment #37
C-LogemannOne 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".
Comment #38
gagarine CreditAttribution: gagarine as a volunteer commented"this is a bug of the mail provider"
Seriously, Drupal community bring less and less value. Unfollow this issue, but I perhaps 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.
Comment #39
daften CreditAttribution: daften at Dropsolid commentedPutting 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
Comment #40
zcht CreditAttribution: zcht at TRENDKRAFT commentedSmall 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.
Comment #41
zcht CreditAttribution: zcht at TRENDKRAFT commentedA 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.