Desde que estoy realmente inmerso en el desarrollo con WordPress dentro de Codection, intento atender este portal con al menos una noticia resumen semanal. El fin de semana pasado estuve fuera, que coincidía con el día de Andalucía; y esta semana ha sido muy dura, así que no he podido hasta hoy preparar esta entrega. Pero bueno, como siempre digo más vale tarde que nunca y por supuesto, que no se pierdan las buenas costumbres.
Vamos a ver este resumen quincenal de enlaces a recursos de interés para todos los que estéis dentro del mundo linuxero, del software libre y del desarrollo web:
Cuando desarrollo plugins y themes para WordPress en CODECTION siempre procuro mirar por la seguridad, “sanitizando” variables tanto para evitar ataques vía inyección SQL como para evitar ataques XSS. Es muy frecuente, que si recibes peticiones y luego las devuelves por pantalla, las variables que manejes, si las maneja el usuario de alguna manera, puedan terminar siendo el origen de una ataque XSS.
Algo tan sencillo como pasar una etiqueta script o iframe en un sitio conveniente y además de un ataque XSS, eres una fuente de phising para el resto de la red. Por fortuna, WordPress facilita mucho la vida al desarrollador al respecto y para evitar este tipo de ataques nos ofrece una función que además es extensible en su funcionamiento vía parámetros.
La función en cuestión es wp_kses() y aunque es similar a strip_tags(), una función nativa de PHP, suele recomendarse para cuestiones de seguridad.
¿Para qué usamos wp_kses?
Básicamente deciros que sirve para limpiar una cadena de elementos HTML indeseados (imaginad otros usos que no sea el de seguridad, se me viene a la cabeza un uso de “limpieza” de una cadena proveniente de Microsft Word o LibreOffice Write).
Tiene esta forma:
wp_kses($string, $allowed_html, $allowed_protocols);
Y los parámetros que recibe indican exactamente:
La función devolverá el código HTML totalmente limpiado.
El segundo parámetro es interesante, porque podemos definir también qué atributos pasarán de cada etiqueta, un ejemplo curioso:
array(
'a' => array(
'href' => array(),
'title' => array()
),
'br' => array(),
'em' => array(),
'strong' => array(),
);Ejemplo
El ejemplo es original de Simon Wheatly. Tenemos de entrada:
Wisi <a href=”#” style=”color: red;”>defui nunc</a> dignissim <strong class=”weird”>transverbero ideo vel</strong> utinam blandit, iaceo meus epulae enim amet nibh sed brevitas. Pala consequat <script type=”text/javascript” src=”http://example.com/certainly/do/not/want/this.js”></script> capio sino regula typicus <small>luptatum</small> olim ullamcorper uxor in verto.
Vamos a dejar sólo:
El código sería este:
$entrada = 'Wisi <a href="#" style="color: red;">defui nunc</a> dignissim <strong class="weird">transverbero ideo vel</strong> utinam blandit, iaceo meus epulae enim amet nibh sed brevitas. Pala consequat <script type="text/javascript" src="http://example.com/certainly/do/not/want/this.js"></script> capio sino regula typicus <small>luptatum</small> olim ullamcorper uxor in verto.'; $etiquetas_permitidas = array( 'a' => array( 'href' => array(), 'title' => array(), 'target' => array() ), 'em' => array(), 'strong' => array(), ); $salida= wp_kses( $entrada, $etiquetas_permitidas ); echo $salida;
Si te dedicas a la consultoría web estarás acostumbrado a manejar phpMyAdmin como cliente de MySQL sobre la web. Sin lugar a dudas, pasa por ser la solución la solución más completa de las que existen en este campo y teniendo la precaución evidente de no dejarlo colgado de una ruta demasiado visible que pueda ser rastreada hasta por los bots que andan buscando sitios susceptibles de ser atacados, no deberíamos tener ningún problema usándolo de cara a seguridad (la idea es la que os digo, taparlo un poco usando una ruta rara y al dejar de usarlo borrarlo inmediatamente).
Si manejáis WordPress a diario seguro que alguna vez habréis sufrido un error de falta de memoria RAM, que se traduce en un mensaje de este tipo:
Fatal error: Allowed memory size of N bytes exhausted
Como sabréis, PHP es un lenguaje del lado del servidor, que se interpreta (no se compila) y que en cada ejecución necesita una no despreciable cantidad de memoria para poder ejecutarse. Si usamos un sistema gestor de contenidos como WordPress y encima usamos cantidad de plugins y un theme que sea algo pesado, es muy posible que una ejecución necesite del orden de 64MB de RAM hacia arriba (he visto necesidades de más de 128 MB de RAM para ciertas operaciones).
Siempre que manejamos PHP, existe la problemática de mezclar la vista y funcionalidad. Este problema se da a varios niveles y es más complejo y da más quebraderos de cabeza cuanto más se enrevesan código y funcionalidad, el caso típico es cuando guardamos parte de la vista en una cadena y la devolvemos o la imprimimos. Al meter la vista dentro de la cadena, el código se vuelve poco legible y además hay ocasiones en las que este métodos llega a ser inoperable.
Hay muchas formas de hacerlo, pero las que pasan por usar directamente $_SERVER como la vía que se muestra en este ejemplo no me convencen para nada.
Así que ya que usamos WordPress, vamos a ayudarnos de éste para hacerlo.
Lo primero es entender qué significa obtener la dirección URL actual, en resumidas palabras obtener lo que tenemos en la barra de direcciones (si no hemos modificado su contenido previamente, de cajón 😉 ) Con la función add_query_arg, si no le pasamos ningún elemento (array()) obtendremos la ruta actual de la forma /página/subpágina/ pero si lo que deseamos es la dirección completa tendremos que usar home_url. Así, si introducimos lo siguiente:
Si manejáis PHP y sois usuarios de Linux sabréis que una de las mejores librerías que existen para manejar imágenes, con operaciones a todos los niveles, es imagemagick.
En caso de que la estéis usando y obtengáis un error 500 del servidor, si activáis los errores, es posible que tengáis algo así:
PHP Fatal error: Class ‘Imagick’ not found
El error se debe a que no tenéis instalada la librería correctamente, la solución es simple:
apt-get install imagemagick php5-imagick
