Today I'd like to share a multitenant solution I developed for Symfony which came out very elegant and easy to use:

What I wanted was a way to include several customers under the same domain (and subdomain) with no passing of additional variables to control the current tenant over the different controllers. Specifically, what I wanted was a way to point to a tenant with the following structure:

{domain.com}/{tenant}/{controller}

But of course that wasn't as easy as expected, so here is the code I used to make it work:

app/config/routing.yml
 
 vendor_my:
 resource: "@VendorMyBundle/Controller/"
 type: annotation
 prefix: /{tenant}

I used FOSUserBundle, so it had to be configured too:

app/config/security.yml
 
 firewalls:
 main:
 pattern: ^/
 form_login:
 provider: fos_userbundle
 login_path: fos_user_security_login
 check_path: fos_user_security_check
 csrf_provider: form.csrf_provider
 success_handler: my.login_success_handler
 default_target_path: administration
 anonymous: true
 logout:
 path: fos_user_security_logout
 target: fos_user_security_login
 
 access_control:
 - { path: .*/login$, role: IS_AUTHENTICATED_ANONYMOUSLY }
 - { path: .*/, role: ROLE_USER }

Note that the last two lines have some minor regex changes so it can accept any tenant

Then I had to include a EventListener to save the tenant configuration in the session after a user has successfully logged in

/src/Vendor/MyBundle/EventListener/TenantListener.php
 
 namespace Vendor\MyBundle\EventListener;
 
 use Symfony\Component\HttpKernel\Event\GetResponseEvent;
 use Symfony\Component\HttpKernel\KernelEvents;
 use Symfony\Component\EventDispatcher\EventSubscriberInterface;
 
 class TenantListener implements EventSubscriberInterface
 {
 private $defaultTenant;
 private $router;//add
 private $context;
 
 public function __construct($defaultTenant, \Symfony\Component\Routing\Router $router, \Symfony\Component\Security\Core\SecurityContext $context)
 {
 $this->defaultTenant = $defaultTenant;
 $this->router = $router;
 $this->context = $context;
 }
 
 public function onKernelRequest(GetResponseEvent $event)
 {
 $request = $event->getRequest();
 if($request->attributes->has('tenant')){
 $this->defaultTenant=$request->attributes->get('tenant');
 }
 if ($this->context->isGranted('ROLE_USER')||$this->context->isGranted('ROLE_ADMIN')) {
 $this->defaultTenant = $request->getSession()->get('tenant');
 } else {
 $request->getSession()->set('tenant', $this->defaultTenant);
 $request->attributes->set('tenant', $this->defaultTenant);
 }
 $this->router->getContext()->setParameter('tenant',$request->getSession()->get('tenant'));
 }
 
 public static function getSubscribedEvents()
 {
 return array(
 // must be registered before the default Locale listener
 KernelEvents::REQUEST => array(array('onKernelRequest', 17)),
 );
 }
 }

And register the Listener under /app/config/config.yml

services:
 vendor.tenant_listener:
 class: Vendor\MyBundle\EventListener\TenantListener
 arguments: ["%default_tenant%", @router, @security.context]
 tags:
 - { name: kernel.event_listener, event: kernel.request, method: onKernelRequest }

With this solution I can pass the 'tenant' variable throughout the session so that every controller or twig can use it. Note that even if the user changes the tenant url, the variable considered is the one that was registered at the time of the login.

Now I can have a custom login theme for every tenant:

Extending the FOSUserBundle Controller in my Bundle:

/src/Vendor/MyBundle/Controller/SecurityController.php
 
 namespace Vendor\MyBundle\Controller;
 
 use Symfony\Component\HttpFoundation\RedirectResponse;
 use FOS\UserBundle\Controller\SecurityController as BaseController;
 use Symfony\Component\HttpFoundation\Request; 
 
 class SecurityController extends BaseController
 {
 
 protected function renderLogin(array $data)
 {
 $tenant = $this->container->get('request')->getSession()->get('tenant');
 
 ....

I can then check the tenant info passed in the Listener and use it to have a different experience for different tenants.

Great, right? Next post will be about checking if the current user belongs to the right tenant... To be continued

Qué permite hacer MDOP? Dividámoslo en tres grandes grupos:Virtualización, Administración y Diagnóstico/Reparación. No quiero centrar el artículo en esto, porque ya hay un sitio que tiene la descripción completa.

Dentro del primer gran grupo (Virtualización) se encuentra MED-V, que permite –en términos simples– distribuir y administrar una imagen del Modo XP dentro de la organización. Qué beneficios tiene esto versus el Modo XP? Aún más simple: Qué beneficio tiene esto versus correr Windows XP como mi sistema operativo base? Veamos:

1)     Qué beneficio tiene MED-V versus XP como sistema operativo base?

Han escuchado sobre el fin del soporte de XP? Así de simple.

Lo sé, me lo han dicho en innumerables ocasiones: Esa es una respuesta mezquina y antojadiza de parte de Microsoft sólo para cobrar por otro sistema operativo que hace exactamente lo mismo. Dentro de todo, XP funciona muy bien!

Hasta ahora. Qué está pasando con los equipos nuevos, con todas sus nuevas características (como pantallas touch, módulos de seguridad TPM, discos eDrive)? No está contemplado siquiera que soporten este antiguo sistema operativo. Pero el asunto va más allá todavía. Estudios demuestran que XP aumenta los costos de administración y disminuye la productividad de los trabajadores, en comparación con nuevos sistemas operativos.

No logré convencerlos? Déjenme sus argumentos en los comentarios y tengamos una conversación al respecto.

2)     Qué beneficio tiene MED-V versus el Modo XP?

El Modo XP no permite administrar la imagen que se instala dentro de la organización. Podría configurarse una imagen corporativa de Windows 7 con el modo XP ya configurado (lo que puede ser muy tedioso), pero al momento de querer hacer una actualización sobre ésta, la cosa ya no es tan simple. MED-V simplifica la administración de estas imágenes y no es necesario desplegar una imagen nueva de Windows 7 cada vez que ocurra un cambio o una por cada grupo de usuarios.

MED-V estará soportado por un tiempo más, hasta diciembre del 2016, pero esto no significa que será una forma de extender el soporte de XP. MED-V recibirá actualizaciones, sin embargo, el sistema operativo “guest” (XP), no recibirá actualizaciones a partir de abril del 2014. Los riesgos de seguridad seguirán latentes.

Quisiera dedicar un párrafo también a transmitir la necesidad de modernizar estas aplicaciones no soportadas por los nuevos sistemas operativos, o en su defecto, reemplazarlas. Probablemente ya existen soluciones en el mercado que pueden entregar soluciones más completas y robustas que estas antiguas aplicaciones. El mundo ha cambiado desde el 2001 y el ambiente en que se diseñaron esas aplicaciones probablemente ya no es el mismo que en el que se encuentran en la actualidad (de lo contrario, ese ambiente debe estar muy alejado de la realidad).

En resumen, la idea es concientizar sobre los costos que actualmente implica administrar un ambiente de trabajo con XP y los problemas de productividad que conlleva. Microsoft cuenta con herramientas (Como MED-V) que pueden ayudar a mitigar las dificultades que surgen al migrar a un nuevo sistema operativo, sin dejar de lado el mensaje principal: los costos de actualizar en estos momentos son menores a los costos de mantener una plataforma diseñada hace más de 11 años.