系统配置¶

This document describes basic steps to set up Odoo in production or on an internet-facing server. It follows installation, and is not generally necessary for a development systems that is not exposed on the internet.

警告

如果您正在设置公共服务器，请务必查看我们的安全性建议！

数据库过滤器¶

Odoo是一个多租户系统：一个Odoo系统可以运行和服务于多个数据库实例。它也是高度可定制的，自定义（从加载的模块开始）取决于“当前数据库”。

当作为已登录的公司用户使用后端（Web客户端）时，这不是问题：可以在登录时选择数据库，然后加载自定义设置。

然而，对于未登录的用户（门户网站），这是一个问题，因为他们没有绑定到数据库：Odoo需要知道应该使用哪个数据库来加载网页或执行操作。如果不使用多租户，那么这不是问题，只有一个数据库可用，但如果有多个可访问的数据库，Odoo需要一条规则来知道应该使用哪个。

这是 --db-filter 的一个目的：它指定了如何根据请求的主机名（域名）选择数据库。值是一个正则表达式，可能包括动态注入的主机名（%h）或通过系统访问的第一个子域（%d）。

对于在生产环境中托管多个数据库的服务器，特别是如果使用了``website``，必须设置dbfilter，否则一些功能将无法正常工作。

配置示例¶

仅显示名称以’mycompany’开头的数据库

在配置文件中设置：

[options]
dbfilter = ^mycompany.*$

只显示与 www 后的第一个子域名匹配的数据库：例如，如果传入请求发送到 www.mycompany.com 或 mycompany.co.uk，则会显示数据库 “mycompany”，但不会显示 www2.mycompany.com 或 helpdesk.mycompany.com。

在配置文件中设置：

[options]
dbfilter = ^%d$

注解

设置正确的 --db-filter 是保护您的部署的重要部分。一旦它正确工作并且只匹配每个主机名的单个数据库，强烈建议阻止访问数据库管理屏幕，并使用 --no-database-list 启动参数防止列出您的数据库，并阻止访问数据库管理屏幕。另请参阅 security。

PostgreSQL¶

默认情况下，PostgreSQL仅允许通过UNIX套接字和回环连接（从”localhost”，即安装PostgreSQL服务器的同一台机器）进行连接。

UNIX socket is fine if you want Odoo and PostgreSQL to execute on the same machine, and is the default when no host is provided, but if you want Odoo and PostgreSQL to execute on different machines 1 it will need to listen to network interfaces 2, either:

只接受回环连接并在Odoo运行的机器和PostgreSQL运行的机器之间 使用SSH隧道 _，然后配置Odoo连接到隧道的末端
接受连接到安装了Odoo的机器上，可能通过ssl连接（详见 PostgreSQL连接设置），然后配置Odoo以通过网络连接

配置示例¶

允许本地主机上的 TCP 连接
允许来自192.168.1.x网络的TCP连接

在 /etc/postgresql/<YOUR POSTGRESQL VERSION>/main/pg_hba.conf 中设置：

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

in /etc/postgresql/<YOUR POSTGRESQL VERSION>/main/postgresql.conf 设置：

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

配置Odoo¶

开箱即用，Odoo通过端口5432连接到本地的UNIX套接字上的postgres。当您的Postgres部署不是本地的和/或不使用安装默认值时，可以使用数据库选项来覆盖此设置。

The packaged installers will automatically create a new user (odoo) and set it as the database user.

数据库管理界面受 admin_passwd 设置的保护。此设置只能使用配置文件设置，并在执行数据库更改之前进行简单检查。应将其设置为随机生成的值，以确保第三方无法使用此界面。
所有数据库操作都使用数据库选项，包括数据库管理屏幕。要使数据库管理屏幕正常工作，需要 PostgreSQL 用户具有 createdb 权限。
用户可以随时删除自己拥有的数据库。为了使数据库管理界面完全无法使用，需要创建具有 no-createdb 权限的PostgreSQL用户，并且数据库必须由不同的PostgreSQL用户拥有。

警告
PostgreSQL用户不能是超级用户

配置示例¶

连接到位于192.168.1.2的PostgreSQL服务器
端口 5432
使用 ‘odoo’ 用户账户，
使用’pwd’作为密码
仅筛选名称以’mycompany’开头的数据库

在配置文件中设置：

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

Odoo和PostgreSQL之间的SSL¶

