Configuración del sistema¶

Este documento describe los pasos básicos para configurar Odoo en producción o en un servidor orientado a Internet. Sigue installation, y, por lo general, no es necesario para un sistema de desarrollo que no esté expuesto en internet.

Advertencia

Si está configurando un servidor público, asegúrese de revisar sus recomendaciones de seguridad.

dbfilter¶

Odoo es un sistema de tenencia múltiple: es posible que un solo sistema de Odoo ejecute y sirva varias instancias de la base de datos. También puede tener varias personalizaciones (desde cómo se cargan los módulos) dependiendo la base de datos actual.

Esto no es un problema al trabajar en el backend (cliente web) como un usuario de la empresa que inició sesión: la base de datos se puede seleccionar al iniciar sesión y las personalizaciones se cargan después.

Sin embargo, esto es un problema para usuarios que no iniciaron sesión (portal, sitio web) y no están ligados a la base de datos: Odoo necesita saber qué base de datos se deberían usar para cargar la página de sitio web o realizar la operación. Si la tenencia múltiple no se usa, no será un problema, ya que solo hay una base de datos para usar, pero si hay varias bases de datos a las que se pueden acceder, Odoo necesita una regla para saber cuál debe de usuar.

Ese es uno de los propósitos de --db-filter: especifica cuál es la base de datos que se debe seleccionar dependiendo en el nombre de host (dominio) que se solicita. El valor es una expresión regular, posiblemente incluyendo el nombre de host inyectado dinámicamente (%h) o el primer subdominio (%d) mediante el cual el se accede al sistema.

Para servidores que alojan varias bases de datos en producción, especialmente si se usa sitio web, el dbfilter debe estar configurado, de lo contrario un número de funciones no trabajarán correctamente.

Ejemplos de configuración¶

Mostrar solo las bases de datos con nombres que empiecen con “miempresa”

en /etc/odoo.conf configure:

[options]
dbfilter = ^mycompany.*$

Mostrar solo las bases de datos que coinciden con el primer subdominio después de www: por ejemplo, la base de datos «miempresa» se enseñará si la solicitud entreante se envió a www.miempresa.com or miempresa.co.uk, pero no para www2.miempresa.com o serviciodeasistencia.miempresa.com.

en /etc/odoo.conf configure:

[options]
dbfilter = ^%d$

Nota

Configurar un --db-filtro es una parte importante para asegurar el despliegue. Una vez que funcione correctamente y solo se vincule una base de datos por nombre de host, se recomienda ampliamente bloquear el acceso de las pantallas de gerencia a la base de datos y use el parámetro de inicio --no-database-list para evitar listar sus bases de datos y para bloquear el acceso a las pantallas de gerencia de la base de datos. También vea security.

PostgreSQL¶

Por defecto, PostgreSQL solo permite la conexión con UNIX mediante sockets y loopback (desde «localhost», la misma máquina en la que está instalada el servidor PostgreSQL).

El socket de UNIX está bien si quiere que Odoo y PostgreSQL se ejecuten en la misma máquina y es lo predeterminado cuando no se brinda un alojamiento, pero si quiere que Odoo y PostgreSQL se ejecuten en diferentes máquinas 1 necesitará escuchar las interfaces de la red 2, ya sea:

Solo acepte conexiones loopback y use un SSH tunel entre la máquina en la que Odoo se ejecutra y la máquina en la que PostgreSQL se ejecuta, después configure Odoo para conectarse para su lado del tunel.
Aceptar conexiones a la máquina en la que Odoo está instalado, posiblemente en ssl (vea ajustes de conexión con PostgreSQL para más detalles), después configure Odoo para conectarlo con la red.

Ejemplo de configuración¶

Permitir la conexión tcp en alojamiento local
Permitir la conexión tcp desde la red 192.168.1.x

en /etc/postgresql/9.5/main/pg_hba.conf configure:

# IPv4 local connections:
host    all             all             127.0.0.1/32            md5
host    all             all             192.168.1.0/24          md5

en /etc/postgresql/9.5/main/postgresql.conf configure:

listen_addresses = 'localhost,192.168.1.2'
port = 5432
max_connections = 80

Configurando Odoo¶

