Have you ever had a bug you couldn't reproduce? Nope, me either. Of course we have! The worst is when a user reports a bug in their account... which would be really easy to verify and debug... if only we could log and see what they're seeing.
Look, we've got too much work to do to debug this the hard way. We need to be able switch to that user's account: we need to impersonate them.
Setting up impersonation is super easy. In
security.yml, under your firewall,
add a new key called
switch_user set to
~ to activate the system:
|... lines 1 - 2|
|... lines 4 - 14|
|... lines 16 - 20|
|... lines 22 - 28|
|... lines 30 - 40|
Now, on any URL, you can add
?_switch_user= and then the username of whoever
you want to log in as. In our case, we want to login as firstname.lastname@example.org. Why
is that the email address in our case? This actually goes back to your user provider.
We're using the built-in
entity user provider, and we told it that we want to
identify by the
Hit enter to try switching users. OMG - access denied!
That makes sense - we can't just let anybody do this impersonation trick. Internally,
this feature checks for a very specific role called
we don't have that.
Hey, no problem! Let's give this role to
|... lines 1 - 2|
|... lines 4 - 6|
|ROLE_ADMIN: [ROLE_MANAGE_GENUS, ROLE_ALLOWED_TO_SWITCH]|
|... lines 9 - 40|
Cool! Try it out. It works! I mean, it doesn't work! Hmm, but it's not that security
error anymore - it just can't find the user:
weaverryan email@example.com You know what?
This is the because of the
+ sign in the email addresses - which represents a
space in URLs. Change that to the url-encoded plus sign:
Boom! Now we're surfing as
firstname.lastname@example.org. Pretty awesome. Once you're
done, go back by adding
?_switch_user=_exit to any URL. That's it! We're back
as our original user.
Switching users... yea, it's my favorite.