自Odoo 11.0版本开始，您可以在Odoo和PostgreSQL之间强制使用SSL连接。在Odoo中，db_sslmode控制连接的SSL安全性，可选值为’disable’、’allow’、’prefer’、’require’、’verify-ca’或’verify-full’

PostgreSQL Doc

内置服务器¶

Odoo includes built-in HTTP, cron, and live-chat servers, using either multi-threading or multi-processing.

The multi-threaded server is a simpler server primarily used for development, demonstrations, and its compatibility with various operating systems (including Windows). A new thread is spawned for every new HTTP request, even for long-lived connections such as websocket. Extra daemonic cron threads are spawned too. Due to a Python limitation (GIL), it doesn’t make the best use of the hardware.

The multi-threaded server is the default server, also for docker containers. It is selected by leaving the --workers option out or setting it to 0.

The multi-processing server is a full-blown server primarily used for production. It is not liable to the same Python limitation (GIL) on resource usage and hence makes the best use of the hardware. A pool of workers is created upon server startup. New HTTP requests are queued by the OS until there are workers ready to process them. An extra event-driven HTTP worker for the live chat is spawned on an alternative port. Extra cron workers are spawned too. A configurable process reaper monitors resource usage and can kill/restart failed workers.

The multi-processing server is opt-in. It is selected by setting the --workers option to a non-null integer.

注解

Because it is highly customized for Linux servers, the multi-processing server is not available on Windows.

工作进程数量计算¶

