Reescribe condiciones de Apache dependientes de la hora

ByLuis

Cuando queremos redirigir mediante Apache se puede realizar teniendo en cuenta la hora y los minutos actuales. Tieniendo en cuenta que las horas son en formato 24 y que empieza por 01 para la 1 am y 24 para las 12 pm, podemos redirigir nuestra página según sea la hora y el minuto.

RewriteCond %{TIME_HOUR} ^(.*)
RewriteCond %{TIME_MIN} ^(.*)
RewriteRule (.*) http://${HTTP_HOST}%{REQUEST_URI}?H=%1&M=%2 [R,L]

Si se da el caso de que el servidor está ciertas horas de retraso respecto a tí, por ejemplo 3, se podría hacer de la siguiente manera:

Options +FollowSymLinks
RewriteEngine On
RewriteBase /demo/apache/
# 5am > < 8am
RewriteCond %{TIME_HOUR} >02
RewriteCond %{TIME_HOUR} <05
RewriteRule ^index.html$ /demo/apache/manyana/index.html
# 8am > < 4pm
RewriteCond %{TIME_HOUR} >05
RewriteCond %{TIME_HOUR} <13
RewriteRule ^index.html$ /demo/apache/mediodia/index.html
# 4pm > < 10pm
RewriteCond %{TIME_HOUR} >13
RewriteCond %{TIME_HOUR} <19
RewriteRule ^index.html$ /demo/apache/tarde/index.html
# 10pm > < 5am
RewriteCond %{TIME_HOUR} >19
RewriteCond %{TIME_HOUR} <02
RewriteRule ^index.html$ /demo/apache/noche/index.html

Using TIME_HOUR and TIME_MIN RewriteCond in htaccess

Similar Posts

Limita el tamaño de ficheros a subir mediante Apache

ByLuis

El otro día una amiga me escribía bastante agobiada preguntando cómo se podía saber mediante Javascript el tamaño de un fichero que se quería subir, porque si superaba cierto tamaño, no se debía permitir que se subiera (antes de que se intente mandar). Mi respuesta fue un “no se puede hacer desde el cliente” (espero no haberme equivocado).

El problema que tenía es que le obligaban a que fuera en el navegador, supongo que o el cliente (cabezón) o el analista/jefe (más cabezón aún). La solución, que creo que no aceptaban era controlarlo mediante Apache: se añade en el fichero .htaccess la siguiente directiva y ya no hay problemas:

LimitRequestBody tamaño

Siendo tamaño el número de bytes que ponemos como límite para subir ficheros.

A parte de este ejemplo, mi pobre amiga siempre anda enmarronada con peticiones increibles. Por ello, dos consejos:

  • No dejéis que el cliente imponga lo que le venga en gana, hay cosas que no se pueden/deben hacer y por mucho que se empeñe, seguirán sin poderse/deberse hacer. Entre ellas, siempre se comprueban las cosas en el servidor, nunca únicamente en el cliente, sobre todo por temas de seguridad.
  • El elemento input file es tal cual es, no se le puede cambiar el texto del botón, ni aplicarle filtro, ni que te vaya a la carpeta que quieran, ni cambiar el diseño de la ventana, ni modificar mediante Javascript el fichero que se quiere seleccionar. Aunque parezca mentira siempre acaban pidiéndonos alguna de estas cosas.

Pido disculpas si esta entrada no es la típica, pero es que las tonterías del cliente acaban sacándote de quicio.

mod_qos: prioridades para peticiones en Apache

ByLuis

QoS (calidad del servicio) se trata mecanismos de control para proveer diferentes prioridades a diferentes usuarios, aplicaciones y conexiones, realmente es más gestión de recursos que calidad del servicio. Cuando queremos limitar el uso de Apache y dar prioridades a diferentes peticiones podemos usar mod_qos.

Ofrece mecanismos para gestionar:

  • Número máximo de peticiones concurrentes a una URL o a un dominio virtual.
  • Limitación del ancho de banda, ya sea por número de peticiones por segundo o kilobytes por segundo.
  • Posibilidad de detectar usuarios especiales que no sufriran las restricciones o lo harán en menor grado.
  • Denegar operaciones no autorizadas
  • Limitaciones en el nivel TCP, por ejemplo el número máximo de conexiones permitidas desde una IP.

mod_qos

Vía / Apache-es

|

Simular dominio en localhost con Apache

ByLuis

