Microsano

En estos días el buscador Google encontrará una nueva palabra en la Web, se trata de microsano, que antes del inicio del concurso de HazRuido no devolvía resultados al ser buscada en Google. Al parecer no seran pocos los desarrolladores Web que dedicarán alguna sección de su Web a esta palabra, la mayoría con la intención de lograr un poco de tráfico desde Google y una dosis de satisfacción personal.

Un post de PosicionaWeb sobre microsano ha enlazado una página que se intenta posicionar: microsano, donde se anuncia ademas, la presentación de una herramienta para llevar un seguimiento estadístico de microsano en Google. En ese caso se menciona parte de la prueba ante la que se ha puesto el propio Google: ¿ las buenas técnicas de posicionamiento o trucos engañosos ? Ojala sean las primeras, pues despues de tanto bombo y platillo a los jagger y mini-updates posteriores seria vergonzoso otro resultado.

No resultará nuevo tampoco ver como se crean de repente varios blogs con microsano como nombre y URL, incluso ver comprados los nombres de dominios con esta palabra.

Oscommerce y register_globals

Hace unos días me sucedió un percance instalando un Oscommerce en un servidor Windows con register_globals desactivado en el PHP.INI . El OsCommerce requiere del register_globals activado para funcionar correctamente, sin embargo en muchos servidores Web se encuentra desactivado esta opción ya que representa un riesgo de seguridad a través de códigos PHP mal elaborados.

Sobre Apache en dependencia de la configuración del servidor se podría activar el register_globals con la linea "php_flag register_globals 1" al inicio del ".htaccess", pero en
este caso se trataba de un servidor Windows con el IIS como servidor Web.

Finalmente la solución aplicada fue la simulación de register_globals activado, implementado de la siguiente forma:

Primero hacer globales las cookies y variables get y post, esto en /includes/application_top.php:

if (function_exists('ini_get'))
{
 if (!ini_get('register_globals')) {
    if (is_array($_COOKIES))
        foreach ($_COOKIES as $item => $value)
            $$item = $value;
    foreach ($_POST as $item => $value)
        $$item = $value;
    foreach ($_GET as $item => $value)
        $$item = $value;
 }
}

Luego, en el mismo fichero, posterior al inicio de sesión, hacer globales las variables de sesión:

$saved_sessions = array();
if (function_exists('ini_get')) {
 if (!ini_get('register_globals'))
     foreach ($HTTP_SESSION_VARS as $item => $value)
     {
         $$item = $value;
         $saved_sessions[] = $item;
     }
}

Finalmente en /includes/application_top.php y dentro de la función tep_redirect en /includes/functions, antes del redirect, devolver a la sesión los valores cambiados:

foreach ($saved_sessions as $item => $value)
 $_SESSION[$value] = $$value;

Afortunadamente estos cambios fueron suficientes, y el OsCommerce ha funcionado correctamente a pesar de estar desabilitado el register_globals en el servidor.

La idea original de la solución me fue aportada por el desarrollador de Estadísticas Web D4W que la había aplicado anteriormente en la creación de una web de chistes a modo de experimento de posicionamiento y desarrollo web.

El método es aplicable a la mayoría de las webs en PHP que requieren del register_globals para funcionar, aunque debemos recordar que no es una buena práctica el uso de register_globals en el desarrollo de Webs con PHP, tanto por los posibles bugs que afecten la seguridad, como por las limintantes de los servicios de hosting en este aspecto.

Urls canonicas

Todo parece indicar que a pesar de la disminución de afectaciones por urls canónicas que intenta lograr google en este update, esto continuará representando un problema, cuya solución debe pasar a formar parte del know-how de los desarrolladores web.

Basicamente el problema consiste en afectaciones por división de enlaces recibidos y por posibles identificaciones de contenidos duplicados al estar publicados estos bajo direcciones técnicamente diferentes, direcciones a las que los servidores web responden comunmente con la misma página. Ejemplo, las siguientes direcciones:

http://misitio.com
http://www.misitio.com
http://misitio.com/index.php

La solución puede estar a nivel de programación o a través de configuración del servidor Web. A tráves de un post sobre las urls canónicas conocí de un par de referencias sobre la solución del problema de las urls canónicas, en el artículo donde tambien se analiza si es mejor usar o no las www en los URLs.

Independiente de la configuración de los servidores Web, los desarrolladores Web deben ofrecer una solución a este problema de las urls canónicas, lo cual debe formar parte también de los puntos a evaluar para decidirse por un sistema de gestión de contenidos, ya que muchos de estos (así como los foros) usualmente responden con el mismo contenido desde varias direcciones diferentes.

Proteccion de contenidos

Hace unos días un amigo que también se dedica al desarrollo web me comentaba sobre el deseo de evitar un plagio a sus contenidos en la Web, y me pedía información sobre aplicar una protección técnica para evitar la copia.

En este caso se trataba de contenidos disponibles a toda la comunidad en la red, y que además se deseaba mantener su visibilidad ante los buscadores.

Por supuesto, desde el punto de vista que el cliente de la Web es un navegador, no hay mucho que se pueda hacer por una protección del todo eficiente, aunque aun así se puede trabajar con el objetivo a dificultar la copia del contenido al menos ante la mayoría de los usuarios en la red y basarse en esta definición de contenido seguro: un contenido en la red es seguro si el costo de violar su seguridad es mayor a la ganancia obtenida.

Los métodos: desabilitar opiciones del navegador que permitan la copia (las de salvar, menus popup, imprimir, print-screen, etc...), cifrar el código para evitar copia directa, y un grupo de cosas que en otro momento mencionaré como hacer en cada caso particular. Todo esto es posible lograrlo solo a base de JavaScript y algun script de parte del servidor Web.

En este caso quisiera tocar solo el tema de los inconvenientes. Primeramente tenemos el costo de la pérdida de accesibilidad, puesto que si no se puede imprimir, se requiere de JavaScript, probablemente no funcionen todas las características en todos los navegadores, ademas de evitar uso del portapapeles... ummm... pero bueno se trata de proteger, habría que evaluar si realmente se desea pagar este precio en dependencia de cada caso.

El otro aspecto esta en lograr que los buscadores indexen el contenido. La técnica evidente sería usando el User-Agent y mostrarle un contenido no cifrado a los robots de búsqueda (cloaking ?), pero esto es muy fácil de burlar ya que existen herramientas que cambian el useragent además de que los contenidos podrían salir como parte del cache de los buscadores, sin contar con la posible penalización, pues aunque en la práctica se estaría mostrando el mismo contenido a los robots que a personas, técnicamente el código es diferente y es interpretado como cloaking por parte de herramientas automáticas... suficiente, este tipo de protección no es amigable con los robots de busqueda y/o los robots representan un riesgo para esta protección.

Estas protecciones pueden ser por el contrario bien usadas en el caso de aplicaciones Web que desean proteger informaciones determinadas, en especial en el caso de intranets corporativas, pero no es práctico aplicarlas en el caso de contenidos públicos, salvo algunas excepciones como el caso de Google Books (muy bien hecha esta protección por cierto).

Por ahora debemos convivir (y combatir) con el robo de contenidos en la red, pero no son estos tipos de protección de contenidos los métodos más adecuados.