HTTPS al alcance de todos

Muchas son las ventajas de cifrar toda la información que viaja entre nuestro navegador y los servidores y dos eran los grandes inconvenientes:

  1. El precio de un certificado HTTPS empieza a partir de unos 80€ y para mayores requerimientos los precios pasan de los 200€
  2. El proceso de cifrar y descifrar afectaba al rendimiento.

Estos dos grandes inconvenientes han desaparecido:

  1. Ha nacido Let’s Encrypt, una autoridad emisora de certificados SSL gratuitos sin ánimo de lucro. Detrás está la Linux Foundation, Mozilla Foundation y la Electronic Frontier Foundation, entre otros.
  2. Ya no hay diferencias de rendimiento entre ambos protocolos.

Así que he pasado el sitio a HTTPS:

Certificado SSL

Certificado SSL

No lo he pasado simplemente porque pueda si no que hay tres poderosas razones para ello:

  1. La seguridad, especialmente vía Wifi. Los paquetes irán cifrados, así que puedes validarte con tranquilidad para comentar. También deja de ser posible que te roben la cookie con la que se identifica tu navegador.
  2. La privacidad. Así como lo que haces en Internet no es asunto de otros usuarios de tu red local tampoco lo es de tu proveedor de Internet (ISP) ni de nadie.
  3. Tanto Google Chrome como Firefox mostrarán un mensaje de alerta cada vez que una web no cifrada nos solicite datos sensibles. Además, con el objetivo de que HTTPS vaya reemplazando HTTP, Google penalizará ligeramente en los resultados de búsqueda a las webs no cifradas.
Validacion en web no segura

Validación en web no segura – Firefox

Formulario

Introduciendo la contraseña en una web no segura

Si una empresa hace servir sus servicios estaría bien que donara una parte de lo que se ahorra en certificados a Let’s Encrypt, cuyos gastos mensuales ascienden a 200.000$

Exportar datos a Excel con PHP

Cuando queremos que el usuario pueda exportar los datos desde una aplicación web para poder abrirlos como una hoja de cálculo lo más recomendable es hacerlo en formato CSV (Comma-Separted Values) Ahora bien, hay casos en que el cliente insiste en que desea que se le abra inmediatamente su Microsoft Excel al hacer click sobre el link o botón. En estos casos, cuando generamos el fichero “al vuelo”, la cabecera debe ser:

header('Content-Type: application/vnd.ms-excel');

En vez de:

header('Content-Type: text/csv'; charset=utf-8);

Si los datos contienen caracteres más allá de los primeros 128 ASCII, por ejemplo acentos, al abrirse Excel veremos que estos caracteres no se visualizan correctamente. ¿Por qué? Aunque UTF-8 es de lejos la codificación más usada en la web, y lo más probable es que tu aplicación trabajé con ella, Microsoft Excel sorprendentemente no trabaja con este formato. Los de Redmond pueden haber perdido parte de su poder pero no su idiosincrasia. ¿Cómo arreglar este desaguisado? Pasando los datos a UTF-16LE (Lower Endian) e indicando la codificación en la cabecera, pues con esta codificación sí trabajan. Para lograrlo, PHP dispone de una función para convertir codificaciones: mb_convert_encoding()

El siguiente código de ejemplo deshace el entuerto. En $participations
tenemos los datos a exportar, es un array. En este caso concreto, el código pertenece a una vista y por lo tanto el array ha llegado desde un controlador. El array $header contiene el nombre de cada columna para la hoja de cálculo y $fields contiene los índices de $participations, que coinciden con los nombres de los campos en la base de datos.

<?php

$participations = $render['main']['participations'];
$header = ['NOMBRE1', 'NOMBRE2', 'NOMBRE3', 'NOMBRE4', 'NOMBRE5'];
$fields = ['campo1', 'campo2', 'campo3', 'campo4', 'campo5'];

header("Content-Type: application/vnd.ms-excel; charset=UTF-16LE");
header('Content-Disposition: attachment; filename=participantes_' . makeUrlPhrase($render['main']['bla']['bla']) . '.xls');
header("Expires: 0");
header("Cache-Control: must-revalidate, post-check=0, pre-check=0");
header("Cache-Control: private", false);

$result = implode("\t", $header);
$result .= "\r\n";
if (!empty($participations)):
 foreach ($participations as $part):
  foreach ($fields as $iField):
   $result .= $part[$iField] . "\t";
  endforeach;
  $result .= "\r\n";
 endforeach;
endif;

echo mb_convert_encoding($result, 'UTF-16LE', 'UTF-8');

Como está haciendo servir el tabulador \t para indicar a Excel separación entre campos y el salto de línea \r\n como separación de registros, si creemos que en los datos puede existir alguno de estos caracteres especiales, deberemos escaparlos con la función preg_replace() De lo contrario la hoja no se importará correctamente.

Excel, fuente inagotable de virtudes, tratará campos como fechas, números de teléfono o códigos postales y los procesará para dejarlos inútiles. Por ejemplo, los códigos postales de Barcelona empiezan por cero: 08080. Excel tratará ese dato como un número entero y lo dejará en 8080. Para evitarlo hay que entrecomillar estos datos y una vez más la función preg_replace() acude a nuestro rescate:

if(preg_match("/^0/", $result) || preg_match("/^\+?\d{8,}$/", $result) || preg_match("/^\d{4}.\d{1,2}.\d{1,2}/", $result)) {
  $result = "'$result";
}

Con todo esto conseguiremos que al hacer click el usuario sobre un link, se descargará un fichero que se abrirá automáticamente en Excel y en el que los datos aparecerán correctamente.

En el caso de necesitar más funcionalidades, como por ejemplo añadir gráficas o imágenes a la hoja de cálculo, acabaremos antes si usamos una librería como PhpSpreadsheet en vez de usar nuestro propio código. En caso contrario, si se trata de una mera exportación de datos, implementar la solución con nuestro propio código, teniendo en cuenta lo aquí explicado, será la forma más productiva de proceder.

Los campos meta que Facebook impone

Facebook imponiendo su criterio en la web (todavía libre):

Resultados de la herramienta Sharing Debugger de Facebook al procesar una URL

Pueden deducirse todos todos los valores de otros meta tags pero no le gustan que no sean estrictamente los suyos. Y no son pocos, aquí sólo unos cuantos:

<meta property="og:type" content="website" />
<meta property="og:title" content="Título de la página" />
<meta property="og:description" content="Descripción de la página" />
<meta property="og:site_name" content="bla bla bla" />
<meta property="og:url" content="http://www.bla.com/lang/bla-bla-bla/bla/" />
<meta property="og:image" content="http://www.bla.com/images/bla/1/bla.jpg" />

Y si no quieres tener problemas con la visualización de la imagen al compartir no te olvides de añadir el height y el width:

<meta property="og:image:width" content="400" />
<meta property="og:image:height" content="47" />

¿Esto es un estándard? ¿De dónde lo han sacado? Por si fuera poco, Twitter usa otros y Google+ también requiere otros. Por un lado tenemos a Facebook intentando imponer su criterio como estándar… ¿De qué me suena esto? Por otro desarrolladores dedicando tiempo (que alguien pagará) implementando estos meta tags. Y por otro se incrementa la cantidad de datos a descargar. Sin duda tienen músculo suficiente para permitirse estas licencias.