Un problema recurrente con los sistemas grandes y/o multidominio es mantener la sesion de usuarios entre diferentes dominios.

Es imposible hacerlo con las cookies ya que por cuestiones de seguridad los browser no dejan leer o escribir cookies con diferente dominio al actual.

Lo mismo pasa con las sesiones, si uno accede a una pagina y genera un sesion cuando pasa a otro dominio pierde esa sesion.

La solucion no es nada simple. En el ultimo web and beer se hablo de una solucion, pero esa solucion no me dejo nada convencido, y me quede pensando en la idea.

Actualmente en Easytech estamos trabajando en un proyecto, que inicialmente iba a tener el mismo problema, pero lo solucionamos usando un unico dominio, ya que no era necesario otro. Solo tuvimos que unir varios sistemas, bajo el mismo dominio, pero esto es mucho mas facil, ya que podemos pasar un hash que nos permita buscar la info del usuario en una base de datos o en el file system a traves de las cookies.

Pero este problema de los multidominios tiene solucion, de hecho tenemos un google account, que administra las claves de diferentes dominios, ya sea www.gmail.com, www.google.com, www.youtube.com, www.orkut.com, www.picasaweb.com, etc.. Si google lo resolvio porque no nosotros?

Una manera de resolver este probelma, es guardar los datos de sesion en una base de datos, y los enlaces a los diferentes dominios agregarle el hash que hace de indice en esta base para que pueda regenerar los datos de session. El problema es que si yo accedo directamente a un dominio eso no me va a funcionar muy bien.

Una alternativa a este problema es que todo siempre se redireccione a un dominio, cheque si hay una sesion, y despues redirigirlo, como hace google.

Por ejemplo, cada vez que nosotros accedemos a www.orkut.com, este nos redirecciona a https://www.google.com/accounts/ServiceLogin y envia todos los parametros que necesita para identificar al usuario.

Desde este dominio de autenticacion, generamos la cookie correspondiente con el hash necesario. Y lo volvemos a redireccionar al sitio que quiere acceder con un parametro hash, con el indice para que obtenga los datos.

La solucion parece bastante simple, y creo que lo es pero  queria compartirla ya que se me quedo colgada en el ultimo web and beer.

Vamos a ver ahora un ejemplo practico

Yo tengo el dominio www.mail.com, el dominio www.calendar.com, y el dominio de mi empresa que se llama www.cloacas.com.

Un usuario ingresa en www.mail.com, ingresa los datos de su cuenta, este formulario envia un post a http://account.cloacas.com/, valido los datos, genero la autenticacion, y lo redirecciono a http://www.mail.com/?id=1231534232, el dominio mail.com, sabe que tiene que generar la sesion con los datos que va a obtener de la base de datos, con el indice que le paso en id.

Con esto tengo que haber logrado autenticarme en www.mail.com. Ahora el usuario, en otro tab de su browser escribe, www.calendar.com.

Calendar.com, hace lo mismo que www.mail.com, y lo redirecciona a account.cloacas.com, este se fija sino tiene ninguna cookie seteada, y si la tiene busca el hash que guardo en la cookie y la compara con el de la base de datos, si todo esta ok, redirecciona al usuario a www.calendar.com/?id=1231534232, sin la necesidad que el usuario ingrese sus datos, porque ya lo habia hecho en www.mail.com

Gente pido disculpas porque prometi para hoy enviar la 3 er parte del blog, pero ayer a Edenor con 50 grados de calor se le ocurrio cortar la luz, antes que pueda hacer el commit, con los documentos, y los archivos. Tratare de subirlos hoy a la noche.

Saludos, y sepan disculpar

Hace unos dias me entere que voy a ser Padre, y mas alla de todos los sentimientos que esto genera y lo feliz que me hace.

Cuando comente esto con algunos amigos geeks me dio gracia que uno de ellos, Agustin Dotta, me pregunto “Che asi que hiciste Zend_Baby::getInstance()?”.

Esto me dio tanta gracia que termino en mi nic de Gtalk.

