Archivo por meses: noviembre 2019

La insoportable dependencia de las tiendas de aplicaciones

Posted on por
Responder

El avance imparable de la informática en todas las áreas nos ha creado nuevos problemas a los desarrolladores, no ya el hecho de tener que conocer nuevas herramientas cada mes, o nuevos frameworks de desarrollo que tardas más tiempo en aprender que el que te ahorras, sino la pérdida completa del control de lo que tus usuarios pueden instalarse, dónde y cómo. Os pondré un ejemplo.

NoMorePass es una aplicación móvil de la que os llevo hablando bastante y que desarrollamos nosotros; a nivel básico consiste en la app y un conjunto de extensiones para los navegadores que nos permiten intercambiar las contraseñas mediante un código QR. La app ahora mismo tiene su máxima utilidad cuando se usa desde la extensión. Desarrollar una extensión para navegador no es especialmente complicado, como ya os expliqué en esta entrada, probarlas tampoco es difícil con el modo desarrollador de los navegadores, pero una vez que la tenemos lista tenemos que pasar por un infierno inesperado… Ponerla a disposición del público.

Antes se podía distribuir un archivo empaquetado que al abrirse permitía instalar la extensión, pero esa forma de distribuir extensiones se volvió peligrosa (a pesar de que los navegadores preguntaban muchas veces si de verdad querías instalar eso) y Google decidió que para chrome solo se podían instalar extensiones que pasasen por su tienda de aplicaciones el chome web store. Firefox, por su parte, no lo hace obligatorio por el momento, pero la mejor manera de que una extensión se conozca es tenerla en la página de add-ons de firefox. Lo mismo pasa con Opera (aunque esta es otra odiséa que ya os contaré) y, hasta el momento, con Edge.

No tengo nada en contra de las tiendas de aplicaciones mientras estas funcionen de manera ágil y razonable. A efectos prácticos se convierten en cuellos de botella que pueden afectar en gran medida a la forma en la que se produce la distribución de los productos. Como ejemplo valga lo que me ha pasado en las últimas semanas con la extensión de chrome.

El día 19 de noviembre terminé de desarrollar una mejora a la extensión que había en la tienda, pasaba de la versión 2.1.1 a la 3.0.0 y tras probarla en local y funcionando perfectamente intenté subirla al web store… Se quejó que de que pedía demasiados permisos (cosa que no hizo con la versión anterior) y modifiqué la extensión para que funcionase sin necesidad de pedirlos, generé una nueva versión y la subí a toda prisa… Tanta prisa que se me coló un bug que impedía que funcionase el botón derecho (una funcionalidad que se usa mucho cuando la web no está reconocida o queremos rellenar un formulario con una contraseña que tenemos)… Me di cuenta de ello minutos después de haber «publicado» la versión y cuando intenté subir la versión corregida veo que NO ME DEJA... Dice que la extensión está pendiente de revisión y no se puede enviar otra versión. WTF!!!

No había mucho problema, la versión anterior funcionaba perfectamente y las nuevas funcionalidades podían esperar… Así que esperé ¡¡5 DIAS!! a que Google pasara a producción la versión con el bug un sábado por la mañana… Inmediatamente subí la nueva versión (que solo tiene 2 líneas de código distintas con la versión anterior) esperando que se aprobase inmediatamente y que los clientes no tuviesen que sufrir el bug… Pero no, volvieron a poner en revisión la nueva versión y en esas estamos, llevamos ya 4 días con la versión defectuosa de la extensión y con clientes que ya se han quejado… Y no podemos hacer nada, Google nos ha jodido y no nos da ninguna pista de cuando se publicará de verdad la nueva versión.

No hay nada que podamos decir a los clientes, no hay forma de volver a una versión antigua si tenías la auto-actualización de las extensiones (google no guarda las versiones viejas) y no hay forma de acelerar el proceso de publicación. Tampoco hay forma de hablar con Google (he mandado múltiples formularios de contacto con un sonoro silencio por respuesta), tampoco puedo dar un método alternativo para instalar la extensión porque Google obliga a usar su tienda si-o-si, así que no queda más que esperar a que se publique finalmente la nueva versión y disculparnos ante los clientes y asumamos las pérdidas que esto nos pueda ocasionar como algo inevitable… Muy mal google.

ACTUALIZACIÓN 1: 28/11/2019 Google ha leído este post y ha decidido ir un paso más adelante, nos ha RECHAZADO la extensión por pedir más permisos de los que necesitamos (cuando la anterior versión pedía exactamente los mismos)…

Nada, nueva versión pidiendo menos permisos (v3.0.2) y a esperar otros cuatro días (con suerte)…

