Protege tu .git

Hasta hace poco en mi empresa utilizábamos subversion como repositorio, no somos un equipo grande y las funcionalidades que nos ofrecía el repositorio eran suficiente para nuestros proyectos.
Recientemente, debido a que un cliente nos ha impuesto utilizar git como repositorio principal y dado que nuestra relación con ellos es muy importante, decidimos mover todos nuestros repositorios a git. Tampoco es que vayamos a utilizar extensivamente las ventajas que nos ofrece, pero si que nos obligaría a funcionar de manera más fluida con una herramienta que vamos a necesitar si-o-si.

El caso es que, en nuestra anterior configuración, utilizábamos subversion para mantener el código de producción de algunas webs y al modificar el repositorio hicimos lo propio con git, teniendo una «feliz transición». El problema vino en que, realmente, no eramos conscientes de las diferencias reales que tenían los dos repositorios y dentro de los directorios servidos junto a la web en cuestión se encontraba el directorio .git.

¿Qué significa esto? Pues ni más ni menos que todo el mundo mundial tiene acceso a tu repositorio local y puede, entre otras cosas, acceder a todo el código de lo que hay allí publicado… Y eso no puede ser. ¿Qué hacemos para evitarlo?

Hay varias formas de hacerlo, dependiendo de si tienes o no un .htaccess en tu web o no y de la configuración de tu servidor, en mi caso la solución que implementamos fue añadir las siguientes líneas al archivo de configuración de cada web:

        <Directory /directorio.de.la.web/.git>
		Options FollowSymLinks
		AllowOverride All
		Require all denied
	</Directory>

Esto indica al servidor que todo lo que hay bajo el directorio .git no está autorizado para ser visto… Reiniciamos el servidor o recargamos la configuración y ya tendremos el problema resuelto.

Y con esto y un bizcocho… Podemos empezar nuestra semana.

¿Seguridad en la red?

Lo digo muchas veces, pero yo ya soy viejuno en esto de internet. Mi primera cuenta de correo electrónico me la abrieron en 1989 (si, la web no se había inventado todavía) y tuve la suerte de ser el administrador de la red del laboratorio de investigación en el que estaba estudiando, lo que me dió la oportunidad de configurar y usar las news de internet (a alguno ya ni les sonará). El caso es que llevo el tiempo suficiente surfeando la ola de internet como para tener una perspectiva amplia en esto de «la red».

El caso es que ayer llegó a mis oídos la noticia Mother of All Breaches Exposes 773 Million Emails, 21 Million Passwords, que viene a decir que se ha encontrado una colección de archivos que recopilan 772.904.991 direcciones de correo y 21.222.975 passwords distintos. ¿Qué significa esto? Básicamente que si no has cambiado tu contraseña durante mucho tiempo en alguno de los servicios menos seguros de la red (aquellos que hayan tenido alguna fuga de datos) es casi seguro que cualquiera pueda saber cual es tu contraseña. De hecho, las últimas noticias indican que ese archivo es parte de un conjunto más grande con 1TB de contraseñas….

Hace unos años esto no sería mayor problema, la contraseña era una cosa que nos forzaban a elegir y que, en el mejor de los casos, nosotros seleccionabamos de una manera «regular», siempre la misma que creíamos segura, una variación de esa contraseña segura o lo primero que se nos pasaba por la cabeza y que terminábamos apuntando en un papel, total, ¿quién va a querer acceder a mis datos? Pero hoy en día la cosa ha cambiado muchísimo. La mayoría de nosotros ya no vamos al banco, sino que operamos via internet, compramos cada día en internet por más y más cantidad, pedimos las citas para el médico, compramos las entradas para el cine, los viajes, alquilamos las vacaciones… Y todo ello utilizando las contraseñas a las que, desgraciadamente, hemos prestado tan poca atención.

El principio básico en que se basa toda nuestra vida digital es que nosotros podemos almacenar en nuestro cerebro las contraseñas que necesitemos, pero eso ya no es válido. Cada día usamos más contraseñas de más servicios y eso hace físicamente imposible que las memoricemos… ¿hay solución?

Ninguna 100% fiable. Los gestores de contraseñas tradicionales (1password, dashlane, etc.) utilizan bases de datos centralizadas que son, como poco, golosinas demasiado irresistibles para los hackers y se convierten en destino de ataques que ya han conseguido éxito alguna que otra vez. Por eso, y hasta que se encuentren métodos más seguros para autorizarnos a acceder a nuestros servicios se me ocurrió construir nomorepass. El único servicio que mantiene seguras las contraseñas en el móvil y no las almacena en ninguna base de datos central. Además, te da todos los medios para que no tengas que teclear esas contraseñas nunca… Lo que te permite tener contraseñas seguras, distintas y sin tener que recordarlas.