Gonzalo Gorosito se sintio inspirado por esta frase y creo el objeto Zend_Pablo. Aca comparto lo geeks de este tipo de gente, y gracias.

 'soltero' , 'esFea' => false );
   private $_realMarriedStatus = false;

   protected function __construct( $action ){
       try {
               $this->doAction( $action );
       } catch ( Exception $e ) {
               print $e->getMessage();
               die( 'fuck off ');
       }

       $pablosWife = new Zend_Pablo_s_Wife();

       if( !is_null( $pablosWife ) ){
               $this->_realMarriedStatus = true;
       }
       $minitaQa
   }
   public static function getInstance() {
       if ( is_null( self::$instance ) ) {
           self::$instance = new self;
       }
       return self::$instance;
   }
   public function doAction( Action_Object $action ){
       switch( $action ){

           case 'levantar':
           case 'iracasa':
           case 'dormir':
           case 'trabajar':
           case 'comer':
           case 'salir':
           case 'salirconamigos':
               $this->ponerla();
               break;
           default:
               $this->ponerla();
               break;
       }
   }
   private function ponerla(){
       if( $this->_realMarriedStatus ){
           $this->baby = new Baby();
           return true;

       } else {

           $minita = new Minita();
           $minitaQa = $minita->getQuality();

           if(  $this->_marriedStatus[ $minitaQa ] == 'soltero' ){
                   $sex = new Zend_FastSex();
                   $sex->doAction( true );
           }

           //always return false this case......
           return false;

       }
   }

}
?>

En esta parte vamos a emprolijar un poco nuestro sistema, en la versión anterior el objetivo era mostrar el frontend, pero el código no nos quedo muy limpio, y tampoco aprovechamos todo el potencial de ZF.

Usando Zend_Config

Si ustedes configuraron el virtual host de forma diferente al mio, y apunte a otro puerto y/o a otra url, cuando fueron a ejecutar el blog, seguramente no les tomo los estilos. Esto se debe a que nosotros hardcodeamos la url del proyecto, dentro del preDispatch, si quisieramos arreglar esto deberíamos entrar al IndexController y cambiar los valores de estas variables, si bien esto es mejor que escribir la url, una por una donde se requiera, lo mejor es tener un archivo de configuracion, donde todos estos datos que pueden variar según donde este alojado nuestro proyecto. ZF nos provee Zend_Config, y nos da la posibilidad de guardar nuestra configuracion en archivos .ini, y .xml, por simpleza, y porque me parece mucho mas claro, yo uso los .ini, que va a ser el que vamos a usar en este proyecto. Lo que hace Zend_Config, es levantar el file, y crear un objeto con todas las propiedades que pusieron en ese archivo. Vamos al ejemplo del proyecto, creamos un archivo de configuracion, dentro de la carpeta config/ llamado condig.default.ini.

Este archivo va a contener inicialmente las dos propiedades que antes teníamos en el preDispatch.

[site]
static.server = “http://blogzf.dev:8001/”
app.server = “http://blogzf.dev:8001/”

Si nuestro virtual host es diferente completamos los valores equivalentes.

La forma para levantar estos valores es muy simple, desde el bootstrap, vamos a levantar los datos de este archivo y lo vamos a almacenar con Zend_Registry, de forma tal que podamos utilizarlo en cualquier estado del sistema.

$config = new Zend_Config_Ini('config/config.default.ini');
$registry = Zend_Registry::getInstance();
$registry->set( 'config_ini', $config );

Esto es mas que suficiente, para tener nuestro archivo de configuracion en un objeto, y al alcance de cualquier clase que lo requiera.

Ahora en nuestro preDispatch, vamos a traer los valores del config, para mostrarlos en la vista con el siguiente código.

get( 'config_ini' );

$this->view->staticServer = $config->site->static->server;
$this->view->appServer = $config->site->static->server;

La forma de traer datos de la configuracion, es anidar las propiedades, hasta el ultimo valor para que devuelva el valor correspondiente en el config. En nuestro archivo de configuracion tenemos [site] static.server, y para obtener este valor hacemos $config->site->static->server;

Limpiando el layout

