With Symfony2 the firewall comes with a built in feature: impersonate a user. We’ve been using impersonation as an admin tool for about 5 years as it is very effective for troubleshooting. When a user files a support ticket saying something isn’t showing properly to them or they are getting random errors it is very easy to just quickly switch to that user and see what they are seeing. As with all features, this one may not be appropriate for your application if your user expects no administrative staff to have access to his or her account.
While Symfony’s built in impersonation feature is a great step up from having to build it by hand, it still can be a bit more friendly. We’ve seen two additional functions we wanted the impersonation to handle. First, we wanted it to on exit from impersonating the user returns the user to where the user first started to impersonating. Currently it just brings you back to wherever you link the user. Second, if already impersonating a user and trying to start to impersonate another, we didn’t want it to throw an error but to quietly switch you. This functionality could lead to unwanted circumstances if an impersonating user believes they can impersonate another user, and then slowly just keep exiting impersonation of each user and go back up the chain they went down. However, in our situation the time admins hit this was when they’d impersonate one user, realize they clicked the wrong one, click back and try to impersonate a different user. As the browser uses it’s cached page when the user hits back they see the list of users as if they were an admin and can click on the correct user. If they do this they are hit with a 500 error, “You are already switched to X user”.
For both of our goals we overrode the built in switch user class. It is really easy to override, as all you need to do is specify in your parameters.yml “security.authentication.switchuser_listener.class: My\AppBundle\Listener\SwitchUser”. We used the built in class as our starting template: https://github.com/symfony/symfony/blob/2.5/src/Symfony/Component/Security/Http/Firewall/SwitchUserListener.php Our final class ended looking like:
Here are the specifics on what everything we did and why.
First feature: Redirecting the user on exiting impersonating a user to where they originally started impersonating them. As we didn’t want to go around our entire application updating logic for the exit impersonation links if we decided to later change the behavior, we decided to build the redirect into the class itself. We didn’t want to rely on the user’s browser referrer header, so instead we decided to on the links to impersonate a user to include a “returnTo” parameter. This parameter is set to the current URI (app.request.uri). At line 97 we save the returnTo parameter to the session, for later use. On line 93, as a user is switching (in this case exiting) a user, if the session has a stored “returnTo” URL, we assign it to the “$overrideURI” variable. On line 107 we have a bit of logic on if we redirect them to the default route or the “returnTo” URL. The reason for the additional “$this->useOverrideURI” variable on this line is for our second feature of switching between users when you are already impersonating one. As the logic all runs through the same routine, if you are simply switching to a new user from an already impersonated one, we don’t want to redirect you back to your original URL when you started all the impersonating, so we disregard the redirect in this case and redirect to the default route. An example of this is admin impersonates user A, then wants to impersonate user B. Upon impersonating user B, the admin does not want to be redirected back to the admin dashboard (the sessions returnTo URL), but to where the impersonate user link is pointing to (User B homepage).
Second feature: Allow users to impersonate a different user while already impersonating another. One Line 134 is where the original SwitchUserListener would usually throw a 500 error as you are already impersonating a user. Instead, we make sure that the original token has the appropriate permissions, if so it will not throw an exception. Line 159 is the other main update for this feature. If you are already impersonating a user and try to impersonate another user, upon exiting you want to go back to your original user. Now if a original impersonation token (user) exists, we keep that as the user you’ll be switched to when you exit the impersonation.
Recently when I was working on a client project we had a bunch of permissions which had a hierarchy (or tree structure). For example, you needed Permission 1 to have Permission 1a and Permission 1b. In the examples below lets assume `$choices` is equal to the following:
At first, I used the built in in optgroups of a the select box to output the form, so it was clear what permissions fell where. My form would look similar to:
Multiple select boxes aren’t the easiest to work with as we all know. Also, it isn’t as easy to visually see the difference as the height of the select box could not be long enough to show you what an optgroup’s title is. Instead, I decided to use the checkbox approach. Issue with this, the current Symfony2 form themes don’t output checkboxes in groups or with any visual indication of the hierarchy. I ended up creating my own custom field type so I could customize the way it renders globally via the form themeing. My custom type just always set the choice options to expanded and multiple as true. For the actual rendering, below is what I ended up with.
Since a picture is worth a thousand words, here is an example of what it looks like working:
Let me know if you have any questions! Happy Friday.
Unfortunately, setting something like this up with the default “pattern” setting in your security.yml file isn’t possible. The “pattern” setting only matches on the route URL, not the parameters so there’s no way to have it selectively trigger when a parameter is present on a URL. So how do you do it? Well as it turns out, there’s a firewall configuration called “reuqest_matcher” which lets you “match” a firewall using a service. Just create a service that extends the RequestMatcherInterface, implment a “matches” function, and then add the class as a service.
Our code for the service ended up looking like:
And then the actual firewall configuration ends up being:
You don’t need a “pattern” setting anymore since the “matches” function supersedes it. Anyway, let me know if you have any questions!
I was building out an API test console a few days ago and realized I’d never actually looked into how to grab all available routes in Symfony2. The “console” is basically a form with a select box and textarea that lets you “ping” the REST API routes in one of our applications. To make this work, I wanted to traverse all the registered routes, filter for the ones that contained “api_”, and then generate dummy URLs for those routes.
I searched around a bit for how to grab all the registered routes and the only link seems to be https://gist.github.com/hubgit/3380250 Unfortunately, if you try and use the code you’ll discover that “getPattern” no longer exists in the CompiledRoute class. It looks like it’s been replaced by getPathVariables
So, working code to generate a list of route names and “dummy” URLs for you API routes ends up looking like:
One of the nicest features of Symfony2 is the Request/Response paradigm for processing a HTTP request and then sending a response back to a client. At a high level, Symfony’s HttpFoundation component provides an object oriented abstraction to easily deal with HTTP requests and generate responses to send back to a client. Assuming application code correctly uses HttpFoundation, it will only interact with request variables through the Request class, as opposed to $_REQUEST, and only send output using the Response class, as opposed to an “echo”. Because of this contract, the framework as a whole makes it easy to manipulate responses before they’re sent back to a client.
A typical use case that leverages this would be logging API responses before they’re sent back to a client. As much as an API might be RESTful, at some point it’s easier to debug things when you can see the responses that clients have been receiving. OK great so how do you do it? It’s actually pretty straightforward, just create a class to receive the “kernel.terminate” event and register it as a service with the appropriate tags:
And then create the class where you want to manipulate or log the requests:
And that’s about it!
Note: Per Andras’ comment below the event has been switched to “kernel.terminate”.
Posted In: Symfony