Odoo es una aplicación que de inmediato se puede conectar a postgres locales con un socket UNIX mediante el puerto 5432. Esto se puede anular con las opciones de la base de datos cuando su implementación no es local o no usa la configuración predeterminada de la instalación.

Los paquetes de instalación crearán un nuevo usuario (odoo) automáticamente y lo marcarán como un usuario de la base de datos.

La configuración de admin_passwd protegen las pantallas de gestión de la base de datos. Esta configuración solo se puede usar con los archivos de configuración y simplemente se revisa antes de realizar alteraciones a la base de datos. Debería estar configurado a un valor generado de manera aleatoria para asegurar que terceros no pueden usar esta interfaz.
Todas las operaciones de la base de datos usan las opciones de base de datos, incluyendo la pantalla de gestión de las bases de datos. Para que la pantalla de gestión funcione, el usuario de PostgreSQL necesita tener el derecho createdb.
Los usuarios siempre pueden abandonar las bases de datos que les pertenecen. Para que la pantalla de gestión de la base de datos deje de ser funcional, el usuario de PostgreSQL necesita crearse con no-createdb y otro usuario PostgreSQL debe ser el dueño de la base de datos.

Advertencia
el usuario PostgreSQL no puede* ser un superusuario.

Ejemplo de configuración¶

conéctese a un servidor PostgreSQL en 192.168.1.2
puerto 5432
usando una cuenta de usuario «odoo»,
con «pwd» como contraseña
filtrando solo la base de datos con nombres que empiecen en «miempresa»

en /etc/odoo.conf configure:

[options]
admin_passwd = mysupersecretpassword
db_host = 192.168.1.2
db_port = 5432
db_user = odoo
db_password = pwd
dbfilter = ^mycompany.*$

SSL entre Odoo y PostgreSQL¶

Desde Odoo 11.0 puede aplicar la conexión entre Odoo y PostgreSQL. En Odoo, db_sslmode controla la seguridad ssl de la conexión con un valor que puede ser «desabilitar», «permitir», «preferir», «requerir», «verificar-ca», o «verificar-completo»

Documento PostgreSQL

Servidor built-in¶

Odoo incluye servidores HTTP built-in, usando ya sea multihilos o multiprocesos.

Para uso en producción, se recomienda utilizar el servidor multiprocesos ya que aumenta la estabilidad, hace mejor uso de los recursos de cómputo y puede ser mejor monitorearlo y restringir los recursos.

El multiprocesamiento se activa configurando un número, diferente a cero de procesos de trabajadores, el número de workers debería basarse en el número de núcleos en la máquina (posiblemente con espacio para los workers del cron dependiendo de cuánto trabajo en el cron se espere)
Los límites del trabajador se pueden configurar según la configuración del hardware para evitar agotar recursos.

Advertencia

el modo de multiprocesos todavía no está disponible en Windows

Cálculo del número de trabajadores¶