En la primer parte teníamos un html pegado en colorpaper.phtml, que es nuestro layout. Para esta versión trate de separarlo por lo menos un poco, para que el archivo quede mas claro, y mas adelante podamos modificarlo de una forma mas cómoda.

Para hacer esto use $this->layout()->content, que como default, me muestra el phtml del action que estamos viendo. Por ejemplo, el action de nuestra home, deberia mostrar un listado de los ultimos post enviados.

Para el menu principal, use $this->layout->menuTop, y lo configure desde el preDispatch. Definiendo que modulo tenia que llamar para mostrar el contenido en esa seccion, lo mismo, para el sidebar, y el footer.

A todo esto cree un controller SidebarController, para que maneja estos 3 modulos (menuTop, sidebar, footer), mas adelante podemos seguir separando esto, de acuerdo al diseño que vayamos a utilizar.

Las lineas donde configuramos esto son las siguientes.

$response = $this->getResponse();
$response->insert( 'sidebar', $this->view->action( 'rightcontent', 'sidebar' ));
$response->insert( 'footer', $this->view->action( 'footer', 'sidebar' ));
$response->insert( 'topMenu', $this->view->action( 'menutop','sidebar' ));

Sino queremos llamar a un modulo y solo queremos mostrar contenido html estatico podemos hacer un render de un archivo, por ejemplo si el codigo html del footer estuviera en un phtml, sin necesidad de llamar a una accion, podriamos hacer lo siguiente

$response->insert( 'footer', $this->view->render('sidebar/footer.phtml' ));

Esto va a depender de las necesidades que tengamos.

Para bajarte esta version del programa podes descargartelo desde el tag

$ svn internal https://blogzf.googlecode.com/svn/tags/paso_2_layouts_y_configuracion

Componentes utilizados

Zend_Config
Zend_Registry

La url del proyecto es

http://code.google.com/p/blogzf/

Creando un blog desde cero.

Introduccion al proyecto.

La idea de este proyecto, es tratar de transmitir mis conocimientos sobre Zend Framework, y mostrar que es muy simple trabajar con el. Hace tiempo que llevo trabajando con este framework, y me facilita mucho el trabajo diario, y el trabajo en grupo. El blog posiblemente cuando se termine reemplaze a mi worpress, pero eso veremos mas  adelante como evoluciona el proyecto.

Cuando ustedes lean esto el blog va a estar bastante encaminado. Cada parte importante del desarrollo del blog voy a postearlo para que hagan comentarios, y el aprendizaje sea de apoco y no todo de golpe.

Subi el proyecto a google code, por cada corte importante del proyecto cree un tag, ese tag corresponde a un post especifco donde se explican los cambios y porque aplicamos tal o cual cosa.

Una vez el proyecto este terminado cualquiera tiene derecho a implementar este  blog que vamos a desarrollar aca es open source, y totalmente libre.

Manos a la obra

La gente que este leyendo este post, y no sepa nada de Zend Framework quizas les cueste un poco mas entenderlo porque hay conceptos que ya se hablaron en este blog, y no quiero repetirlos, si hay algo que no entienden pueden preguntarlo o googlearlo.

Lo primero que vamos a hacer es armar la estructura, que va a ser practicamente la misma que en el articulo que arme hace varias semanas, pero con algunos cambios, la carpeta apps, se va a llamar application, y la carpeta html sera webroot. Ademas vamos a mover la carpeta layout dentro de webroot.

Creando el virtual host.

# Blog para el proyecto

    ServerAdmin soporte@blogzf.com
    DocumentRoot /var/www/html/blogzf/webroot
    ServerName blogzf.dev
    
        Options FollowSymLinks
        AllowOverride All
    
    # Opciones de PHP
    php_value include_path .:/var/www/html/blogzf/webroot
    ErrorLog logs/blogzf-error.log
    CustomLog logs/blogzf-access.log common

Lo primero que vamos a crear es el bootstrap, que va a ser muy simple por ahora, y generar un layout basico que vamos a pedir prestado por ahi. La configuracion inicial va a quedar bastante basica. Vamos a crear un controller IndexController, un bootstrap index.php en la carpeta webroot, un .htaccess en la carpeta webroot tambien, y una carpeta con el nombre del layout, tambien vamos a agregar como external la libreria de Zend al proyecto. Si queres saber mas sobre como hacer esto, ya hay un post en el blog.

