Script Inside

Antes que nada decir que reemplazar la funcionalidad de las alertas del navegador con código JavaScript nunca es 100 % compatible, por citar un (y el más importante) ejemplo la ejecución del script no se detiene cuando utilizas librerías JavaScript para sustituir alertas. Teniendo en cuenta lo anterior existen 2 opciones para embellecerlas con jQuery, utilizar librerías externas o utilizar los propios cuadros de diálogos de jQuery UI . Si trabajas con esta última librería sería absurdo utilizar otro plugin para recargar aún más nuestro código. Además que muchas de las librerías (como la de jAlert ) no están actualizadas con las últimas versiones de jQuery lo que nos obligaría a utilizar la librería extra de migración . Pero hacerlo con jQuery UI no es tan trivial como parece, hay que tener en cuenta un par de cosas importantes: auto foco, los cuadros de diálogo de jQuery UI tienen el foco puesto automáticamente en el primer elemento enfocable de nuestro html , lo cual puede que no ...

El uso de fechas para cualquier lenguaje de programación es algo básico y en JS, siendo del lado del usuario, su uso, validación e internacionalización es más que importante. El objeto Date de JavaScript es bastante básico y aunque hay clases que extienden sus funcionalidades aún no es suficiente. Para ello existe una librería muy útil llamada momentjs . La documentación esta bastante bien pero aún así hay muchos ejemplos que no me quedan claros. Por ejemplo a la hora de crear un nuevo objeto lo podemos hacer de la siguiente forma: moment(value, "MM/DD/YYYY") o con varios formatos posibles moment(value, ["MM/DD/YYYY", “DD/MM/YYYY”]) Es muy importante que las letras sean en mayúsculas porque el horario se define con letras en minúscula por ejemplo m.format('MM/DD/YYYY HH:mm'), asumiendo que m es la variable resultante del constructor anterior. Se pueden concatenar funciones por ejemplo si queremos validar un campo de un formulario con un formato de ...

Una de las opciones para mejorar la seguridad de nuestro código que planteaba en el post asegurar php desde el archivo de configuración era la de evitar que archivos remotos pudiesen ser abiertos o incluidos desde nuestro código fuente, también comentaba que una de las consecuencias directas era la imposibilidad de utilizar file_get_contents para abrir urls. Después de realizar varias pruebas internas utilizando ambas instrucciones para obtener un json de una página externa a mi sitio veo que no solo es en seguridad que ganamos sino en rendimiento, desde mi código he podido constatar que utilizar curl es de media un 30 % más rápido que llamar directamente a file_get_contents. Haciendo una búsqueda luego de ver estos resultados (que todo sea dicho fueron hechos con una versión de PHP muy antigua la 5.2.1) he encontrado que hay otros usuarios a los que les ha pasado lo mismo y han obtenido resultados muy similares a los míos. La función que utilicé está dentro de una clase con lo cua...

Cuando trabajamos con un sitio que debe estar disponible en  varios idiomas hay múltiples alternativas para traducirlo en PHP pero todas básicamente se basan en incluir un archivo de idioma y sustituir cada frase por su equivalente. Cuando tenemos que traducir un sitio deberíamos plantearnos seriamente la internacionalización del mismo ¿qué es? Básicamente es no solo traducir el texto sino mostrar fechas y configuraciones regionales según el idioma elegido. La mejor herramienta para esto es la extensión de PHP gettext , herramienta que aún no he probado pero que sospecho tendrá un rendimiento más que aceptable y mucho mejor que el resto de opciones que veremos en este post. Lo único malo de esta librería y precisamente será lo que garantice su rendimiento es el uso de la cache para almacenar los idiomas con lo cual cualquier actualización requeriría un reinicio de apache, cosa que en muchos casos no es viable salvo que tengamos un servidor dedicado. Os prometo que intentaré imp...

Tan importante como asegurar y proteger nuestro código PHP es asegurar y proteger el servidor sobre el que corre, en la mayoría de los casos apache. En este fantástico tutorial en inglés nos dan 13 pautas para tener un servidor apache más robusto e incluso algo optimizado. Ocultar las versiones del sistema operativo y de apache. Quitar la posibilidad de listar directorios. Mantener siempre nuestro servidor apache actualizado. Eliminar módulos innecesarios. Tener un grupo y un usuario diferente que corran apache en entornos linux. Restringir el acceso a directorios. Utilizar los módulos security y evasive para evitar ataques de denegación de servicio. En este enlace tenéis como instalar mod_evasive en entornos xampp y en este encontrareis versiones para diferentes compilaciones de apache . No permitir los enlaces simbólicos . Des-habilitar la inclusión del lado del servidor y la ejecución de scripts CGI. Limitar el tamaño de las solicitudes. Protegernos de ata...

El error MySQL server has gone away es bastante común cuando intentamos restaurar nuestra base de datos en otra configuración o a veces cuando ejecutamos consultas que consumen demasiados recursos. Las dos razones más comunes (y sus posibles soluciones) para el error número 2006 son: El servidor agota el tiempo de espera y cierra la conexión EL tiempo de espera de MySQL se gestiona desde la la variable wait_timeout en el archivo de configuración my.cnf. Este valor admite un número entero que representa los segundos que el servidor esperará para terminar una operación. El servidor elimina paquetes incorrectos o demasiado grandes Si MySQL recibe un paquete que es demasiado grande o incorrecto, presupone que algo ha ido mal con el cliente y cierra la conexión. El tamaño de los paquetes que puede gestionar MySQL se puede aumentar gracias a la variable max_allowed_packet , también en el archivo my.cnf. El valor suele ser una cadena con el tamaño que es un número entero y la unidad d...

En el post anterior vimos como podemos establecer las directivas de PHP para cada subdominio , ahora toca asegurar y proteger nuestro código PHP utilizándolo. Voy a remitiros a este fantástico manual en inglés en el cual dan las pautas para asegurar, proteger y endurecer nuestras páginas PHP con directivas de configuración que no vienen habilitadas por defecto. Modo seguro (obsoleto desde PHP 5.4) Restringir los directorios desde donde podremos incluir archivos PHP y trabajar con ficheros (escritura, lectura), en resumen limitar el acceso de PHP al sistema de archivos. Deshabilitar funciones peligrosas como eval. Evitar que se muestre errores en pantalla Deshabilitar register globals (obsoleto desde PHP 5.4) Evitar que archivos remotos puedan ser abiertos e incluidos con PHP, la consecuencia más drástica de esto es que la función file_get_contents no podrá recibir nada con el protocolo http como parámetro, en su lugar deberemos usar curl. Restringir la subida de archi...

Por defecto, los ajustes del archivo de configuración de PHP (php.ini) se aplican a nivel global, por servidor si es dedicado o por usuario si es compartido. Muchas veces es posible que necesitemos sustituir esta configuración predeterminada para un subdominio o subdirectorio, para hacerlo debemos hacer lo siguiente: copiar el archivo php.ini a nuestro subdominio editar o crear un archivo .htaccess e incluir la siguiente línea SetEnv PHPRC. editar el archivo php.ini con las características que queramos. Con estos 3 pasos quedaría configurado un archivo php.ini para nuestro subdominio independiente de la configuración global de PHP pero este archivo sería visible con lo cual debemos protegerlo con el mismo archivo htaccess: <Files ~ "\.ini$"> Order allow,deny Deny from all </Files> Esto denegará cualquier solicitud web a cualquier archivo en ese directorio que termine en .ini; evitando así que la configuración de PHP pueda ser vista por otros. Ahora ...