Una cosa que siempre me ocurre cuando estoy trabajando en mis propios proyectos, es que me creo una carpeta para cada uno de los proyectos dentro del raíz (root) y no puedo usar paths absolutos ya que en el servidor real no usaré ese directorio.

Por ejemplo, estoy creando un nuevo proyecto llamado proyecto1 y para trabajar en local tengo la ruta siguiente: http://localhost:8080/proyecto1, pero cuando lo suba al servidor, será http://proyecto1.com. Voy a tener problemas si quiero usar los paths sean absolutos (“/imagenes/fondo.png”), porque en local debería tener antes el directorio del proyecto (“/proyecto1/imagenes/fondo.png”). Lógicamente, no puedo estar trabajando con paths relativos y luego pasarlos a absolutos cuando lo suba al servidor, puedo liar una buena.

¿Qué solución me queda?, pues una de ellas es la que uso desde hace tiempo, quizás no la más limpia, pero si es bastante sencilla.

Primero tengo que acceder al fichero hosts, que suele encontrarse en la ruta C:\windows\system32\drivers\etc, y añadir la siguiente línea:

127.0.0.1 proyecto1

Con esto lo que conseguimos es que se reconozca el dominio proyecto1 como nuestra propia máquina (127.0.0.1).

Y lo siguiente que tenemos que hacer es modificar el fichero de configuración de Apache (httpd.conf) e incluir el nuevo host.

NameVirtualHost proyecto1:8080
<VirtualHost proyecto1:8080>
DocumentRoot "C:/proyectos/proyecto1"
ServerName proyecto1
</VirtualHost>
<Directory "C:/proyectos/proyecto1">
Allow from all
</Directory>
| |

Protege tus imágenes con Apache

ByLuis

Una de las cosas más molestas con las que te puedes encontrar al mantener un sitio, es ver cómo tus imágenes estan siendo utilizadas en otros sitios que las enlazan directamente a tu servidor, esto es molesto por dos motivos, evidentemente el uso de material gráfico de tu propiedad sin tu consentimiento, y la carga extra que sufre la conexión de tu página.
Para los que usamos Apache existe una fácil solución combinándolo con mod_rewrite, el método se basa en crear un fichero .htaccess que contenga una serie de reglas, que literalmente le indicarán al servidor que las imágenes solo se mostrarán si la petición viene del dominio propio.
Las reglas a añadir son las siguientes. Solo tendrás que sustituir el texto example.com por el nombre de tu dominio:

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?example.com/?.*$ [NC]
RewriteRule \.(gif|jpg|jpeg|png|mp3|mpg|avi|mov)$ - [F,NC]
| | | |

Cómo decir a Google que vuelva por nuestra página más tarde

ByLuis

Cuando tenemos nuestra página en mantenimiento y el motor de Google (Googlebot) u otro motor de búsqueda, se pasa por nuestra página para indexarla, no es correcto que obtenga una página no encontrada (404) o un error del servidor (500).
Según dicen en Google Webmaster Central lo correcto es mandar un código de red no disponible (503), pero el autor de este post recomienda también enviar un Retry-After para que vuelva a pasarse más tarde. También recomienda que a los motores de búsqueda se les envie a una página 503 y a los visitantes (menos a él) a una página 404 (página no encontrada).
Instruct Search Engines to come back to site after you finish working on it

Laboratorio: Proteger ruta virtual mediante Apache

ByLuis

En otras ocasiones hemos comentado como proteger directorios mediante Apache, incluyendo en el .htaccess los comandos necesarios para ello. El problema viene cuando en vez de proteger una ruta física, queremos proteger un URL virtual, entendiendo URL virtual, aquella que no existe físicamente y que mediante Apache redireccionamos a un script en concreto, por ejemplo:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteBase /
RewriteRule ^clientes index.php?redirect=clientes [QSA,L]

En este caso, si accedemos a http://servidor/cliente, realmente no estaremos accediendo a una ruta física, pero puede ser que queramos que esta url no sea accesible para todo el mundo.

Para proteger una URL virtual debemos usar el comando Location, el cual debemos incluirlo en el httpd.conf o en un dominio virtual, y para protegerlo deberemos usar:

<Location /client>
AuthType Basic
AuthName "Acceso Protegido"
AuthUserFile [ruta .htpasswd]
AuthGroupFile /dev/null
order allow,deny
allow from all
deny from none
require valid-user
</Location>