dev-php – Moy Blog

CIISA 2007 ( actualizado con presentacion corregida )

moy — Mon, 04 Jun 2007 00:53:44 +0000

Chale, de plano soy malisimo para esto de actualizar el blog. En fin. EstarÃ¨ dando una plÃ tica en el CIISA 2007 ( Congreso Internacional en IngenierÃ¬a de Software y Sus Aplicaciones ) en Julio. El tema: “Vulnerabilidades en Aplicaciones Web PHP”. Justo acabo de terminar el material y enviarlo para su revisiÃ²n. Aqui dejo ligas al material tambiÃ¨n para quien pueda interesarse.

Vulnerabilidades en Aplicaciones Web PHP ( presentaciÃ²n PowerPoint )

Vulnerabiliades en Aplicaciones Web PHP ( tutorial para ejercicios PDF )

Vulnerabilidades en Aplicaciones Web PHP ( codigo )

Cualquier correcciÃ²n o sugerencia serÃ bienvenida…

Asterisk Manager Interface PHP extension

moy — Fri, 08 Dec 2006 01:15:12 +0000

Ha pasado algo de tiempo desde mi ultimo post, pero he andado algo ocupado. Por estos dias ya empece a escribir ( al fin ) mi extensiÃ³n en C para el lenguaje PHP, esta extensiÃ³n le darÃ¡ soporte a PHP para conectarse directamente y sin escalas al API del manager de Asterisk. En linux ya compila y funciona al 80%. Necesito terminar ese 20% restante y darle soporte para windows.

El API general para PHP es:

resource ami_connect(string host, string user, string passwd)
bool ami_send_action(resource ami, string action, [array data])
array ami_read(resource ami, int timeout)
bool ami_attach(resource ami, string event, callback user_callback)
bool ami_detach(resource ami, string event)
int ami_queue_action(resource ami, string action, [array data], [callback user_callback])
void ami_loop(resource ami)
void ami_disconnect(resource ami)

CONSTANTS

AMI_KILL_LOOP
AMI_EXIT_LOOP

Y este es un script que he estado usando para probar:

http://moy.ivsol.net/scripts/ami.php

Es interesante empezar a conocer mas a fondo como funciona el zend engine. Ya con algo mas de experiencia explicare a detalle como hacer una extensiÃ³n, de momento solo quiero hacer menciÃ³n que dentro del zend engine, todas las variables son representadas como una estructura de C llamada zval. Asi que por ejemplo, para recibir una variable como argumento usualmente se hace algo como esto:

zval *my_argument; // declaramos el apuntador a la variable PHP

int my_length; /* aqui el zend engine pondra la longitud del argumento, en este caso es una cadena */

zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, “s”, &my_argument, &my_length);

de esta forma tenemos el argumento enviado por el usuario y la longitud de la cadena, el argumento “s” es una cadena de formateo, es necesario para especificar de que tipo debe ser el zval, en este caso una cadena.

ahila…

mas de TDD

moy — Sun, 30 Oct 2005 03:36:03 +0000

bueno, al fin he podido resolver el problema que tenÃa con el test suite para el proxy. Los problemas se debÃan principalmente a mi inexperiencia y la dificultad intrÃnseca de probar sockets. Afortunadamente el test estÃ¡ corriendo bastante bien usando incluso un par de pcntl_forks() y un workaround para generar eventos de forma aleatoria.

Para una explicaciÃ³n mas detallada aqui estÃ¡ el link al cÃ³digo y al foro de sitepoint donde seguimos comentandolo.

thread de sitepoint

CÃ³digo del test

se ven,

XP & TDD

moy — Fri, 28 Oct 2005 10:01:26 +0000

bueno, con la novedad de que por fin hemos decidido iniciar con extremme programming, metodologÃa que estÃ¡ intimamente ligada con el Test Driven Development. Principalmente lo desafiante para un principiante como yo, es que tienes que cambiar radicalmente tu forma de programar. Ahora debes escribir tests automatizados de tu cÃ³digo incluso antes de que escribas tu cÃ³digo. Las reglas son simples:

1. disenias tu API
2. escribes tests para tu API (los tests deben probar funcionalidad)
3. escribes el cÃ³digo que debe pasar los test
4. corres tus tests
5. corriges lo que seguramente no pas&ouacute; los tests, y vuelves al paso 3.

“code a little, test a little” dicen en varios sitios relacionados con el TDD.

Pero pues se nos ocurriÃ³ iniciar con una aplicaciÃ³n complicada por dos cosas:

1. la habiamos iniciado sin haber decidido utilizar XP, por lo que no pudimos aplicar la de escribir primero los tests, mas bien tuvimos que hacer los tests despuÃºs de que ya existÃa cÃ³digo escrito.
2. la aplicaciÃ³n es un proxy, y probar sockets, servidores y clientes, es una bronca incluso para programadores experimentados con TDD, como se puede apreciar en los siguientes posts de sitepoint donde hemos estado comentando la mejor forma de hacerlo. El post estÃ¡ un poco inactivo desde hace unos dias por que no he respondido, pero espero hacerlo pronto. Incluso el cuate que escribiÃ³ el framework para testing “simpletest” me comenta que es un poco complicado.

sitepoint: thread en site point aqui

de rato ….