Para ir viendo como quedo esta parte del blog pueden bajarse los archivos del tag de esta version del proyecto haciendo.

$ svn import http://blogzf.googlecode.com/svn/tags/paso_1_layouts_y_configuracion/

Si crearon bien el virtual host, con solo escribir en el navegador http://blogzf.dev:8001/, tienen que ver algo parecido a esto.

Analizando el codigo.

Como primer punto voy a describir el bootstrap, basicamente este archivo tiene que tener una configuracion basica, para que pueda llamar al controller que correspondiente, y asi ejecutar la accion que requerimos.

Nuestro bootstrap es el siguiente.

 'colorpaper/colorpaper',
                'layoutPath' => 'layout/'
);
Zend_Layout::startMvc( $options );
/**
 * Setup controller
 */
$controller = Zend_Controller_Front::getInstance();
$controller->setParam( 'config', 'config.default.ini' )
    ->setControllerDirectory('../application/controller')
    ->throwExceptions(true)
    ->dispatch();

Hacemos unas configuraciones basicas, y despues que le decimos lo path del sistema, esto lo hacemos para que la comunicacion entre carpetas, sea mas sencilla. Algo importante que va a tener nuestro sistema de Blog, es que vamos a usar Zen_Loader::registerAutoload();, lo que hace este componente, es tratar de incluir el archivo que estes llamando, de esta forma si escribis bien el nombre de una clase, haciendo referencia al path, no necesitas hacer un required, o include. Si bien esto no es muy recomendable, porque cae un poco el rendimiento, tambien es cierto que es muy comodo , igual despues mas adelante, cuando optimizemos el sistema, vamos a arreglar un poco este problema.

Las siguientes lineas corresponden a la configuracion del layout, que en este caso agregamos un layout, que se llama colorpaper, y queremos que ejecute colorpaper.phtml.

Las ultimas lineas ejecutan el controller,

Si vemos el codigo vamos a ver que no hay nada raro en especial tenemos un controller (IndexController), con un preDispatch, y un indexAction. El preDispatch ejecutamos todo lo que necesitamos que se cargue antes de empezar a ejecutar la accion.

view->staticServer = 'http://blogzf.dev:8001/';
        $this->view->appServer = 'http://blogzf.dev:8001/';

        /**
         * Agrego el titulo de la pagina
         */
        $this->view->headTitle()->append('Blog con Zend Framework');
        /**
         * Agrego los css para esta pagina
         */
        $this->view->headLink()
            ->appendStylesheet( $this->view->staticServer . 'layout/colorpaper/css/jd.gallery.css' )
            ->appendStylesheet( $this->view->staticServer . 'layout/colorpaper/css/pink.css' )
            ->appendStylesheet( $this->view->staticServer . 'layout/colorpaper/css/style.css' );

En las primeras lineas del preDispatch, configuramos dos propiedades, que van a afectar a las vistas y al layout, uso dos tipos de variables para guardar el dominio, porque puede surgir que yo tenga por un lado un servidor para las imagenes, css, html y en otro servidor la aplicacion en si. Por ahora va a ser la misma, pero esto va a depender de ustedes.

Al hacer $this->view->staticServer, le estamos diciendo que cree una propiedad staticServer, esta es la forma en que ZF comunica desde un controller a una vista.

Despues tenemos la linea

$this->view->headTitle()->append('Blog con Zend Framework');

Aca estamos seteando el titulo del blog.

Y en la siguientes lineas, agregamos los css, que vamos a trabajar.

Cuando nosotros apendeamos, un titulo, los meta, los css, y los js, podemos mostrarlos desde la vista muy facilmente, usando los metodos que van a encontrar en el layout, que veremos mas adelante.

Por ahora nuestro indexAction no hace nada, lo mismo que la vista del mismo.