En serio, tenéis que probarla. A mi me ha solucionado el problema de las contraseñas para siempre… Y, además, no tienes que fiarte de nadie porque nadie tiene tus contraseñas.

Construyendo un dispositivo inteligente con nodemcu y un display OLED

Últimamente se están poniendo de moda los dispositivos «inteligentes» que, básicamente, consiste en cacharros que están conectados de una manera o de otra a internet o a nuestra red doméstica y que aceptan comandos desde la red para controlar sus distintas funciones.

La verdad es que han bajado mucho de precio y el poder controlarlas desde los distintos asistentes de voz le dan un extra adicional. He trasteado un poco con Alexa y con Google Home, pero todavía estoy en el proceso de encontrarle el sitio correcto. En cualqueir caso, como soy un alma inquieta he preferido ver cuanto me costaba crear mi propio «dispositivo inteligente» con los materiales que tenía a mano… Esto es lo que he usado:

  • Pantalla OLED de 1,3″ con el chip SSH1106 de 128×64. En concreto esta.
  • Una placa Weimos D1 mini (compatible), que se basa en el chip ESP8266. En concreto esta.
  • Un relé preparado para 5V. En mi caso este.

El chip ESP8266 es una maravilla que integra wifi junto con un microcontrolador que puede ser programado desde el IDE del Arduino (entre otras formas) y el empaquetado en forma de placa nocemcu hace que sea muy sencillo hacer proyectos con este, siendo más barato y más potente que un arduino habitual. De hecho los componentes de este proyecto comprados en aliexpress (quitando cables y gastos de envío) no suman más de 6 Euros… Irresistible para montar un prototipo.

Al lío… Es esquema de conexiones es este:

En realidad el pulsador no hace falta, lo he incluido para poder comunicar al dispositivo manualmente el cambio de estado (es un rollo tener que hacerlo todo en remoto) y no es necesario para la primera versión.

Para poder programar la placa desde el IDE del Arduino vamos a tener que ir a la sección de Archivo->Preferencias y añadir la url http://arduino.esp8266.com/stable/package_esp8266com_index.json en el campo Gestor de URLs Adicionales de Tarjetas, quedando como en la imagen:

Luego nos vamos a Herramientas->Placas->Gestión de tarjetas y buscamos ESP8266 e instalamos la versión de ESP8266 Community.

Con esto ya nos aparecerá el tipo de tarjeta Wemos o NodeMCU en la lista de tarjetas que podemos conectar con el IDE.

Lo siguiente es encontrar una librería que nos permita interactuar por I2C con nuestra pantalla (y que sea lo más flexible posible para usos futuros). Esto es lo que me llevó más tiempo, básicamente porque los ejemplos que proporcionan están preparados para otro chip y la nomenclatura de los pines es diferente… Al final la mejor es esta:

https://github.com/ThingPulse/esp8266-oled-ssd1306

Yo he usado como base el ejemplo que viene al instalar la placa y se llama WIFIServer (creo que lo han cambiado por una versión nueva, os dejo el código completo al final de todas formas). El funcionamiento es de tal manera que al arrancar se conecta a la red wifi que tengamos configurada y queda esperando conexiones, cuando recibe una petición https://server_ip/gpio/0 ponemos a cero el GPIO2 y si recibimos una https://server_ip/gpio/1 lo ponemos a 1… Como esa salida la tenemos conectada al relé, pues ya podemos encender o apagar lo que queramos desde la web.

Para sacar la información por la pantalla, básicamente, utilizo la función drawString que me imprime en las coordenadas dadas de la pantalla una cadena (y en la fuente que hayamos seleccionado antes)… Podéis verlo en funcionamiento en este video:

Os pongo el código antes de integrar lo del botón… Básicamente lo que falta por poner es que cuando detectemos una pulsación del botón (D3 pase a cero) cambiemos el estado del pin conectado al relé (así tenemos control manual, cosa que echo de menos en las bombillas inteligentes, por ejemplo).


#include <ESP8266WiFi.h>
#include "SH1106Wire.h"

const char* ssid = "tussid";
const char* password = "tupassword";

SH1106Wire display(0x3c, 4, 5);

