Automatic post-registration user authentication

Question

Symfony 4.0

This process hasn't changed from Symfony 3 to 4 but here is an example using the newly recommended AbstractController. Both the security.token_storage and the session services are registered in the parent getSubscribedServices method so you don't have to add those in your controller.

use Symfony\Component\Security\Core\Authentication\Token\UsernamePasswordToken;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use YourNameSpace\UserBundle\Entity\User;

class LoginController extends AbstractController{

    public function registerAction()
    {    
        $user = //Handle getting or creating the user entity likely with a posted form
        $token = new UsernamePasswordToken($user, null, 'main', $user->getRoles());
        $this->container->get('security.token_storage')->setToken($token);
        $this->container->get('session')->set('_security_main', serialize($token));
        // The user is now logged in, you can redirect or do whatever.
    }

}

Symfony 2.6.x - Symfony 3.0.x

As of Symfony 2.6 security.context is deprecated in favor of security.token_storage. The controller can now simply be:

use Symfony\Component\Security\Core\Authentication\Token\UsernamePasswordToken;
use Symfony\Bundle\FrameworkBundle\Controller\Controller;
use YourNameSpace\UserBundle\Entity\User;

class LoginController extends Controller{

    public function registerAction()
    {    
        $user = //Handle getting or creating the user entity likely with a posted form
        $token = new UsernamePasswordToken($user, null, 'main', $user->getRoles());
        $this->get('security.token_storage')->setToken($token);
        $this->get('session')->set('_security_main', serialize($token));
    }

}

While this is deprecated you can still use security.context as it has been made to be backward compatible. Just be ready to update it for Symfony 3.

You can read more about the 2.6 changes for security here: https://github.com/symfony/symfony/blob/2.6/UPGRADE-2.6.md

Symfony 2.3.x

To accomplish this in Symfony 2.3 you can no longer just set the token in the security context. You also need to save the token to the session.

Assuming a security file with a firewall like:

// app/config/security.yml
security:
    firewalls:
        main:
            //firewall settings here

And a controller action similar to:

use Symfony\Component\Security\Core\Authentication\Token\UsernamePasswordToken;
use Symfony\Bundle\FrameworkBundle\Controller\Controller;
use YourNameSpace\UserBundle\Entity\User;

class LoginController extends Controller{

    public function registerAction()
    {    
        $user = //Handle getting or creating the user entity likely with a posted form
        $token = new UsernamePasswordToken($user, null, 'main', $user->getRoles());
        $this->get('security.context')->setToken($token);
        $this->get('session')->set('_security_main',serialize($token));
        //Now you can redirect where ever you need and the user will be logged in
    }

}

For the token creation you will want to create a UsernamePasswordToken. This accepts 4 parameters: User Entity, User Credentials, Firewall Name, User Roles. You don't need to provide the user credentials for the token to be valid.

I'm not 100% sure that setting the token on the security.context is necessary if you are just going to redirect right away. But it doesn't seem to hurt so I have left it.

Then the important part, setting the session variable. The variables naming convention is _security_ followed by your firewall name, in this case main making _security_main.

Figured this one out, finally.

After user registration, you should have access to an object instanceof whatever you've set as your user entity in your provider configuration. The solution is to create a new token with that user entity and pass it into the security context. Here's an example based on my setup:

RegistrationController.php:

$token = new UsernamePasswordToken($userEntity, null, 'main', array('ROLE_USER'));
$this->get('security.context')->setToken($token);

Where main is the name of the firewall for your application (thanks, @Joe). That's really all there is to it; the system now considers your user fully logged in as the user they've just created.