Como primera meta de este proyecto me propuse tomar un diseño modernoso, y adaptarlo al sistema de layout de Zend. Quise darle un aspecto atractivo, para que llame la atencion, y vean un poco el potencial del proyecto, que a veces el problema con excelentes proyectos de este tipo el problema es que no son atractivos y no llaman la atencion, este proyecto busca llamar la atencion, por eso este diseño. Lo unico que queria para esta parte es que me mostrara los datos de forma estatica pero minimante configurado el layout, y digo minimamete porque este layout va ir mutando a medida que avanze el proyecto.

Com hablamos antes en el preDispatch, apendeamos el title, y los css del layout, para mostrarlos desde nuestro layout, hicimos lo siguiente.

<!DOCTYPE HTML PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
<html dir=”ltr” xmlns=”http://www.w3.org/1999/xhtml” lang=”en-US”>
<head profile=”http://gmpg.org/xfn/11″>
<?= $this->headMeta() ?>
<?= $this->headTitle() ?>
<?= $this->headScript() ?>
<?= $this->headLink() ?>
</head>
<body>

Bueno por hoy es suficiente, para la proxima vamos a seguir separando el layout, para que nos quede mejor dividido, y vamos a usar archivos de configuracion, para guardar los datos de nuestros sistemas.

En esta parte del proyecto vimos los siguientes componentes.
* Zend_Controller
* Zend_Loader
* Zend_Layout

Me imagino que el lunes cuando veas tus feeds vas a encontrar esta guia repetida varias veces. Pero mi idea es mantener este tipo de contenidos en este blog, porque son documentos totalmente destacados. Hace unos dias google saco esta guia en ingles, y cumpliendo con su norma de traducir todo a por lo menos 14 idiomas ( Esto contaron los de adWords Argentina, en una conferencia que fui el año pasado ) tenemos la version en nuestra lengua.
A descargar, y a cultivarse.

Descargar

Una interesante publicidad de Zune, al final no me quedo muy claro lo que realmente querian expresar, Zune sera una mierda?

Zune Paint from Sibling Rivalry on Vimeo.

Hoy encontre un servicio bastante interesante, 123 People. La idea de este servicio es buscar gente, y su actividad por la red.

Lo interesante es que funciona, de hecho puse, pablo-morales.com, y aparece una foto mia, por suerte no encontre que aparezca mi mail ni mi telefeono, algo que seria un poco mas grave.

123 People busca los nombre por los grandes servicios, tal como linkedin, xing, picasa, google, etc.

Hay que tener cuidado con las cosas que hacemos por internet.

Ultimamente estoy escribiendo bastante y mas sobre Zend Framework, esto es debido porque en el trabajo estamos desarrollando mucho dependiendo de este framework, y no solo yo, somo varios, y muchos de ellos estan encontrando cosas realmente interesantes, que todavia no habia visto referencias en Espaniol, espero poder aportar todos esos descubrimientos.

Un descubrimiento importante que surgio en el trabajo despues de que uno de los chicos estaba debugueando una aplicacion, fue el uso de Binding variables en Oracle con Zend_Db_Select.

Una forma muy comun de creer que usamos binding variables es la siguiente.

$query = $this->select()->where->(' id = ?', $id );

El problema es que esto Zend_Db_Select lo procesa y hace el reemplazo de lo desconocido (?), por el parametro que continua, si es una variable reemplaza el ? por la variable que se pasa como segundo parametro, y si fuera un array , reemplaza por orden.

Si hacemos un echo del query resultante, esto nos va a dar los siguiente

SELECT * FROM tabla WHERE id = 1;

Cuando lo que deberia devolver para que el motor de Oracle saque provecho de las binding variables seria, lo siguiente:

SELECT * FROM tabla WhERE id =:id;

Si quisieramos aprovechar esto con ZF la solucion es simple.La consulta anterior podemos generarla de la siguiente forma.

select()->where( 'id = :id ' );
$this->fetchAll( $query, array( 'id' => 1));
?>

Hay una nota muy interesante sobre las binding variables de Oracle en el blog de Web And Beer. Las binding son una opcion mas que importante para aprovechar el motor de la base de datos, seria bueno usarla de la manera que corresponde.