Recientemente hemos visto como se han incrementado los ataques a instalaciones de phpMyAdmin.

En los logs de nuestros servers aparecen entradas como las siguientes:

De esto se desprenden las siguientes recomendaciones:
- Es importantisimo mantener actualizada la versión de phpMyAdmin para corregir problemas de seguridad.
- Igualmente importante es instalar la aplicación en un directorio con un nombre y ubicación no convencional, de esta forma, si llegara a descubrirse un nuevo problema, la instalación no será fácilmente accesible.
- De ser posible, es conveniente asegurar el directorio completo con autenticación de Apache utilizando AuthType, AuthName, etc.

Recientemente comencé un proyecto en el cual es necesario conectarse a un servidor remoto que provee un web service mediante SOAP.

Hace tiempo que no utilizaba SOAP, la última vez fue hace various años y el soporte de SOAP en PHP era bastante limitado. Debido al paso del tiempo, imaginé que ahora tendría mejor suerte y la experiencia sería mucho mejor y sin problemas.

Empecé a buscar qué opciones tenía para consumir el web service. Debido a que últimamente he estado utilizando el Zend Framework, lo primero que hice fue chequear si este disponía de librerías, con el resultado sorpresivo de que sólo tiene un cliente de XML-RPC.

Mi próximo paso fue revisar el manual de PHP, y la extensión SOAP aparecío como la solución a mi búsqueda.

El web service me ofrecía un WSDL, un documento XML que provee la definición de datos y métodos a utilizar. Idealmente, esto tiene que ser mapeado a una serie de clases en PHP con las mismas propiedades y métodos (esto se llama proxy). Un utilitario llamado wsdl2php me permitió generar todo el código PHP de una forma considerablemente rápida y sin problemas, aunque tuve que hacer algunas modificaciones menores en el código resultante para que todo funcione a gusto.

La extensión SOAP de PHP funcionó muy bien enviando datos simples, pero me topé con un problema al querer enviar un array de objetos. Diversos errores volvían de las llamadas al servidor. Seguí los consejos de la página del manual de PHP de utilizar SoapVar para generar el encoding necesario, pero sin un resultado positivo.

Como método de prueba y error, decidí probar la librería de SOAP de PEAR.

Luego de seguir las instrucciones de instalación, las cuales fueron bastante simples, me encontré con otro tipo de errores provenientes del servidor.

A este punto, me preguntaba si el problema estaba en el lado del servidor, por lo que cree un pequeño programa en  C# y .NET con Visual Studio. Este cliente SOAP funcionó de primera en cuestión de minutos !

Pude obtener el XML generado por .NET apuntando el cliente a un script
PHP que guardaba en un log el contenido del request via POST. Esto me
permitió comparar el XML generado por PHP y ver las diferencias, que
por cierto eran considerables.

Luego de buscar y comentar el problema con un colega, me comentó que estaba utilizando NuSoap. Esta es una de las primeras (sino la primera) de las librerías para crear servidores y clientes SOAP en PHP. En mi búsqueda inicial, la había encontrado, pero al ver que las últimas noticias en el sitio eran de 2004, imaginé que el proyecto había sido descontinuado y no estaría a la altura de las necesidades. Luego de mirar un poco mejor, descubrí que la última versión había sido editada en Noviembre de 2007, por lo que decidí a probar, otra vez.

Los primeros intentos también me dieron algunos errores, pero esta vez el XML era muy parecido a lo que debía ser aceptado por el servidor.

La clave fue preparar los parámetros a enviar de la siguiente forma:

 $param = array(’in0′ => new soapval( ‘AuthenticationInfo’, ”, $authinfo ),       
                        ‘in1′ => array( new soapval( ‘ContactInfo’, ”, $contact ) ) );      
 $result = $client->call(’addContacts’,$param );