Me han hackeado el Spotify!

Posted on por
Responder

Bueno, realmente a mi no, ha sido a mi hija, ¿pero qué leche? si lo estoy pagando yo también es mío, ¿no?… Como soy un poco vago os reproduzco el hilo de twitter que mandé ayer para que os hagáis una idea:

Ejemplo práctico, de ahora mismo, de porqué es tan malo poner la misma contraseña en sitios distintos… Dentro hilo..

Esta mañana mi hija me ha mandado un whatsapp diciendo que alguien estaba cambiando la música de su spotify y que no podía oir nada de lo que ella ponía… raro.

Al rato me manda pantallazo del correo que ha recibido

Eso ya es indicio claro de que alguien ha entrado en su cuenta y ha cambiado el correo y, obviamente, la contraseña… En este momento estamos pagando el servicio a una persona que no conocemos.

Y que tiene unos gustos musicales pésimos además.

Después de momentos de desconcierto acertamos a dar con el chat de soporte de spotify que, tras pedirnos copia de los justificantes de pago y alguna cosilla más nos devuelve la cuenta. Bien por @SpotifySpain

Para saber lo que ha pasado, le pregunto si usaba la misma contraseña en otros sitios, me dice que si, compruebo en https://haveibeenpwned.com si su email estaba comprometido y… bingo.

Había otros cuatro sitios en internet donde se registro con la misma contraseña que habían sido comprometidos y, probablemente, de uno de ellos haya salido la contraseña que han usado.

Remedio inmediato: usar @nomorepass_ para generar nuevas contraseñas diferentes y cambiarlas en todas partes.

Por eso, amiguitos, nunca debéis usar la misma contraseña (ni ninguna variación simplona de la misma) en ningún sitio… Y, por supuesto, como no vas a poder recordar las contraseñas, usa nomorepass

Montar un wordpress con docker

Posted on por
Responder

Si, esta es una receta muy sencilla y muy rápida. Quizá no sea perfecta, pero en caso de que quieras montar un servidor wordpress sin preocuparte de instalaciones y milongas, este es el método.

Voy a suponer que ya sabes lo que es docker y docker-compose, es más, voy a dar por hecho que los tienes instalados en el servidor donde quieres instalar wordpress, si eso no es así vete disparado a google y búscalo (me lo agradecerás).

Vamos a hacer una instalación donde la base de datos y los archivos de wordpress estén en directorios de la misma máquina y no dentro del contenedor, de manera que podamos reiniciar y actualizar los contenedores preservando los datos. Para ello creamos una estructura haciendo algo similar a esto (pongo como se hace en linux):

mkdir wordpress
cd wordpress
mkdir db
mkdir archivos
mkdir docker
cd docker

Ahora viene lo bueno, creamos dentro del directorio docker el archivo docker-compose.yml con este contenido:

version: '2'
services:
  db:
    image: mysql:5.7
    volumes:
      - "../db:/var/lib/mysql"
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: wordpress
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: wordpress

  wordpress:
    depends_on:
      - db
    image: wordpress:latest
    links:
      - db
    ports:
      - "80:80"
    volumes:
      - ../archivos:/var/www/html
    restart: always
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_PASSWORD: wordpress

Y con esto ya tenemos todo el pescado vendido. Nos metemos en el directorio docker (donde está el docker-compose.yml) y ejecutamos:

docker-compose up -d

Puedes comprobar que todo está funcionando en cualquier momento con el comando docker ps 

CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                 NAMES
 18b4c06458b7        wordpress:latest    "docker-entrypoint.s…"   36 seconds ago      Up 32 seconds       0.0.0.0:80->80/tcp    docker_wordpress_1
 211c0832d549        mysql:5.7           "docker-entrypoint.s…"   39 seconds ago      Up 35 seconds       3306/tcp, 33060/tcp   docker_db_1

Ahora, para instalar, de verdad, el wordpress debemos conectar a http://localhost y podremos comenzar la instalación:

Y después de poner todos los datos tendremos un wordpress funcional en el puerto 80, con el añadido de que para realizar un backup solo tenemos que parar los contenedores y copiar los directorios db y archivos (o llevárnoslos a otro servidor).

Hay muchas mejoras que hacer si queremos que esto esté listo para producción como, por ejemplo, hacer que vaya por https (para eso lo mejor es poner un proxy inverso), pero ya lo veremos un poco más adelante. Por ahora, si queréis parar los servicios solo tenéis que ejecutar, desde el directorio docker la instrucción:

docker-compose stop

Y, lo bueno, es que tu máquina no ha sufrido ningún cambio de configuración ni ha instalado ningún paquete de más… Todo ventajas.