Tag php (Página 40) - Userlinux.net

Como medida preventiva de spam he tenido que implementar captchas en el blog. Por lo de pronto puedo decir que ha merecido la pena puesto que no se ha colado ni un solo comentario spam, pero también he leido quejas al respecto.

Habitualmente la gente se queja de que salta el filtro antispam perdiendo el contenido del comentario, supongo que el motivo es el tipo de fuente o los colores. Tampoco está el mundo como para andar tirando comentarios así que (y a raíz del último comentario de Wu), se me ocurren dos cosas:

• Cambiar tipo de fuente y/o colores.
• Ctrl+C antes de enviar comentario por si las moscas.

Obviamente son dos medidas distintas, una del lado del cliente (podría facilitar la lectura a los spammers) y otra del servidor, por decirlo de alguna forma. Me gustaría saber vuestra opinión sobre el tema.

Actualización
Según vuestras opinines he llegado a la conclusión de que lo mejor es volver a cargar la variable del comentario en el formulario en caso de que los captchas no coincidan, nueva oportunidad y los datos no se pierden (en teoría). A ver qué tal va. Gracias de nuevo por vuestras opiniones.

Siempre quise programar un explorador de archivos/directorios en PHP. Sé que es crítico jugar con el contenido de un disco duro y su visualización vía web, pero sin riesgo no hay adrenalina. La única premisa que me había marcado era un enjaulamiento complicado de saltar, algo así como definir una ruta base de la cual no se podría subir, por seguridad. Esto es lo que ha salido: El File Browser (todavía por bautizar) consta de tres funciones:

Como comentaba en la entrada anterior, he decidido meter captchas en los comentarios de las anotaciones y fotos para prevenir todo el spam que estaba llegando últimamente al blog, no quiero contabilizar el tiempo que he pasado borrando mierda a la vuelta de vacaciones.

Los captcha son una prueba-desafío para determinar cuando el usuario es humano o no, consiste en mostrar una imagen con un texto distorsionado de forma que una máquina no sea capaz de comprender e introducir las letras de forma correcta sin embargo un humano sí podría hacerlo.

Y yo sin saberlo, los hechos han acontecido esta noche, en #lucux de Freenode (ya sabeis, la Asociación de Usuarios de Software Libre de Lugo) a media noche aproximadamante:

Hace algunas entradas pasaba a formar parte de PlanetaBSD, para lo cual tuve que crear un archivo de sindicación adecuado al tema principal del planet. Desde que implementé la sindicación en el blog tenía un par de formatos validados: RSS y RDF, pero ambos abarcaban la totalidad de las entradas de Userlinux.

En un alarde de intuición y falta de ritmo he toqueteado el código de sindicación de rCMS. Ahora los feeds van un poco más formateados de lo que lo iban. Lo que hace conocer las funciones y todos sus argumentos:

<?php strip_tags($resumen, '<p><pre><br /><img><blockquote>'); ?>

La función strip_tags() elimina todas las etiquetas HTML y PHP. Lo que desconocía es que el segundo argumento es usado para las excepciones. Una vez más, la documentación de php a la altura de las circunstancias.

Hoy he leido lo siguiente: ¿Se podría usar nmap vía web?. Aunque sería rizar el rizo, porque normalmente quien tiene acceso a web puede tener de forma sencilla y rápida acceso a una pequeña shell con nmap instalado, se podría usar pero con algún que otro matíz, fijaos en el código propuesto:

<?php
$host = "194.179.1.100";
$archivo = "./nmap.log";
$CADENA = "nmap -P0 ".$host." > $archivon";
shell_exec($CADENA);
$fd = fopen($archivo,"r");
while(!feof($fd))
{
	$scan = fgets($fd);
	echo $scan."n";
}
fclose($fd);
?>

Todavía hay gente que sigue utilizando shell_exec(), exec(), system()... aún sabiendo el riesgo de estas funciones. Pensando en un entorno seguro con servidor web enjaulado, modo seguro (safe_mode=On) y demás previsiones el código rompería por mil sitios antes de devolver un resultado coherente, (obviamente nadie tiene nmap instalado en la jaula de httpd).

He conseguido pasar todos los contenidos, comentarios incluidos, de un formato a medida a otro standard. Para ello me han ayudado un par de funciones una standard utf8_encode y otra a medida: datetime2tstamp.

El uso de la primera es sencillo, se encarga de convertir o codificar un texto pasado por variable de iso8859-1 a utf-8. En su caso datetime2tstamp se encarga de cambiar el formato de una fecha, del típico datetime de MySQL a un timestamp normal y corriente. Aquí van varios ejemplos de uso:

$texto_utf=utf8_encode($texto_iso);

function datetime2tstamp($timestamp)
{
	$year=substr($timestamp,0,4);
	$month=substr($timestamp,5,2);
	$day=substr($timestamp,8,2);
	$hour=substr($timestamp,11,2);
	$minute=substr($timestamp,14,2);
	$second=substr($timestamp,17,2);
	$newdate=mktime($hour,$minute,$second,$month,$day,$year);
	return($newdate);
}
$fecha_timestamp=datetime2tstamp("2005-10-15 20:54:26");

Con esto, un par de conexiones a base de datos, bucles y reemplazos he conseguido salvar todo el contenido, falta categorizar noticias y repasar enlaces rotos.