Regla general : (#CPU * 2) + 1
Los workers del cron necesitan CPU
1 trabajador ~= 6 usuarios concurrentes

cálculo del tamaño de la memoria¶

Consideramos que el 20% de las solicitudes son serias, mientras que el 80% son más simples.
Se estima que un trabajador pesado consume alrededor de 1GB de RAM una vez que todos los campos computados y las peticiones SQL estén bien diseñadas, etc.
Se estima que un trabajador ligero en el mismo escenario consume alrededor de 150MB de RAM

RAM necesario = #trabajador * ( (light_worker_ratio * light_worker_ram_estimation) + (heavy_worker_ratio * heavy_worker_ram_estimation) )

Chat en vivo¶

En el procesamiento paralelo, un trabajador especializado se inicia automáticamente y escucha el el puerto longpolling pero el cliente no lo conectará.

En su lugar, necesita tener un proxy para redireccionar las solicitudes de los URL que empiezan con «/longpolling/» al puerto longpolling. El resto de peticiones deben ser proxies al puerto HTTP normal

Para lograr esto, necesita realizar el proxy reverso en Odoo, como nginx o apache. Al hacerlo, necesitará enviar algunos encabezados http a Odoo para activar el proxy_mode en la configuración de Odoo y el software pueda leer todos los encabezados.

Ejemplo de configuración¶

Servidor con 4 CPU, 8 Thread
60 usuarios concurrentes
60 users / 6 = 10 <- theorical number of worker needed
(4 * 2) + 1 = 9 <- theorical maximal number of worker
Usaremos 8 workers + 1 para el cron. También usaremos un sistema de monitoreo para medir la carga del cpu y revisar que sea entre 7 y 7.5.
RAM = 9 * ((0.8*150) + (0.2*1024)) ~= 3Go RAM para Odoo

en /etc/odoo.conf:

[options]
limit_memory_hard = 1677721600
limit_memory_soft = 629145600
limit_request = 8192
limit_time_cpu = 600
limit_time_real = 1200
max_cron_threads = 1
workers = 8

HTTPS¶

No importa si el acceso es mediante sitio web/cliente web o servicio web, Odoo transmite información de autenticación en cleartext. Esto significa que una implementación de Odoo segura debe usar HTTPS3. La terminación SSL se puede implementar con cualquier proxy de terminación SSL, pero requiere la siguiente configuración:

Activar el modo proxy de Odoo. Esto solo debería estar activado cuando Odoo esté detrás de un proxy reverso.
Configurar la terminación SSL del proxy (ejemplo de terminación Nginx)
Configurar el proxy en sí (ejemplo Nginx del proxy)
Su terminación proxy SSL también debería de redirigir conexiones no seguras automáticamente para asegurar el puerto

Ejemplo de configuración¶

Redirigir solicitudes http a https
Solicitudes proxy a odoo

en /etc/odoo.conf configure:

proxy_mode = True

en /etc/nginx/sites-enabled/odoo.conf configure:

#odoo server
upstream odoo {
 server 127.0.0.1:8069;
}
upstream odoochat {
 server 127.0.0.1:8072;
}

# http -> https
server {
   listen 80;
   server_name odoo.mycompany.com;
   rewrite ^(.*) https://$host$1 permanent;
}

server {
 listen 443 ssl;
 server_name odoo.mycompany.com;
 proxy_read_timeout 720s;
 proxy_connect_timeout 720s;
 proxy_send_timeout 720s;

 # Add Headers for odoo proxy mode
 proxy_set_header X-Forwarded-Host $host;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
 proxy_set_header X-Real-IP $remote_addr;

 # SSL parameters
 ssl_certificate /etc/ssl/nginx/server.crt;
 ssl_certificate_key /etc/ssl/nginx/server.key;
 ssl_session_timeout 30m;
 ssl_protocols TLSv1.2;
 ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
 ssl_prefer_server_ciphers off;

 # log
 access_log /var/log/nginx/odoo.access.log;
 error_log /var/log/nginx/odoo.error.log;

 # Redirect longpoll requests to odoo longpolling port
 location /longpolling {
 proxy_pass http://odoochat;
 }

 # Redirect requests to odoo backend server
 location / {
   proxy_redirect off;
   proxy_pass http://odoo;
 }

 # common gzip
 gzip_types text/css text/scss text/plain text/xml application/xml application/json application/javascript;
 gzip on;
}

Odoo como una aplicación WSGI¶

También es posible montar Odoo como una aplicación WSGI estándar. Odoo proporciona la base para un script de lanzamiento WSGI como odoo-wsgi.example.py. El script debe personalizarse (posiblemente después de copiarlo desde el directorio de configuración) para realizar la configuración correctamente en odoo.tools.config y no en la línea de comando o archivo de configuración.

Sin embargo, el servidor WSGI solo mostrará el extremo HTTP principal para el cliente web, sitio web y servicio web API. Como Odoo ya no controla la creación de workers, así que ya no puede configurar el cron o los workers del chat en vivo.

Workers de cron¶

Para ejecutar trabajos de cron en una implementación de Odoo, la aplicación de WSGI requiere:

Un Odoo clásico (ejecutado con odoo-bin)
Conexión a la base de datos en la que los trabajos de cron se tienen que ejecutar (via odoo-bin -d)
No debería estar expuesta a la red. Para asegurarse de que los ejecutores del cron no tienen acceso a la red, es posible deshabilitar el servidor HTTP integrado por completo con odoo-bin --no-http o si configuramos http_enable = False en el archivo de configuración.

Chat en vivo¶

El segundo subsistema problemático para implementaciones con WSGI es el Chat en vivo: mientras que la mayoría de las conexiones HTTP son relativamente cortas y liberan rápidamente los procesos de trabajadores para la siguiente solicitud, el chat en vivo necesita una conexión duradera para cada cliente para poder implementar notificaciones casi a tiempo real.

Esto entra en conflicto con un modelo de trabajo basado en procesos, ya que vinculará los trabajadores de procesos y prevendrá que los nuevos usuarios ingresen al sistema. Sin embargo, esas conexiones duraderas hacen muy poco y usualmente se quedan sin hacer nada y esperando por notificaciones.

Las soluciones para soportar chat en vivo/notificaciones en una aplicación WSGI son:

Implementar una versión de subprocesamiento de Odoo (en lugar de una basada en procesos preforking) y redirigir solo solicitudes a URL que empiecen con ``/longpolling/` a ese Odoo. Esta es la solución más simple y la URL longpolling también puede funcionar como una instancia de cron.
Desplegar un Odoo con eventos con ayuda de odoo-gevent y hacer proxy de solicitudes que inicien con /longpolling/ al puerto de longpolling.

Servicio de archivos estáticos¶

Por conveniencia, Odoo sirve directamente todos los archivos estáticos en sus módulos. Esto puede ser ideal cuando se trata de rendimiento y los archivos estáticos generalmente se deberían servir con un servidor HTTP estático.

Los archivos estáticos en la carpeta static/, así que los archivos estáticos se pueden servir al interceptar todas las solicitudes a /MODULE/static/FILE y puede buscar el módulo (y archivo) correcto en todas las rutas agregadas.

Seguridad¶

Para empezar, tome en cuenta que asegurar un sistema de información es un proceso continuo, no una operación de una sola vez. En cualquier momento, su entorno solo será tan seguro como el vínculo más débil.

No tome esta sección como la única lista de medidas para prevenir todos los problemas de seguridad. Esta lista solo es un resumen de las cosas más importantes que debe incluir en su plan de acción de seguridad. Lo demás vendrá de las mejores prácticas de seguridad para su sistema operativo y distribución. Las mejores prácticas en cuanto a usuarios, contraseñas y la gestión del control de acceso, etc.

Al desplegar un servidor con acceso a internet, asegúrese de considerar los siguientes temas relacionados a la seguridad:

Siempre configure una contraseña de administrador del super-admin que sea fuerte y restrinja el acceso a la gestión de la página web tan pronto como se configure el sistema. Vea Seguridad del gestor de la base de datos.
Elija inicios de sesión únicos y contraseñas fuertes para todas las cuentas de administrador en todas las bases de datos. No use «admin» como inicio de sesión. No use los mismos inicios de sesión para operaciones del día a día, solo para controlar/gestionar la instalación. Nunca use contraseñas automáticas, como admin/admin, incluso para bases de dato de prueba o de secuenciamiento.
No instale los datos demo en servidores con acceso a internet. Las bases de datos con información de demo tienen inicios de sesión predeterminados y contraseñas que se podrían usar para ingresar a sus sistemas y puede ser un gran problema, incluso en sistemas de desarrollo o secuenciamiento.
Use filtros apropiados para la base de datos ( --db-filter) para restringir la visibilidad de sus bases de datos según al nombre de host. Vea dbfilter. También puede usar -d para obtener su propia lista (separada por comas) de bases de datos que puede filtrar, en lugar de dejar que el sistema obtenga todo desde el backend de la base de datos.
Una vez que su db_name y db_filter están configurados y solo emparejan las bases de datos por nombre de host. Debe poner la opción de configuración a Falso, para prevenir que se enlisten las bases de datos por completo y para bloquear el acceso a la pantalla de gestión de la base de datos (esto también se muestra como --no-database-list en la opción de la línea de comando).
Asegúrese de que el usuario de PostgreSQL (--db_user) no es un super usuario y sus bases de datos le pertenecen a un usuario diferente. Por ejemplo, puede que los super usuarios de postgres sean los dueños si usa un db_user especializado y no privilegiado. También vea Configurando Odoo.
Instale las versiones más recientes para que las instalaciones siempre estén actualizadas, ya sea por medio de GitHub, o descargando la versión más reciente de https://www.odoo.com/page/download o http://nightly.odoo.com
Configure su servidor en un modo multiproceso con límites adecuados que sean igual a su uso habitual (memoria/CPU/tiempos de espera). También vea Servidor built-in.
Ejecute Odoo con un servicio web que proporcione una terminación HTTPS con un certificado SSL válido para evitar intercepción en comunicaciones de cleartext. Los certificados de SSL son baratos y existen muchas opciones gratis. Configure el proxy web para limitar el tamaño de las solicitudes, configure tiempos de espera apropiados y después active la opción de modo proxy. También vea HTTPS.
Si necesita permitir el acceso remoto SSH a sus servidores, asegúrese de configurar una contraseña fuerte para todas las cuentas, no solo root. Le recomendamos deshabilitar enteramente la autenticación a base de contraseña y solo permita la autenticación con clave pública. También considere restringir el acceso a través de VPN y solo permita IP de confianza en el firewall, o ejecutar un sistema de detección a fuerza bruta como un fail2ban o equivalente.
Considere instalar un factor de límite de tasa en su proxy o firewall para así evitar ataques de fuerza bruta y negar ataques al servicio. También vea Bloquear ataques de fuerza bruta para medidas específicas.

Muchos proveedores de red brindan migración automática para ataques DoS (ataque de denegación de servicio, por su sigla en inglés), pero este es un servicio opcional. Le recomendamos que lo consulte con ellos.
Siempre que sea posible, aloje sus instancias de demostración/prueba/secuenciamiento en máquinas que sean diferentes a las de producción. Aplique las mismas precauciones de seguridad que para producción.
Si su servidor público de Odoo tiene acceso a recursos o servicios sensibles de la red interna (por ejemplo, a través de una VLAN privada), implemente reglas de firewall apropiadas para proteger esos recursos internos. Esto es para asegurar que el servidor de Odoo no se pueda usar accidentalmente (o como resultado de las acciones de un usuario malicioso) para acceder o alterar aquellos recursos internos. Esto se puede hacer usualmente aplicando una regla de denegación automática de salida en el firewall. Una vez que lo haga solo autorice explícitamente el acceso a recursos internos a los que el servidor de Odoo tiene que acceder. El control de acceso al tráfico IP de Systemd también puede servir para implementarse por control de acceso a la red de procesos.
Si su servidor público de Odoo está detrás de un firewall de aplicaciones web, un balanceo de carga, un servicio de protección DoS transparente (como CloudFlare), o un dispositivo similar a nivel de red, querrá evitar tener acceso directo al sistema de Odoo. Generalmente es difícil mantener el final de las direcciones IP de sus servidores de Odoo secreto. Por ejemplo, pueden aparecer en registros del servidor web al consultar sistemas públicos, o en los encabezados de los correos que Odoo publica. En cada situación, es posible que quiera configurar su firewall para que no se pueda ingresar a las terminales públicamente, excepto por las direcciones IP de su WAF, balanceo de carga, o servicio proxy. Los proveedores de servicios como CloudFlare usualmente mantienen una lista pública de sus rangos de direcciones IP para este propósito.
Si está alojando a varios clientes, aísle datos de clientes y archivos el uno de otro usando contenedores o técnicas de «jail».
Configure respaldos diarios para sus bases de datos y los datos de los archivos guardados, cópielos a un servidor de almacenamiento remoto que no sea accesible desde el servidor en sí.

Bloquear ataques de fuerza bruta¶

Para despliegues en internet, los ataques a fuerza bruta en las contraseñas de los usuarios son muy comunes. Esta amenaza no se pueda pasar por alto para los servidores de Odoo. Odoo registra una entrada cada que se realiza un intento de inicio de sesión y reporta los resultados: éxito o fallo, así como el objetivo de inicio de sesión e IP fuente.

Los registros de entradas tendrán el siguiente formato.

Inicio de sesión fallido:

2018-07-05 14:56:31,506 24849 INFO db_name odoo.addons.base.res.res_users: Login failed for db:db_name login:admin from 127.0.0.1

Inicio de sesión exitoso:

2018-07-05 14:56:31,506 24849 INFO db_name odoo.addons.base.res.res_users: Login successful for db:db_name login:admin from 127.0.0.1

Estos registros se pueden analizar fácilmente con un sistema de prevención de intrusos como fail2ban.

Por ejemplo, la siguiente definición del filtro fail2ban debe emparejarse con un inicio de sesión fallido:

[Definition]
failregex = ^ \d+ INFO \S+ \S+ Login failed for db:\S+ login:\S+ from <HOST>
ignoreregex =

Esto se podía usar con una definición de jail para bloquear los ataques IP en HTTP(S).

Así es como se podría ver por bloquear la IP por 15 minutos cuando se detectan 10 intentos fallidos de inicio de sesión desde la misma IP en 1 minuto:

[odoo-login]
enabled = true
port = http,https
bantime = 900  ; 15 min ban
maxretry = 10  ; if 10 attempts
findtime = 60  ; within 1 min  /!\ Should be adjusted with the TZ offset
logpath = /var/log/odoo.log  ;  set the actual odoo log path here

Seguridad del gestor de la base de datos¶

Configurando Odoo menciona admin_passwd de paso.

Esta configuración se usa en todas las pantallas de gestión de la base de datos (para crear, borrar, descartar o restablecer bases de datos).

Si no se debería acceder a las pantallas de gestión de ninguna manera, debe establecer la opción de configuración list_db a Falso, para bloquear el acceso a todas las pantallas de gestión o selección de bases de datos.

Advertencia

¡Le recomendamos deshabilitar el gestor de la base de datos para un sistema en internet! Está hecha como una herramienta de desarrollo/demo, para facilitar la creación y gestión rápida de las bases de datos. No está diseñada para usarse en producción, además de que puede exponer funciones peligrosas para los atacantes. Tampoco está diseñado para ejecutar bases de datos grandes y puede que active límites de memoria.

En sistemas en producción, las operaciones de gestión en la base de datos siempre las debe realizar el administrador del sistema, incluyendo el suministro de bases de datos nuevas y respaldos automáticos.

Asegúrese de configurar un parámetro db_name apropiado (y también db_filter, opcionalmente) para que el sistema pueda determinar la base de datos objetivo para cada petición, de lo contrario, se bloqueará a los usuarios ya que no se permitirá que ellos mismos elijan la base de datos.

Si solo se puede acceder a las pantallas de gestión desde un grupo de máquinas específicas, use las funciones de proxy del servidor para bloquear el acceso a todas las rutas que empiecen con /web/database, excepto (quizá) /web/database/selector que muestra la pantalla de selección de base de datos.

Si se debe de mantener el acceso a la pantalla de gestión de la base de datos, la configuración de admin_passwd se debe de cambiar de la predeterminada que es admin: esta contraseña se debe de revisar antes de permitir operaciones que alteren la base de datos.

Se debe guardar en un lugar seguro y se debe de generar aleatoriamente, p. ej.

$ python3 -c 'import base64, os; print(base64.b64encode(os.urandom(24)))'

que generará una cadena imprimible pseudoaleatoria de 32 caracteres.

Navegadores compatibles¶

Odoo es compatible con todos los navegadores web principales, siempre y cuando sigan siendo compatibles con sus creadores.

Estos son los navegadores compatibles:

Google Chrome
Mozilla Firefox
Microsoft Edge
Apple Safari

Advertencia

Asegúrese de que su navegador esté actualizado y que el creador le siga dando soporte antes de llenar un reporte de bug.

Nota

Desde Odoo 13.0, ES6 es compatible. Por lo tanto, ya no se da asistencia a IE.

1: para que varias instalaciones de Odoo usen la misma base de datos PostgreSQL, o brindar más recursos de cálculo para el software.
2: técnicamente una herramienta como socat puede ser utilizada para proxy UNIX sockets a través de redes, pero eso es sobre todo para el software que sólo se puede utilizar a través de UNIX sockets
3: o puede ser accesible solo a través de una red interna de comunicación de paquetes, pero para esto se necesitan paquetes seguros, protección contra suplantación de ARP y excluye el uso de WiFi. Incluso en redes seguras de comunicación de paquetes, se recomienda el despliegue en HTTPS y los costos posibles se reducen, ya que los certificados «autofirmados» son más fáciles de desplegar en un entorno controlado que en Internet.

Edit on GitHub