经验法则：(#CPU * 2) + 1
Cron工作进程需要CPU
1个工作进程 ~= 6个并发用户

内存大小计算¶

我们认为20%的请求是重型请求，而80%的请求是较简单的请求
当所有计算字段和 SQL 请求都设计良好时，一个繁重的工作进程预计会消耗约 1GB 的 RAM。
在相同的场景中，一个轻量级的工作进程预计会消耗大约150MB的内存。

所需内存 = #worker * ( (轻型工作进程比率 * 轻型工作进程内存估算) + (重型工作进程比率 * 重型工作进程内存估算) )

在线聊天¶

In multi-processing, a dedicated LiveChat worker is automatically started and listens on the --gevent-port. By default, the HTTP requests will keep accessing the normal HTTP workers instead of the LiveChat one. You must deploy a proxy in front of Odoo and redirect incoming requests whose path starts with /websocket/ to the LiveChat worker. You must also start Odoo in --proxy-mode so it uses the real client headers (such as hostname, scheme, and IP) instead of the proxy ones.

配置示例¶

带有4个CPU和8个线程的服务器
60个并发用户
60个用户 / 6 = 10 <- 理论上需要的工作人员数量
(4 * 2) + 1 = 9 <- 理论上的最大工作人数
我们将使用8个工作进程+1个cron。我们还将使用监控系统来测量CPU负载，并检查它是否在7到7.5之间。
RAM = 9 * ((0.8*150) + (0.2*1024)) ~= 3Go RAM for Odoo

在配置文件中：

[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¶

无论是通过网站/网页客户端还是Web服务访问，Odoo都会以明文形式传输身份验证信息。这意味着Odoo的安全部署必须使用HTTPS3。SSL终止可以通过几乎任何SSL终止代理实现，但需要以下设置：

启用Odoo的 代理模式 。这只应在Odoo位于反向代理后启用
设置SSL终止代理 (Nginx终止示例)
设置代理本身 (Nginx 代理示例)
您的 SSL 终止代理应该自动将非安全连接重定向到安全端口

配置示例¶

将http请求重定向到https
代理请求到Odoo

在配置文件中设置：

proxy_mode = True

在 /etc/nginx/sites-enabled/odoo.conf 中设置：

#odoo server
upstream odoo {
  server 127.0.0.1:8069;
}
upstream odoochat {
  server 127.0.0.1:8072;
}
map $http_upgrade $connection_upgrade {
  default upgrade;
  ''      close;
}

# 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;

  # 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 websocket requests to odoo gevent port
  location /websocket {
    proxy_pass http://odoochat;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
    proxy_set_header X-Forwarded-Host $http_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;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
    proxy_cookie_flags session_id samesite=lax secure;  # requires nginx 1.19.8
  }

  # Redirect requests to odoo backend server
  location / {
    # Add Headers for odoo proxy mode
    proxy_set_header X-Forwarded-Host $http_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;
    proxy_redirect off;
    proxy_pass http://odoo;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
    proxy_cookie_flags session_id samesite=lax secure;  # requires nginx 1.19.8
  }

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

HTTPS Hardening¶

Add the Strict-Transport-Security header to all requests, in order to prevent browsers from ever sending a plain HTTP request to this domain. You will need to maintain a working HTTPS service with a valid certificate on this domain at all times, otherwise your users will see security alerts or be entirely unable to access it.

Force HTTPS connections during a year for every visitor in NGINX with the line:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

Additional configuration can be defined for the session_id cookie. The Secure flag can be added to ensure it is never transmitted over HTTP and SameSite=Lax to prevent authenticated CSRF.

# requires nginx 1.19.8
proxy_cookie_flags session_id samesite=lax secure;

将Odoo作为WSGI应用程序¶

也可以将Odoo作为标准的WSGI_应用程序进行挂载。Odoo提供了一个WSGI启动脚本的基础，名为 odoo-wsgi.example.py 。该脚本应该被定制化（可能需要从设置目录中复制），以便直接在 odoo.tools.config 中正确设置配置，而不是通过命令行或配置文件。

然而，WSGI服务器仅会为Web客户端、网站和Web服务API公开主要的HTTP端点。因为Odoo不再控制工作进程的创建，所以它无法设置cron或livechat工作进程。

定时任务工作者¶

Starting one of the built-in Odoo servers next to the WSGI server is required to process cron jobs. That server must be configured to only process crons and not HTTP requests using the --no-http cli option or the http_enable = False configuration file setting.

On Linux-like systems, using the multi-processing server over the multi-threading one is recommended to benefit from better hardware usage and increased stability, i.e., using the --workers=-1 and --max-cron-threads=n cli options.

在线聊天¶

Using a gevent-compatible WSGI server is required for the correct operation of the live chat feature. That server should be able to handle many simultaneous long-lived connections but doesn’t need a lot of processing power. All requests whose path starts with /websocket/ should be directed to that server. A regular (thread/process-based) WSGI server should be used for all other requests.

The Odoo cron server can also be used to serve the live chat requests. Just drop the --no-http cli option from the cron server and make sure requests whose path starts with /websocket/ are directed to this server, either on the --http-port (multi-threading server) or on the --gevent-port (multi-processing server).

提供静态文件和附件服务¶

为了开发方便，Odoo直接在其模块中提供所有静态文件和附件。但是，这在性能方面可能不是理想的，静态文件通常应该由静态HTTP服务器提供。

提供静态文件服务¶

Odoo静态文件位于每个模块的 static/ 文件夹中，因此可以通过拦截所有请求到 /MODULE/static/FILE 来提供静态文件，并在各个插件路径中查找正确的模块（和文件）。

It is recommended to set the Content-Security-Policy: default-src 'none' header on all images delivered by the web server. It is not strictly necessary as users cannot modify/inject content inside of modules’ static/ folder and existing images are final (they do not fetch new resources by themselves). However, it is good practice.

Using the above NGINX (https) configuration, the following map and location blocks should be added to serve static files via NGINX.

map $sent_http_content_type $content_type_csp {
    default "";
    ~image/ "default-src 'none'";
}

server {
    # the rest of the configuration

    location @odoo {
        # copy-paste the content of the / location block
    }

    # Serve static files right away
    location ~ ^/[^/]+/static/.+$ {
        # root and try_files both depend on your addons paths
        root ...;
        try_files ... @odoo;
        expires 24h;
        add_header Content-Security-Policy $content_type_csp;
    }
}

The actual root and try_files directives are dependant on your installation, specifically on your --addons-path.

Example

Say Odoo has been installed via the debian packages for Community and Enterprise, and that the --addons-path is '/usr/lib/python3/dist-packages/odoo/addons'.

The root and try_files should be:

root /usr/lib/python3/dist-packages/odoo/addons;
try_files $uri @odoo;

Say Odoo has been installed via the sources, that both the Community and Enterprise git repositories were cloned in /opt/odoo/community and /opt/odoo/enterprise respectively, and that the --addons-path is '/opt/odoo/community/odoo/addons,/opt/odoo/community/addons,/opt/odoo/enterprise'.

The root and try_files should be:

root /opt/odoo;
try_files /community/odoo/addons$uri /community/addons$uri /enterprise$uri @odoo;

附件服务¶

附件是存储在文件存储中的文件，其访问受Odoo管理。无法通过静态Web服务器直接访问它们，因为访问它们需要在数据库中进行多次查找，以确定文件存储的位置以及当前用户是否可以访问它们。

无论如何，一旦文件被定位并且访问权限由Odoo验证通过，使用静态Web服务器而不是Odoo来提供文件是个好主意。为了让Odoo将文件服务委托给静态Web服务器，必须在静态Web服务器上启用和配置 X-Sendfile <https://tn123.org/mod_xsendfile/> _（apache）或 X-Accel <https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/> _（nginx）扩展。设置完成后，使用 --x-sendfile 命令行标志启动Odoo（此唯一标志同时用于X-Sendfile和X-Accel）。

注解

Apache（和兼容的Web服务器）的X-Sendfile扩展不需要任何补充配置。
NGINX 的 X-Accel 扩展确实需要以下额外配置：
```
location /web/filestore {
    internal;
    alias /path/to/odoo/data-dir/filestore;
}
```
如果您不知道文件存储的路径，请使用 --x-sendfile 选项启动 Odoo，并直接通过 Odoo 导航到 /web/filestore URL（不要通过 NGINX 导航到该 URL）。这将记录一个警告，其中包含您需要的配置信息。

安全性¶

首先，请记住，保护信息系统是一个持续的过程，而不是一次性操作。在任何时候，您的安全性只能与您环境中最薄弱的环节一样安全。

因此，请不要将本节视为可防止所有安全问题的终极措施清单。它仅旨在总结您应该确保包含在安全行动计划中的首要重要事项。其余的措施将来自于操作系统和发行版的最佳安全实践，用户、密码和访问控制管理方面的最佳实践等。

在部署面向互联网的服务器时，请务必考虑以下与安全相关的主题：

始终设置一个强大的超级管理员密码，并在系统设置完成后立即限制对数据库管理页面的访问。请参阅数据库管理器安全性。
为所有数据库的所有管理员账户选择唯一的登录名和强密码。不要使用 ‘admin’ 作为登录名。不要将这些登录名用于日常操作，仅用于控制/管理安装。 永远不要 使用任何默认密码，如 admin/admin，即使是用于测试/暂存数据库。
不要在面向互联网的服务器上安装演示数据。带有演示数据的数据库包含默认的登录名和密码，可以用来进入您的系统并造成重大麻烦，即使是在暂存/开发系统上也是如此。
使用适当的数据库过滤器（ --db-filter ）根据主机名限制数据库的可见性。参见数据库过滤器。您还可以使用 -d 提供您自己的（逗号分隔的）可用数据库列表进行过滤，而不是让系统从数据库后端获取所有数据库。
一旦配置了 db_name 和 db_filter，并且它们只与每个主机名匹配一个数据库，您应该将 list_db 配置选项设置为 False，以完全阻止列出数据库，并阻止访问数据库管理界面（这也可以通过命令行选项 --no-database-list 来实现）
确保 PostgreSQL 用户 (--db_user) 不是超级用户，并且您的数据库由不同的用户拥有。例如，如果您使用专用的非特权 db_user，它们可以由 postgres 超级用户拥有。另请参阅配置Odoo。
定期安装最新版本的构建，可以通过GitHub或从https://www.odoo.com/page/download或http://nightly.odoo.com下载最新版本来保持安装程序更新。
将服务器配置为多进程模式，并设置适合您典型使用情况的限制（内存/CPU/超时）。另请参阅：内置服务器。
在一个提供有效SSL证书的Web服务器后面运行Odoo，以防止窃听明文通信。SSL证书价格便宜，并且有很多免费选项。配置Web代理以限制请求大小，设置适当的超时时间，然后启用 代理模式 选项。另请参阅 HTTPS 。
如果您需要允许远程SSH访问您的服务器，请确保为所有帐户设置强密码，而不仅仅是 root 。强烈建议完全禁用基于密码的身份验证，仅允许公钥身份验证。还要考虑通过VPN限制访问，仅允许防火墙中的受信任IP，和/或运行类似 fail2ban 或等效的暴力破解检测系统。
考虑在您的代理或防火墙上安装适当的速率限制，以防止暴力攻击和拒绝服务攻击。另请参阅阻止暴力攻击以获取具体措施。

许多网络提供商提供分布式拒绝服务攻击（DDOS）的自动缓解，但这通常是一项可选服务，因此您应该与他们咨询。
如果可能的话，请将公共演示/测试/暂存实例托管在与生产实例不同的机器上。并采取与生产相同的安全预防措施。
如果您的公共面向的Odoo服务器可以访问敏感的内部网络资源或服务（例如通过私有VLAN），请实施适当的防火墙规则来保护这些内部资源。这将确保Odoo服务器不能被意外使用（或由于恶意用户行为）来访问或干扰这些内部资源。通常可以通过在防火墙上应用出站默认拒绝规则，然后仅明确授权Odoo服务器需要访问的内部资源来实现。 Systemd IP流量访问控制<http://0pointer.net/blog/ip-accounting-and-access-lists-with-systemd.html> _也可能对实施基于进程的网络访问控制有用。
如果您的公共Odoo服务器位于Web应用程序防火墙、负载均衡器、透明DDoS保护服务（如CloudFlare）或类似的网络级设备后面，您可能希望避免直接访问Odoo系统。通常很难保持Odoo服务器的终端IP地址的机密性。例如，当从Odoo查询公共系统或发布电子邮件时，它们可能出现在Web服务器日志中或邮件头中。在这种情况下，您可能希望配置防火墙，使终端点除了来自WAF、负载均衡器或代理服务的特定IP地址外，不可公开访问。像CloudFlare这样的服务提供商通常为此维护其IP地址范围的公共列表。
如果您正在托管多个客户，请使用容器或适当的“监狱”技术将客户数据和文件彼此隔离。
设置每日备份数据库和文件存储数据，并将其复制到远程归档服务器，该服务器无法从服务器本身访问。
Deploying Odoo on Linux is strongly recommended over Windows. Should you choose nevertheless to deploy on a Windows platform, a thorough security hardening review of the server should be conducted and is outside of the scope of this guide.

阻止暴力攻击¶

对于面向互联网的部署，对用户密码进行暴力攻击非常普遍，因此Odoo服务器不应忽视此威胁。每当进行登录尝试时，Odoo都会发出日志记录，并报告结果：成功或失败，以及目标登录和源IP。

日志条目将具有以下格式。

登录失败:

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

成功登录:

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

这些日志可以轻松地通过入侵防御系统（如 fail2ban）进行分析。

例如，以下 fail2ban 过滤器定义应该匹配一个失败的登录：

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

这可以与监狱定义一起使用，以在HTTP（S）上阻止攻击IP。

当在1分钟内检测到来自同一IP的10次登录尝试失败时，以下是阻止该IP 15分钟的示例：

[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

数据库管理器安全性¶

在配置Odoo 中提到了 admin_passwd 。

此设置用于所有数据库管理屏幕（用于创建、删除、转储或恢复数据库）。

如果完全不能访问管理界面，您应该将 list_db 配置选项设置为 False，以阻止访问所有数据库选择和管理界面。

警告

强烈建议禁用数据库管理器用于任何面向互联网的系统！它是作为开发/演示工具而设计的，以便快速创建和管理数据库。它不适用于生产环境，甚至可能向攻击者公开危险功能。它也不适用于处理大型数据库，可能会触发内存限制。

在生产系统中，数据库管理操作应该由系统管理员执行，包括新数据库的配置和自动备份。

请务必设置适当的 db_name 参数（可选地，也可以设置 db_filter 参数），以便系统可以确定每个请求的目标数据库，否则用户将被阻止，因为他们将无法自己选择数据库。

如果管理界面只能从一组选定的机器访问，请使用代理服务器的功能来阻止访问所有以 /web/database 开头的路由，除了（也许）显示数据库选择界面的 /web/database/selector。

如果要保留数据库管理界面的访问权限，则必须更改 admin_passwd 设置，以避免使用默认的 admin 密码。在允许数据库更改操作之前，将检查此密码。

应该安全地存储，并随机生成，例如：

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

这将生成一个32个字符的伪随机可打印字符串。

支持的浏览器¶

Odoo支持市场上所有主要的桌面和移动浏览器，只要它们得到其发布商的支持。

以下是支持的浏览器：

谷歌浏览器
Mozilla Firefox
微软 Edge
苹果Safari

警告

请在提交错误报告之前确保您的浏览器是最新的，并且仍然得到其发布者的支持。

注解

自Odoo 13.0起，支持ES6。因此，不再支持IE。

1: 要让多个Odoo安装使用同一个PostgreSQL数据库，或为两个软件提供更多的计算资源。
2: 技术上，可以使用类似 socat 的工具将 UNIX 套接字代理到网络上，但这主要是针对只能在 UNIX 套接字上使用的软件
3: 或者只能通过内部分组交换网络访问，但这需要安全交换机、防止 ARP 欺骗并且不允许使用 WiFi。即使在安全的分组交换网络上，也建议使用 HTTPS 进行部署，这样可以降低成本，因为在受控环境中部署“自签名”证书比在互联网上更容易。

Edit on GitHub