EDIT: Per @Miquel's comment, I've updated the controller code sample to include a sensible default role for a new user (though obviously this can be adjusted according to your application's specific needs).

If you have a UserInterface object (and that should be the case most of the time) you might want to use the getRoles function that it implements for the last argument. So if you create a function logUser, it should looks like that:

public function logUser(UserInterface $user) {
    $token = new UsernamePasswordToken($user, null, 'main', $user->getRoles());
    $this->container->get('security.context')->setToken($token);
}

I'm using Symfony 2.2 and my experience was slightly different than Problematic's, so this is a combined version of all the info from this question plus some of my own.

I think Joe is wrong about the value of $providerKey, the third parameter to the UsernamePasswordToken constructor. It's supposed to be the key of an authentication (not user) provider. It's used by the authentication system to distinguish between tokens created for different providers. Any provider which descends from UserAuthenticationProvider will only authenticate tokens whose provider key matches its own. For example, the UsernamePasswordFormAuthenticationListener sets the key of the token it creates to match that of its corresponding DaoAuthenticationProvider. That lets a single firewall have multiple username+password providers without them stepping on each other. We therefore need to choose a key that won't conflict with any other providers. I use 'new_user'.

I have a few systems in other parts of my application that depend on the authentication success event, and that isn't fired by just setting the token on the context. I had to get the EventDispatcher from the container and fire the event manually. I decided against also firing an interactive login event because we're authenticating the user implicitly, not in response to an explicit login request.

use Symfony\Component\Security\Core\Authentication\Token\UsernamePasswordToken;
use Symfony\Component\Security\Core\AuthenticationEvents;
use Symfony\Component\Security\Core\Event\AuthenticationEvent;

$user = // get a Symfony user instance somehow
$token = new UsernamePasswordToken(
        $user, null, 'new_user', $user->getRoles() );
$this->get( 'security.context' )->setToken( $token );
$this->get( 'event_dispatcher' )->dispatch(
        AuthenticationEvents::AUTHENTICATION_SUCCESS,
        new AuthenticationEvent( $token ) );

Note that use of $this->get( .. ) assumes the snippet is in a controller method. If you're using the code somewhere else you'll have to change those to call ContainerInterface::get( ... ) in a way appropriate to the environment. As it happens my user entities implement UserInterface so I can use them directly with the token. If yours don't you'll have to find a way to convert them to UserInterface instances.

That code works, but I feel like it's hacking around Symfony's authentication architecture rather than working with it. It would probably be more correct to implement a new authentication provider with its own token class rather than hijacking the UsernamePasswordToken. Also, using a proper provider would mean that the events were handled for you.

With Symfony 4.4, you can simply do the following in your controller method (see from the Symfony documentation: https://symfony.com/doc/current/security/guard_authentication.html#manually-authenticating-a-user):

// src/Controller/RegistrationController.php
// ...

use App\Security\LoginFormAuthenticator;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\Security\Guard\GuardAuthenticatorHandler;

class RegistrationController extends AbstractController
{
    public function register(LoginFormAuthenticator $authenticator, GuardAuthenticatorHandler $guardHandler, Request $request)
    {
        // ...

        // after validating the user and saving them to the database
        // authenticate the user and use onAuthenticationSuccess on the authenticator
        return $guardHandler->authenticateUserAndHandleSuccess(
            $user,          // the User object you just created
            $request,
            $authenticator, // authenticator whose onAuthenticationSuccess you want to use
            'main'          // the name of your firewall in security.yaml
        );
    }
}

One important thing, make sure your firewall is not set to lazy. If it is, the token will never be stored in the session and you will never get logged in.

firewalls:
    main:
        anonymous: ~ # this and not 'lazy'

In case anyone has the same follow-on question which kept me coming back to here:

Calling

$this->container->get('security.context')->setToken($token); 

only effects the current security.context for the route used.

I.e. you can only log in a user from a url within the firewall's control.

(Add an exception for the route if needed - IS_AUTHENTICATED_ANONYMOUSLY)

As Problematic here already mentioned, this elusive $providerKey parameter is in reality nothing more than the name of your firewall rule, 'foobar' in the case of the example below.

firewalls:
    foobar:
        pattern:    /foo/