Is Hotmail “clicking” your account confirmation links?

An interesting issue occurred regarding email registration with the FOSUserBundle when using Hotmail for account signups.

FOSUserBundle’s registration confirmation was enabled, so the user signing up would receive an email containing a link with a token used to verify and enable their account.

However, when clicking the verification link from any Hotmail email account, a 404 not found page was the result.

The NotFoundHttpException said:

The user with confirmation token “R_jrlvXPyi_qTb3kvbCE_x5Qka89SikV9F1FlL5xWU4” does not exist

There is information online regarding this FOSUserBundle error, but it all seems to relate to users accidentally clicking their link multiple times. In our case, the link was clicked once…and only once.

Checking the database, I could see that the account had been enabled successfully, and the verification token removed. This is exactly what you’d expect to see upon a successful account confirmation.

Looking back at the Hotmail email again, I noticed that it was including a link preview of our site in the email body (similar to what you see when sharing links on Facebook).

I realized that Hotmail was likely sending a bot to our verification link in order to create that preview.

Checking in the server logs confirmed it:

157.55.39.45 – – [30/Dec/2016:14:22:54 -0500] “GET /signup/confirm/R_jrlvXPyi_qTb3kvbCE_x5Qka89SikV9F1FlL5xWU4 HTTP/1.1” 302 4648 “-” “Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534+ (KHTML, like Gecko) BingPreview/1.0b”

A visit from their BingPreview crawler occurred the moment the email was opened.

Considering how FOSUserBundle is set up to work, this might cause some user confusion.

You see, the first time a confirmation link is visited successfully, FOSUserBundle enables the account, and removes the verification token from the database. Any attempts to visit the url again with that token will result in a 404 not found (as the token no longer exists in the database).

The user has no idea their account was already verified by the BingPreview crawler just by opening their email, and due to the 404 error page, will likely believe that something went wrong.

So, what can you do if you want to continue using FOSUserBundle with email verification?

One thing you could do is, set your .htaccess to block the BingPreview user agent from accessing your signup and password reset paths (Your paths may differ from this example):

RewriteEngine On
RewriteCond %{REQUEST_URI} /signup/confirm/ [OR]
RewriteCond %{REQUEST_URI} /resetting/reset/ 
RewriteCond %{HTTP_USER_AGENT} BingPreview
RewriteRule . - [F,L]

RewriteEngine On

RewriteCond %{REQUEST_URI} /signup/confirm/ [OR]

RewriteCond %{REQUEST_URI} /resetting/reset/

RewriteCond %{HTTP_USER_AGENT} BingPreview

RewriteRule . - [F,L]

This will stop the BingPreview crawler, but I feel like it is an incomplete solution. You can block as many annoying user agents here as you want, but do you really want to spend all your time hunting down which email providers are providing similar link previews in their emails?

Another thing you can do is to override the way FOSUserBundle handles account confirmation.

If you don’t know how to override FOSUserBundle controllers, read this article: Overriding Default FOSUserBundle Controllers

Once your bundle override is in place, you can do something like suggested by GitHub user dmaicher here in your RegistrationController.php: https://github.com/FriendsOfSymfony/FOSUserBundle/issues/2106#issuecomment-212027852

Make sure that you also use Symfony\Component\HttpKernel\Exception\NotFoundHttpException; in your file:

// src/MyCompany/UserBundle/Controller/RegistrationController.php

namespace MyCompany\UserBundle\Controller;

use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpKernel\Exception\NotFoundHttpException;
use FOS\UserBundle\Controller\RegistrationController as BaseController;

class RegistrationController extends BaseController
{

    /**
     * Redirect to login page when token confirmation fails.
     */
    public function confirmAction(Request $request, $token)
    {
        try {
            return parent::confirmAction($request, $token);
        } catch (NotFoundHttpException $e) {
            return $this->redirectToRoute('fos_user_security_login');
        }
    }

}

// src/MyCompany/UserBundle/Controller/RegistrationController.php

namespace MyCompany\UserBundle\Controller;

use Symfony\Component\HttpFoundation\Request;

use Symfony\Component\HttpKernel\Exception\NotFoundHttpException;

use FOS\UserBundle\Controller\RegistrationController as BaseController;

class RegistrationController extends BaseController

{

/**

* Redirect to login page when token confirmation fails.

public function confirmAction(Request $request, $token)

{

try {

return parent::confirmAction($request, $token);

} catch (NotFoundHttpException $e) {

return $this->redirectToRoute('fos_user_security_login');

}

In that example, if another email provider decides to start visiting your confirmation links, the users would at least be redirected to a login page rather than getting a confusing 404.

You can get creative with it, and I’ll post again if I come up with something better.

Would love to hear others’ opinions on this, and/or if you have had issues with this kind of behavior from email providers before.