Rodrigo Fuentealba escribió: > El 24/09/07, Alvaro Herrera <[EMAIL PROTECTED]> escribió: > > Ricardo Mun~oz A. escribió: > > > cierto. pero depende del modelo y la aplicacion si es que en algun momento > > > se puede producir un conflicto... por algo los mismos desarrolladores de > > > Slony-I indican que sirve cuando todos los nodos estan disponibles todo el > > > tiempo... > > > > Estás poniendo a Slony-I para que se adapte a tu modelo, cuando en > realidad es al revés, debes adaptar tu modelo para que funcione con > esta solución. Por eso es que Álvaro hablaba de tablas heredadas; por > lo que entiendo, y como se me ocurre usarla, es hacer una tabla > maestra en cada zona que "extienda" a la tabla de datos total, > utilizando la característica de orientación a objetos de PostgreSQL, y > a esa tabla que extiende la pones como maestra en la aplicación. ¿Es > así, Álvaro?
Sí, básicamente de eso se trata. > > Lo que yo intentaria > > hacer seria tener copias esclavas de la base de dato en cada una de las > > sucursales, de solo lectura (con Slony-I); y que las escrituras vayan a > > la base de datos central. De este modo no se notaria la lentitud del > > enlace en las consultas de solo lectura (puesto que son locales a la > > sucursal), y se requeriria contactar al central solamente para las > > escrituras. > > Mira, este plugin lo estamos arreglando y usando para un sitio Web en > el cual tenemos ese inconveniente a nivel nacional, y no ha tenido > mayor problema hasta ahora (aunque es alfa!): > > http://trac.symfony-project.com/trac/wiki/sfPropelLoadbalancerPlugin Otra forma de hacer esto sin necesidad de modificar la aplicación es usando pgpool o pgBouncer. > > De esa forma, te ahorras todo el problema de la resolucion de conflictos > > y de replicacion multimaestro. El inconveniente es que cuando se caiga > > la conexion sucursal-servidor, no podrias escribir (pero ojo, que eso > > sucede en casi todos los sistemas multimaestro, incluso los > > comerciales). > > Inclusive aquí debes apelar a las leyes de la física y no aceptar a > personas que se crean Criss Angel, para que aparezcan al mismo tiempo > en dos sucursales distintas solicitando la misma información. Entrete > caso, :-s Eso generalmente no es problema cuando se trata solamente de leer información. Si hay que escribir, recuerda que las escrituras van directo a la base de datos maestra, asi que dos escrituras que entran en conflicto serian detectadas facilmente. -- Alvaro Herrera Developer, http://www.PostgreSQL.org/ "La victoria es para quien se atreve a estar solo" From [EMAIL PROTECTED] Mon Sep 24 16:59:06 2007 From: [EMAIL PROTECTED] (Aldrin Gonzalo Martoq Ahumada) Date: Mon Sep 24 17:01:35 2007 Subject: Evitar sql injection y xss In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> On 9/24/07, Ricardo Mun~oz A. <[EMAIL PROTECTED]> wrote: > Raul Perez wrote: > > Tengo mysql 5 y phpp 5 en un servidor con centos > > La pregunta es que codigo han implementado ustedes para > > asegurar sus aplicaciones en php para evitar injection de sql y xss > migrar a CakePHP y usar las herramientas que provee, mas info en [1]... ;) > en todo caso, en el mismo Cake la validacion de "SQL injection" viene > "de fabrica"... por ejemplo en el metodo findAll(), y en todos los otros > metodos que sirven para que el framework traiga datos desde la BD, se > puede hacer esto: > ... > $condiciones = array('nombres' => "LIKE %$nombres%", 'otro_campo' => "<> > $valor", etc.); > $this->set('clientes', $this->Cliente->findAll($condiciones)); > ... > entonces, en findAll() el framework va armar el correspondiente SELECT y > validara automaticamente todas las condiciones en el arreglo > $condiciones evitando SQL injection, independientemente del motor de BD > que uses con el framework. > [1] http://www.scribd.com/doc/5546/CakePHP-tutorial-no-3-from-IBM arghhhh! Que codigo mas horrible. No hay algo como JDBC (Java) o DB-API (Python) para PHP ??? Basicamente, algun framework que implementa el siguiente pseudocodigo: $args[0] = "valor de fi"; $args[1] = "valor de 'teta"; $rowlist = query("select value from foo where phi=?0 and tetha=?1", $args) foreach ($rowlist as $row) { print $row['value']."\n"; } -- Aldrin Martoq From [EMAIL PROTECTED] Mon Sep 24 17:10:36 2007 From: [EMAIL PROTECTED] (Alvaro Herrera) Date: Mon Sep 24 17:13:08 2007 Subject: Evitar sql injection y xss In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Aldrin Gonzalo Martoq Ahumada escribió: > No hay algo como JDBC (Java) o DB-API (Python) para PHP ??? > > Basicamente, algun framework que implementa el siguiente pseudocodigo: > > $args[0] = "valor de fi"; > $args[1] = "valor de 'teta"; > $rowlist = query("select value from foo where phi=?0 and tetha=?1", $args) > foreach ($rowlist as $row) { > print $row['value']."\n"; > } Sí hay, pero no todo el mundo lo usa :-) (de ahí que aparecen los "SQL injection" a cada rato) -- Alvaro Herrera http://www.flickr.com/photos/alvherre/ "People get annoyed when you try to debug them." (Larry Wall) From [EMAIL PROTECTED] Mon Sep 24 17:39:52 2007 From: [EMAIL PROTECTED] (Ricardo Mun~oz A.) Date: Mon Sep 24 17:42:57 2007 Subject: desarrollo deaAplicacion grande In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]><[EMAIL PROTECTED]> <[EMAIL PROTECTED]><[EMAIL PROTECTED]><3cd5f0920709 [EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Alvaro Herrera wrote: > Rodrigo Fuentealba escribió: > >> El 24/09/07, Alvaro Herrera <[EMAIL PROTECTED]> escribió: >> >>> Ricardo Mun~oz A. escribió: >>> >>>> cierto. pero depende del modelo y la aplicacion si es que en algun momento >>>> se puede producir un conflicto... por algo los mismos desarrolladores de >>>> Slony-I indican que sirve cuando todos los nodos estan disponibles todo el >>>> tiempo... >>>> >> Estás poniendo a Slony-I para que se adapte a tu modelo, cuando en >> realidad es al revés, debes adaptar tu modelo para que funcione con >> esta solución. Por eso es que Álvaro hablaba de tablas heredadas; por >> lo que entiendo, y como se me ocurre usarla, es hacer una tabla >> maestra en cada zona que "extienda" a la tabla de datos total, >> utilizando la característica de orientación a objetos de PostgreSQL, y >> a esa tabla que extiende la pones como maestra en la aplicación. ¿Es >> así, Álvaro? >> > > Sí, básicamente de eso se trata. > yo tambien entendi lo mismo, y por eso dije "depende del modelo si se produce un conflicto". en ningun momento dije que Slony-I se deberia adaptar al modelo, sino todo lo contrario. >>> Lo que yo intentaria >>> hacer seria tener copias esclavas de la base de dato en cada una de las >>> sucursales, de solo lectura (con Slony-I); y que las escrituras vayan a >>> la base de datos central. De este modo no se notaria la lentitud del >>> enlace en las consultas de solo lectura (puesto que son locales a la >>> sucursal), y se requeriria contactar al central solamente para las >>> escrituras. >>> >> Mira, este plugin lo estamos arreglando y usando para un sitio Web en >> el cual tenemos ese inconveniente a nivel nacional, y no ha tenido >> mayor problema hasta ahora (aunque es alfa!): >> >> http://trac.symfony-project.com/trac/wiki/sfPropelLoadbalancerPlugin >> > > Otra forma de hacer esto sin necesidad de modificar la aplicación es > usando pgpool o pgBouncer. > creo que el plugin que menciona Rodrigo le permite a sus aplicaciones hechas en Symfony escribir (UPDATE, DELETE) siempre en el mismo nodo (maestro) y las operaciones SELECT hacerlas en cualquiera de los nodos esclavos disponibles. una tecnica bastante comun de balanceo de carga y muy facil de implementar tambien en CakePHP... ;) pgpool y/o pgBouncer creo que no permiten hacer lo mismo... aunque pgpool-II se ve interesante... ;) -- Ricardo Mun~oz A. Usuario Linux #182825 (counter.li.org) From [EMAIL PROTECTED] Mon Sep 24 17:50:06 2007 From: [EMAIL PROTECTED] (Ricardo Mun~oz A.) Date: Mon Sep 24 17:53:11 2007 Subject: Evitar sql injection y xss In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Aldrin Gonzalo Martoq Ahumada wrote: > On 9/24/07, Ricardo Mun~oz A. <[EMAIL PROTECTED]> wrote: > >> Raul Perez wrote: >> >>> Tengo mysql 5 y phpp 5 en un servidor con centos >>> La pregunta es que codigo han implementado ustedes para >>> asegurar sus aplicaciones en php para evitar injection de sql y xss >>> >> migrar a CakePHP y usar las herramientas que provee, mas info en [1]... ;) >> en todo caso, en el mismo Cake la validacion de "SQL injection" viene >> "de fabrica"... por ejemplo en el metodo findAll(), y en todos los otros >> metodos que sirven para que el framework traiga datos desde la BD, se >> puede hacer esto: >> ... >> $condiciones = array('nombres' => "LIKE %$nombres%", 'otro_campo' => "<> >> $valor", etc.); >> $this->set('clientes', $this->Cliente->findAll($condiciones)); >> ... >> entonces, en findAll() el framework va armar el correspondiente SELECT y >> validara automaticamente todas las condiciones en el arreglo >> $condiciones evitando SQL injection, independientemente del motor de BD >> que uses con el framework. >> [1] http://www.scribd.com/doc/5546/CakePHP-tutorial-no-3-from-IBM >> > > arghhhh! Que codigo mas horrible. > > No hay algo como JDBC (Java) o DB-API (Python) para PHP ??? > > Basicamente, algun framework que implementa el siguiente pseudocodigo: > > $args[0] = "valor de fi"; > $args[1] = "valor de 'teta"; > $rowlist = query("select value from foo where phi=?0 and tetha=?1", $args) > foreach ($rowlist as $row) { > print $row['value']."\n"; > } > ADOdb para PHP permite hacer lo que mencionas. que tiene de feo el codigo de CakePHP? es solo tu gusto personal o tienes algo concreto que aportar? -- Ricardo Mun~oz A. Usuario Linux #182825 (counter.li.org) From [EMAIL PROTECTED] Mon Sep 24 17:53:23 2007 From: [EMAIL PROTECTED] (Horst H. von Brand) Date: Mon Sep 24 17:55:49 2007 Subject: desarrollo deaAplicacion grande In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Alvaro Herrera <[EMAIL PROTECTED]> wrote: 1> Ricardo Mun~oz A. escribió: > > Alvaro Herrera wrote: > > >>> "Slony-I is a system intended for data centers and backup sites, where > >>> the normal mode of operation is that all nodes are available all the > >>> time, and where all nodes can be secured. If you have nodes that are > >>> likely to regularly drop onto and off of the network, or have nodes that > >>> cannot be kept secure, Slony-I is probably not the ideal replication > >>> solution for you." > >> > >> Esto no es lo mismo que tener conexiones de baja velocidad. Por lo > >> demas, qué tan problematico sea depende del volumen de transacciones que > >> tengas. > > > > cierto. en el peor de los casos (si se corta el enlace entre la of.central > > y las sucursales) hay algo que se puede hacer a nivel de RDBMS? > > Bueno, lo que hace Slony-I es dejar una cola de operaciones en el > maestro, que se va vaciando a medida que los esclavos las reciben y > aplican. Si se cae la conexion, la cola empieza a crecer hasta que la > conexion vuelve. > > En realidad ese es el modelo de operacion normal de Slony-I: todas las > operaciones pasan siempre por una cola. Lo que pasa en condiciones > normales es que la cola se transmite en forma "instantanea". Cuidado con el teorema CAP (para una discusion de sistemas distribuidos ver p.ej. <http://www.ccs.neu.edu/groups/IEEE/ind-acad/brewer/sld001.htm>). Si, hay una demostracion rigurosa (en un modelo bastante simple y realista) del teorema de marras. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
