Https está conceptualmente roto

[andresmanelli]

Se tienen que implementar los dos, en http y en https. Y se sirven los dos.

[fcladera]

Ese título es más pro haha.

Algunos comentarios al respecto:

• Es mejor que el server, en la etapa de desarrollo, se sirva por http.
• Idealmente el usuario debería poder elegir si quiere servir por http o https. Además, idealmente no debería crearse un certificado self-signed, el usuario debería poder configurar el servicio en algún archivo de configuración en donde especifique la dirección de los certificados. A modo de ejemplo, en nginx es así

server {
    listen              443 ssl;
    server_name         www.example.com;
    ssl_certificate     www.example.com.crt;
    ssl_certificate_key www.example.com.key;
    ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers         HIGH:!aNULL:!MD5;
    ...
}

Ese es el archivo de configuración, en donde se puede especificar si hay que escuchar en el puerto 80, o en el 443 ssl. Además se especifican los certificados. Los ciphers y protocolos es ya un lujo, eso permite usar configuraciones de ssl que son seguras (cada tanto se descubren vulnerabilidades en cyphers o protocolos viejos y así pueden desactivarse).

• Finalmente, una última opción es que el server redirija las peticiones de http a https. Eso puede hacerse respondiendo un 301 o usando HSTS.

[andresmanelli]

El tema de nginx se puede agregar o tiene que incluirse por el admin del host, fuera de este repo? Porque si con eso solucionamos todo el tema de puertos y direcciones y certificados que tenemos, podríamos apuntar a un PR que arregle eso no? De por sí eso de poner :3000 en el navegador no está bueno

[fcladera]

No, el archivo de Nginx lo puse a modo de ejemplo. Lo que quiero mostrar es como se configura un servicio cualquiera en Unix, y que nuestro proyecto debería ser similar a eso. En ese archivo uno le puede decir a Nginx si quiere que sirva en http o en https, y se le dan los certificados a usar.

El admin va a hacer el deploy como le pinte. Puede descargar todo el proyecto y cambiar el puerto en el que corre express, puede usar nginx como proxy para redirigir al 3000, o puede crear un container de docker y redirigir el puerto del container al 80. Eso no lo tenemos que decidir nosotros.

Lo que sí hay que hacer, es que la persona que quiera correr el edt como http, pueda hacerlo. Aquella que quera correrlo en https, también (y pueda configurar sus propios certificados). El cert self-signed está bueno para hacer pruebas en dev, pero no mucho más.

No es mala idea que pueda elegir los puertos en los que corre la aplicación tampoco. Así, puede configurar si lanza el servidor como http en 80 y https en 443 (si tiene privilegios de admin), o cualquier otro par de puertos.

[francoa]

Ustedes dos son unos maestros loco. Me siento un pichón jaja

[francoa]

Algo de acá que deba ir en el archivo config?

[andresmanelli]

Sí, los puertos a servir para http y https (que según Fer, pueden ser diferentes). No ví lo que está en lo que hiciste, pero bueno quería responder jaja

[fcladera]

Si, los puertos puede ser. Pero eso me parece que es para un rework completo de lo de https. Yo lo dejaría como está, total el issue de https ya está, lo hacemos después.