En resumen, lo que parecería algo simple y fácil de hacer (como lo fue con C# y .NET), fue más complicado de lo esperado. Es notorio que luego de tantos años, el soporte de PHP sigue siendo deficiente, y que una librería que no es mantenida de manera activa haya dado los mejores resultados, el único resultado positivo.

Pido disculpas si no he dado suficientes ejemplos, o mensajes de error, espero poder comentar detalladamente cuando tenga más tiempo, si por lo pronto tienen alguna pregunta al respecto, no duden en contactarse mediante comentarios o via el foro de PHPes.

Autor: Javier Leyba

En estos dias he tenido la necesidad de instalar una copia de Symfony en un host compartido.
Yo ya había instalado dicho software en un par de máquinas pero de forma totalmente libre y standard, cosa que no
ocurre en los hosting compartidos donde, normalmente, existe una estructura fija que no responde a las necesidad del framework.

En este caso, mi proyecto Symfony consistía en una estructura “de manual”:

myproject
+—apps
¦ +—backend
¦ ¦ +—config
¦ ¦ +—i18n
¦ ¦ +—lib
¦ ¦ +—modules
¦ ¦ +—templates
¦ +—frontend
¦ +—config
¦ +—i18n
¦ +—lib
¦ +—modules
¦ +—templates
+—batch
+—cache
¦ +—frontend
¦ +—dev
¦ ¦ +—config
¦ ¦ +—i18n
¦ ¦ +—apps
¦ +—prod
¦ +—config
¦ +—i18n
¦ +—apps
+—config
+—data
¦ +—model
¦ +—sql
+—doc
+—lib
¦ +—model
¦ +—map
¦ +—om
+—log
+—plugins
+—test
¦ +—bootstrap
¦ +—functional
¦ ¦ +—backend
¦ ¦ +—frontend
¦ +—unit
+—web
+—css
+—images
+—js
+—uploads
+—assets
+—thumbnail

Al acceder al hosting me encuentro con una estructura donde:

1. No existí­a Symfony.
2. Existía un directorio httpdocs al que apuntaba el virtual host y donde debía dejar toda mi aplicación

El primer paso fue tomar conciencia de que era imposible instalar mi aplicación de esa forma.
Symfony tiene un directorio web al que debe apuntar el virtual host y todo el resto de la
aplicación debe estar por detrás de este.

En la empresa de hosting (servergrove) fueron muy gentiles, comprendieron el problema
y me habilitaron un directorio por debajo de httpdocs para instalar mi aplicación. De esa
forma, solo deberí­a hacer que Symfony entendiera que su directorio web, normalmente
dentro del árbol de la aplicación, estaba fuera de este, en httpdocs, algo que era posible
por configuración.

Ahora el problema pasaba a ser la instalación de Symfony.

Primero intenté instalarlo a mano, descargando un tarball y poniéndolo en un directorio
del host. Luego de muchas pruebas me rendí­ ya que no logré que eso funcionara.

La instalación normal y recomendada es utilizando PEAR y, dado que el hosting tení­a PEAR
instalado, imaginé que no vendrí­a mal que hicieran la instalación ellos. Nuevamente
la gente de servergrove me solucionó el problema y Symfony quedó instalado de forma
standard en un directorio accesible por Apache y en el path.

Ahora ya podía ejecutar comandos de Symfony (por ejemplo limpiar el cache con symfony cc)
dentro del directorio de mi aplicación. Y funcionaba !.

El siguiente paso consistí­a en indicarle a Symfony que el directorio web pasarí­a a ser httpdocs.
Para hacer esto, es necesario ir al archivo index.php de nuestra aplicación y modificar lo siguiente:

define(’SF_ROOT_DIR’, dirname(__FILE__).’/../myproject’);

De forma tal que SF_ROOT_DIR apunte a nuestra aplicación.

Luego, en el archivo config/config.php de nuestra aplicación hay que modificar dos paths:

sfConfig::add(array(
’sf_web_dir’ => SF_ROOT_DIR.DIRECTORY_SEPARATOR.’www’,
’sf_upload_dir’ => SF_ROOT_DIR.DIRECTORY_SEPARATOR.’www’.DIRECTORY_SEPARATOR.
sfConfig::get(’sf_upload_dir_name’),
));

De forma tal que quede así:

sfConfig::add(
array(
’sf_web_dir’ => SF_ROOT_DIR.DIRECTORY_SEPARATOR.’..’.DIRECTORY_SEPARATOR.
’httpdocs’,
’sf_upload_dir’ => SF_ROOT_DIR.DIRECTORY_SEPARATOR.’..’.DIRECTORY_SEPARATOR.
’httpdocs’.
DIRECTORY_SEPARATOR.sfConfig::get(’sf_upload_dir_name’),
));

Cabe destacar que el archivo config a modificar es el de cada aplicación (por ej: myproject/apps/frontend/config.php) y no el del proyecto (myproject/config/config.php)
porque el objeto sfConfig no esta disponible en el config del proyecto.

La instalación de Symfony tambien requiere establecer un alias en la definición del virtual
 host para algunos scripts y librerías que utiliza. Dado que esto es imposible en un hosting
 compartido, una solución sencilla es copiar el directorio sf de PEAR/symfony/ al directorio
web de nuestra aplicación, en este caso httpdocs.

Con estos pasos, la aplicación esta lista para funcionar.

Hay muchas formas para convertir estructuras de datos como arrays y objetos a XML.

Convertir estos datos a XML facilita la transmisión de datos a través de sistemas heterogéneos, y es utilizado en web services, SOAP, Xml-Rpc, Ajax y demas tecnologías.

Una de las mejores opciones para convertir arrays y objetos es utilizar XML_Serializer de Pear. Pear es un repositorio muy completo de clases con distintas funcionalidades.

Con PHP 5, pear se instala por defecto. En un sistema Linux, generalmente se encuentra en /usr/local/php (si PHP es compilado desde el código fuente), o en /usr/share/pear si PHP fue instalado via RPM.

Para instalar XML_Serializer y sus dependencias estos son los pasos a ejecutar en la linea de comando del shell:

$ pear install XML_Util
$ pear install XML_Parser
$ pear install channel://pear.php.net/XML_Serializer-0.18.0

Una vez instalado, ya puede ser utilizado en un script, de la siguiente manera:

<?php

// Set error reporting to ignore notices

error_reporting(E_ALL ^ E_NOTICE);

// Include XML_Serializer

require_once ‘XML/Serializer.php’;

// Some data to transform

$palette = array(’red’, ‘green’, ‘blue’);

// An array of serializer options

$serializer_options = array (

   ’addDecl’ => TRUE,

   ’encoding’ => ‘ISO-8859-1′,

   ’indent’ => ‘  ’,

   ’rootName’ => ‘palette’,

   ’defaultTagName’ => ‘color’,

);

// Instantiate the serializer with the options

$Serializer = new XML_Serializer($serializer_options);

// Serialize the data structure

$status = $Serializer->serialize($palette);

// Check whether serialization worked

if (PEAR::isError($status)) {

   die($status->getMessage());

}

// Display the XML document

header(’Content-type: text/xml’);

echo $Serializer->getSerializedData();
?>

El resultado sería el siguiente:

<?xml version="1.0" encoding="ISO-8859-1"?>
<palette>
 <color>red</color>
 <color>green</color>
 <color>blue</color>
</palette>

(ejemplos obtenidos de Sitepoint)

Así como esto funciona con arrays, tambien funciona con objetos y sus propiedades.

La nueva edición de la conferencia PHP|tek ha sido anunciada para los dias 20 al 23 de mayo de 2008. Tuve la oportunidad de participar de la edición 2007 y fue una experiencia imperdible.

Para aquellos que utilizan IIS y Windows como servidor web, llegan buenas noticias desde Microsoft.

El anuncio de que FastCGI fue incorporado a IIS6 significa que PHP ahora puede ser instalado utilizando esta interface, que en el mundo Unix ya es usada con mucho éxito por su flexibilidad y rapidez.

Me gustaría saber la experiencia de usuarios de FastCGI en IIS.

Más información de PHP sobre Windows aquí.

Recientemente salió la version 5.2.5 de PHP. Esta versión contiene mas de 60 bugs corregidos, alguno de los cuales son cuestiones de seguridad. A bajarlo ya!

El mercado de editores para PHP está creciendo. Hasta hace poco, sólo habia unos pocos suficientemente buenos para nombralos.

Con el crecimiento de la complejidad de las aplicaciones web, ya no es productivo utilizar editores de texto, ya que es necesario poder hacer ‘debugging’, poniendo ‘breakpoints’. Otra gran utilidad es el profiling, que permite encontrar puntos en los cuales los programas consumen más tiempo y recursos.

Zend Studio fue uno de los precursores en este rubro. Recientemente fue puesto en disponibilidad la versión beta del plugin para Eclipse, un IDE que permite utilizar distintos lenguajes de programación instalando plugins.
Otro de los editores que han estado en el mercado por un buen tiempo es el ActiveState IDE, que recientemente cambió su nombre a Komodo IDE.
Tanto Zend Studio como Komodo IDE son versiones comerciales con un precio cercano a los $300 dolares.
Recientemente, apareció un nuevo jugador en este ámbito. A diferencia de los mencionados anteriormente, el Aptana IDE es open-source y tiene mucho futuro, bienvenido sea! La lista de ‘features’ es importante: soporte para Javascript, CSS, Adobe AIR, Ajax, SFTP, y muchas más.
Me gustaría saber que IDEs utilizan, asique no sean timidos y comenten!

El uso de PHP en sitios importantes y con alto tráfico sigue creciendo, lo que demuestra la madurez del lenguaje y plataforma, y los buenos resultados que estos otorgan.

A la impresionante lista de sitios (Yahoo, Skype, Techcrunch, ZDNet entre otros) se suma de.li.cio.us, un sitio para compatir bookmarks.

de.li.cio.us utilizará el framework Symfony que es utilizado por Yahoo en varios de sus sitios.

Más información.

Ayer fue puesto a disposición una nueva versión del Zend Framework, con bugfixes y algunas mejoras.

Podés

obtener esta versión aquí.