WiFiServer server(80);

void setup() {
 
  Serial.begin(115200);
  delay(10);

  pinMode(2, OUTPUT);
  digitalWrite(2, 0);
  
  Serial.println();
  Serial.println();
  Serial.print("Connecting to ");
  Serial.println(ssid);

  display.init();
  display.flipScreenVertically();
  display.setFont(ArialMT_Plain_10);

  display.clear();
  display.setTextAlignment(TEXT_ALIGN_LEFT);
  display.drawString(0,0,"Connecting...");
  display.display();
      
  WiFi.begin(ssid, password);
  
  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");
  }
  Serial.println("");
  Serial.println("WiFi connected");
  
  display.clear();
  display.drawString(0,0,String(ssid));
  display.drawString(0,10, "IP: "+WiFi.localIP().toString());
  display.display();
    
  // Start the server
  server.begin();
  Serial.println("Server started");

  // Print the IP address
  Serial.println(WiFi.localIP());
}

void loop() {
  WiFiClient client = server.available();
  if (!client) {
    return;
  }
  
  Serial.println("new client");
  while(!client.available()){
    delay(1);
  }
  
  String req = client.readStringUntil('\r');
  Serial.println(req);
  client.flush();
  
  int val;
  if (req.indexOf("/gpio/0") != -1)
    val = 0;
  else if (req.indexOf("/gpio/1") != -1)
    val = 1;
  else {
    Serial.println("invalid request");
    client.stop();
    return;
  }

  digitalWrite(2, val);
  display.setColor(BLACK);
  display.fillRect(0, 26, 100, 10);
  display.setColor(WHITE);
  display.drawString(0,26,"GPIO: "+String(val));
  display.display();
  
  client.flush();

  String s = "HTTP/1.1 200 OK\r\nContent-Type: text/html\r\n\r\n<!DOCTYPE HTML>\r\n<html>\r\nGPIO is now ";
  s += (val)?"high":"low";
  s += "</html>\n";

  client.print(s);
  delay(1);
  Serial.println("Client disonnected");
}

Si habéis leido el código veréis que hay algunas cosas que se hacen de más, por ejemplo, pintamos un rectángulo en negro para borrar la línea antes de pintarla de nuevo con el valor del GPIO. Eso es debido a que esta librería está pensada para borrar la pantalla cada vez que la actualicemos y, por eso, no limpia el hueco en el que va a escribir (igual podemos hacer un fork que lo solucione, ya veremos) y sin esa limpieza las letras se escriben unas encima de otras.

Una nota final… El servidor no envía cabeceras CORS, por lo que si vais a utilizarlo desde javascript en cualquier otro servidor os saltará un error en la consola (y en mac ni siquiera hará la llamada real), en linux y windows funcionará aunque no recibiréis la respuesta.

Sigo modificando el código y demás a ver qué termino consiguiendo… Hasta es posible que le diseñe un PCB… Ya os iré contando.

No me extraña nada que apple se vaya al carajo

No voy a hablar sobre la coyuntura de ventas o innovación de la empresa de los iphone, no, de eso ya se encargan otros que saben mucho más que yo y, además, siempre he creído que apple no merecía ser la empresa con mayor capitalización bursatil del mundo… Pero, la verdad, no me extraña que se termine yendo al carajo.

El caso es que estamos haciendo una aplicación móvil para un cliente, que ya tenemos en beta en la play store y que, por supuesto, queríamos tener en beta también en la app store. Así que, al día siguiente de subir la versión android, generamos la versión ios (después de miles de problemas con certificados y perfiles de desarrollo que nadie entiende) y la subimos a itunesconnect. La ponemos como disponible para betatesting con TestFlight (mucho más limitado que la versión beta de Android, pero es lo que hay) y nos exigen una revisión por su parte.

Esperamos pacientemente y nos encontramos esto (literal, que es un pantallazo):

En resumen, que Apple considera que nuestra app no tiene suficientes funcionalidades y no nos la aprueba ni para beta testing… ¡Ole sus huevos!

Así no me extraña que la gente termine asustada por la dependencia brutal de cualquier desarrollo con la tienda y sus revisores de mierda… Y es que, aunque se mueva más dinero en esa plataforma, el desarrollador está completamente indefenso ante las arbitrariedades de la empresa.

NOTA: al final, tras un proceso de revisión adicional, han accedido a que podamos hacer el beta testing… Eso si, de una versión que ya es vieja con respecto a la de Android.. :-(