On making stuff with code. And making code to do stuff.
HTTP redirects should be your tool of choice when you’re reorganizing or renaming key sections of your site on order to keep visitors from hitting a not found page and make search engines update their location and keep their ranking.
However, sometimes you might run into a situation when you need to update a redirect, only to find out that the redirection it’s aggressively cached by your browser (specially Chrome).
So, how can you avoid (or at least, control) the way that redirects are cached?
Basic Authentication it’s often used as a simple security measure or as a temporary authentication method while developing with certain APIs.
While the WordPress HTTP API doesn’t have explicit support for basic authentication, it’s still possible to use it as a header:
$request = wp_remote_post(
$remote_api_endpoint,
array(
'body' => array( 'foo' => 'bar' ),
'headers' => array(
'Authorization' => 'Basic '. base64_encode( $username .':'. $password )
)
)
);
Remember that if you’re sending an unencrypted request, all the headers will be sent in plain text, so you should only use it over HTTPS.
A client let us know that the server where her company’s site was hosted had an unusually high load.
After checking the access log for the web server, it was clear that the cause was repeated access attempts at a single URL, which was not essential to the site. So I though this should be easy, I’ll just block the request in the web server config. Unfortunately, they were using a very outdated version of lighttpd, so it wasn’t that easy.
It seems that older lighttpd builds had several bugs with mod_access, but the worst in our case was that instead of blocking the request and send a 403 Forbidden, it passed the request on to the 404 error handler, and this loaded the entire app enviroment.
So here’s what I did. The lighttpd config looked like this:
$HTTP["url"] =~ "^/foobar.php" {
url.access-deny = ("")
server.error-handler-404 = "/403.php"
}
… so request to foobar.php would be handled by 403.php. And then, 403.php:
<?php header('HTTP/1.0 403 Forbidden'); ?>
<h1>Forbidden</h1>
Very silly, but effective. Just because status codes matter.
En la parte final (por ahora) de esta serie sobre Optimización de respuestas AJAX vamos a revisar cómo utilizar técnicas de caché permanente, o lo que se debería denominar más correctamente caché-que-se-controla-desde-el-servidor — lo que complementa a la parte anterior sobre “caché volátil” o caché-que-se-controla-desde-el-cliente.
Hace un par de publicaciones atrás, explicaba cómo configurar un certificado SSL autofirmado para la administración de WordPress, y señalaba la dificultad de comprobar la integridad de la comunicación entre el cliente y el servidor debido a que un certificado autofirmado no está validado por una autoridad de certificación comercial, como las que se incluyen entre los certificados aceptados por los navegadores más populares.
Aunque por una parte esto podría entenderse como una ventana abierta para ataques de man-in-the-middle, lo cierto es que es posible eliminar el riesgo de este tipo de ataques al utilizar un certificado autofirmado siguiendo un procedimiento relativamente sencillo.
Continue reading “Cómo usar un certificado SSL autofirmado de forma segura”