การกำหนดค่าระบบ¶

เอกสารนี้อธิบายขั้นตอนพื้นฐานในการตั้งค่า Odoo ในการใช้งานจริงหรือบนเซิร์ฟเวอร์ที่เชื่อมต่อกับอินเทอร์เน็ต มันเป็นไปตาม การติดตั้ง และโดยทั่วไปแล้วไม่จำเป็นสำหรับระบบการพัฒนาที่ไม่ได้เปิดเผยบนอินเทอร์เน็ต

dbfilter¶

Odoo เป็นระบบที่มีผู้เช่าหลายราย: ระบบ Odoo เดียวอาจทำงานและให้บริการอินสแตนซ์ฐานข้อมูลจำนวนหนึ่งได้ นอกจากนี้ยังสามารถปรับแต่งได้สูงด้วยการปรับแต่ง (เริ่มจากโมดูลที่กำลังโหลด) ขึ้นอยู่กับ "ฐานข้อมูลปัจจุบัน"

นี่ไม่ใช่ปัญหาเมื่อทำงานกับแบ็กเอนด์ (เว็บลูกค้า) ในฐานะผู้ใช้บริษัทที่เข้าสู่ระบบ: สามารถเลือกฐานข้อมูลได้เมื่อเข้าสู่ระบบ และโหลดการปรับแต่งในภายหลัง

อย่างไรก็ตาม ปัญหาสำหรับผู้ใช้ที่ไม่ได้เข้าสู่ระบบ (พอร์ทัล เว็บไซต์) ซึ่งไม่ได้ผูกไว้กับฐานข้อมูล: Odoo จำเป็นต้องทราบว่าควรใช้ฐานข้อมูลใดในการโหลดหน้าเว็บไซต์หรือดำเนินการ หากไม่ได้ใช้การเช่าหลายรายการซึ่งไม่เป็นปัญหา จะมีเพียงฐานข้อมูลเดียวให้ใช้ แต่หากมีหลายฐานข้อมูลที่เข้าถึงได้ Odoo จำเป็นต้องมีกฎเพื่อทราบว่าควรใช้ฐานข้อมูลใด

นั่นคือหนึ่งในวัตถุประสงค์ของ --db-filter: ระบุว่าควรเลือกฐานข้อมูลตามชื่อโฮสต์ (โดเมน) ที่ถูกร้องขออย่างไร ค่านี้คือ นิพจน์ทั่วไป ซึ่งอาจรวมถึงชื่อโฮสต์ที่แทรกแบบไดนามิก (`` %h``) หรือโดเมนย่อยแรก (%d) ที่ใช้เข้าถึงระบบ

สำหรับเซิร์ฟเวอร์ที่โฮสต์ฐานข้อมูลหลายฐานข้อมูลในการใช้งานจริง โดยเฉพาะอย่างยิ่งหากใช้ เว็บไซต์ จะต้องตั้งค่า dbfilter จำเป็น ไม่เช่นนั้นฟีเจอร์บางอย่างจะทำงานไม่ถูกต้อง

ตัวอย่างการกำหนดค่า¶

• แสดงเฉพาะฐานข้อมูลที่มีชื่อขึ้นต้นด้วย 'mycompany'

ในเซ็ท ไฟล์การกำหนดค่า:

[options]
dbfilter = ^mycompany.*$

• แสดงเฉพาะฐานข้อมูลที่ตรงกับโดเมนย่อยแรกที่อยู่หลัง www: ตัวอย่างเช่น ฐานข้อมูล "mycompany" จะแสดงขึ้นหากคำขอขาเข้าถูกส่งไปยัง www.mycompany.com หรือ mycompany.co.uk แต่ไม่ใช่สำหรับ www2.mycompany.com หรือ helpdesk.mycompany.com

ในเซ็ท ไฟล์การกำหนดค่า:

[options]
dbfilter = ^%d$

PostgreSQL¶

ตามค่าเริ่มต้น PostgreSQL อนุญาตการเชื่อมต่อผ่านซ็อกเก็ต UNIX และการเชื่อมต่อแบบย้อนกลับเท่านั้น (จาก "localhost" ซึ่งเป็นเครื่องเดียวกับที่ติดตั้งเซิร์ฟเวอร์ PostgreSQL)

ซ็อกเก็ต UNIX นั้นใช้ได้ถ้าคุณต้องการให้ Odoo และ PostgreSQL ดำเนินการบนเครื่องเดียวกัน และเป็นค่าเริ่มต้นเมื่อไม่ได้ระบุโฮสต์ไว้ แต่ถ้าคุณต้องการให้ Odoo และ PostgreSQL ดำเนินการบนเครื่องที่แตกต่างกัน 1 จะต้อง ฟังอินเทอร์เฟซเครือข่าย 2 อย่างใดอย่างหนึ่ง:

• ยอมรับเฉพาะการเชื่อมต่อแบบย้อนกลับและ ใช้ช่องทางการเชื่อมต่อ SSH ระหว่างเครื่องที่ Odoo รันกับเครื่องที่ PostgreSQL รัน จากนั้นกำหนดค่า Odoo ให้เชื่อมต่อกับจุดสิ้นสุดของช่องทางการเชื่อมต่อ

• ยอมรับการเชื่อมต่อกับเครื่องที่ติดตั้ง Odoo ซึ่งอาจผ่าน ssl (ดูรายละเอียดใน การตั้งค่าการเชื่อมต่อ PostgreSQL) จากนั้นกำหนดค่า Odoo ให้เชื่อมต่อผ่านเครือข่าย

ตัวอย่างการกำหนดค่า¶

• อนุญาตการเชื่อมต่อ TCP บน localhost

• อนุญาตการเชื่อมต่อ TCP จากเครือข่าย 192.168.1.x

ในเซ็ท /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

ในเซ็ท /etc/postgresql/<YOUR POSTGRESQL VERSION>/main/postgresql.conf:

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

กำลังกำหนดค่า Odoo¶

เมื่อเริ่มใช้งาน Odoo จะเชื่อมต่อกับ postgres ในเครื่องผ่านซ็อกเก็ต UNIX ผ่านพอร์ต 5432 ซึ่งสามารถแทนที่ได้โดยใช้ ตัวเลือกฐานข้อมูล เมื่อการปรับใช้ Postgres ของคุณไม่ใช่ในเครื่องและ/หรือ ไม่ได้ใช้ค่าเริ่มต้นการติดตั้ง

ตัวติดตั้งแบบแพ็คเกจ <packages> ` จะสร้างผู้ใช้ใหม่โดยอัตโนมัติ (``odoo`) และตั้งค่าให้เป็นผู้ใช้ฐานข้อมูล

• หน้าจอการจัดการฐานข้อมูลได้รับการปกป้องโดยการตั้งค่า admin_passwd การตั้งค่านี้สามารถตั้งค่าได้โดยใช้ไฟล์การกำหนดค่าเท่านั้น และจะถูกตรวจสอบก่อนดำเนินการแก้ไขฐานข้อมูล ควรตั้งค่าเป็นค่าที่สร้างขึ้นแบบสุ่มเพื่อให้แน่ใจว่าบุคคลที่สามไม่สามารถใช้อินเทอร์เฟซนี้ได้

• การดำเนินการฐานข้อมูลทั้งหมดใช้ ตัวเลือกฐานข้อมูล รวมถึงหน้าจอการจัดการฐานข้อมูล เพื่อให้หน้าจอการจัดการฐานข้อมูลทำงานได้ ผู้ใช้ PostgreSQL จะต้องมีสิทธิ์ createdb

• ผู้ใช้สามารถทิ้งฐานข้อมูลของตนเองได้ตลอดเวลา เพื่อให้หน้าจอการจัดการฐานข้อมูลไม่ทำงานโดยสมบูรณ์ ผู้ใช้ PostgreSQL จะต้องถูกสร้างขึ้นด้วย no-createdb และฐานข้อมูลจะต้องเป็นของผู้ใช้ PostgreSQL อื่น

  Warning

  ผู้ใช้ PostgreSQL ต้องไม่ เป็นผู้ใช้ระดับสูง

ตัวอย่างการกำหนดค่า¶

• เชื่อมต่อกับเซิร์ฟเวอร์ PostgreSQL บน 192.168.1.2

• พอร์ต 5432

• โดยใช้บัญชีผู้ใช้ 'odoo'

• โดยมี 'pwd' เป็นรหัสผ่าน

• กรองเฉพาะ db ที่มีชื่อขึ้นต้นด้วย 'mycompany'

ในเซ็ท ไฟล์การกำหนดค่า:

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

SSL ระหว่าง Odoo และ PostgreSQL¶

ตั้งแต่ Odoo 11.0 คุณสามารถบังคับใช้การเชื่อมต่อ SSL ระหว่าง Odoo และ PostgreSQL ได้ ใน Odoo db_sslmode ควบคุมความปลอดภัย ssl ของการเชื่อมต่อด้วยค่าที่เลือกจาก 'ปิดการใช้งาน', 'อนุญาต', 'ต้องการ', 'ต้องการ', 'ตรวจสอบ-ca' หรือ 'ตรวจสอบเต็ม'

PostgreSQL Doc

เซิร์ฟเวอร์ในตัว¶

Odoo มีเซิร์ฟเวอร์ HTTP, cron และไลฟ์แชทในตัว โดยใช้มัลติเธรดหรือการประมวลผลหลายตัว

เซิร์ฟเวอร์ แบบมัลติเธรด เป็นเซิร์ฟเวอร์ที่เรียบง่ายกว่าซึ่งส่วนใหญ่ใช้สำหรับการพัฒนา การสาธิต และความเข้ากันได้กับระบบปฏิบัติการต่างๆ (รวมถึง Windows) เธรดใหม่จะถูกสร้างขึ้นสำหรับทุกคำขอ HTTP ใหม่ แม้แต่สำหรับการเชื่อมต่อที่มีอายุการใช้งานยาวนาน เช่น websocket เธรด cron daemonic พิเศษก็ถูกสร้างขึ้นเช่นกัน เนื่องจากข้อจำกัดของ Python (GIL) จึงไม่สามารถใช้ฮาร์ดแวร์ให้เกิดประโยชน์สูงสุดได้

เซิร์ฟเวอร์แบบมัลติเธรดเป็นเซิร์ฟเวอร์เริ่มต้นสำหรับคอนเทนเนอร์นักเทียบท่าด้วย มันถูกเลือกโดยปล่อยตัวเลือก --workers ออกหรือตั้งค่าเป็น 0

เซิร์ฟเวอร์ การประมวลผลหลายตัว เป็นเซิร์ฟเวอร์เต็มรูปแบบที่ใช้สำหรับการผลิตเป็นหลัก จะไม่รับผิดชอบต่อข้อจำกัด Python (GIL) เดียวกันในการใช้ทรัพยากร และด้วยเหตุนี้จึงใช้ฮาร์ดแวร์ให้เกิดประโยชน์สูงสุด กลุ่มคนทำงานถูกสร้างขึ้นเมื่อเริ่มต้นเซิร์ฟเวอร์ ระบบปฏิบัติการจะจัดคิวคำขอ HTTP ใหม่จนกว่าจะมีคนทำงานพร้อมที่จะประมวลผล ผู้ปฏิบัติงาน HTTP ที่ขับเคลื่อนด้วยเหตุการณ์พิเศษสำหรับไลฟ์แชทนั้นถูกสร้างขึ้นบนพอร์ตอื่น คนทำงาน cron พิเศษก็เกิดขึ้นเช่นกัน เก็บเกี่ยวกระบวนการที่กำหนดค่าได้จะตรวจสอบการใช้ทรัพยากรและสามารถหยุด/รีสตาร์ทผู้ปฏิบัติงานที่ไม่สำเร็จได้

เซิร์ฟเวอร์ที่มีการประมวลผลหลายตัวเลือกใช้ มันถูกเลือกโดยการตั้งค่าตัวเลือก --workers เป็นจำนวนเต็มที่ไม่ใช่ค่าว่าง

การคำนวณจำนวนคนงาน¶

• หลักทั่วไป : (#CPU * 2) + 1

• คนทำงาน Cron ต้องการ CPU

• คนงาน 1 คน ~= 6 ผู้ใช้พร้อมกัน

การคำนวณขนาดหน่วยความจำ¶

• เราถือว่าคำขอ 20% เป็นคำขอจำนวนมาก ในขณะที่ 80% เป็นคำขอที่เรียบง่ายกว่า

• ซึ่งทำงานหนัก เมื่อฟิลด์ที่คำนวณทั้งหมดได้รับการออกแบบมาอย่างดี คำขอ SQL จะได้รับการออกแบบมาอย่างดี ... คาดว่าจะใช้ RAM ประมาณ 1GB

• ในสถานการณ์เดียวกัน ส่วนของงานที่เบากว่านั้นคาดว่าจะใช้ RAM ประมาณ 150MB

RAM ที่ต้องการ = #worker * ( (light_worker_ratio * light_worker_ram_estimation) + (heavy_worker_ratio * heavy_worker_ram_estimation) )

ไลฟ์แชท¶

ในการประมวลผลหลายรายการ พนักงานไลฟ์แชทโดยเฉพาะจะเริ่มทำงานโดยอัตโนมัติและรับฟัง --gevent-port ตามค่าเริ่มต้น คำขอ HTTP จะเข้าถึงผู้ปฏิบัติงาน HTTP ปกติต่อไป แทนที่จะเป็นไลฟ์แชท คุณต้องปรับใช้พร็อกซีหน้า Odoo และเปลี่ยนเส้นทางคำขอขาเข้าที่มีเส้นทางขึ้นต้นด้วย /websocket/ ไปยังพนักงานไลฟ์แชท คุณต้องเริ่ม Odoo ใน --proxy-mode ดังนั้นจึงใช้ส่วนหัวของลูกค้าจริง (เช่น ชื่อโฮสต์ สคีม และ IP) แทนส่วนหัวของพร็อกซี

ตัวอย่างการกำหนดค่า¶

• เซิร์ฟเวอร์ที่มี 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 สำหรับ Odoo

ใน the configuration file:

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

ไม่ว่าจะเข้าถึงผ่านเว็บไซต์/เว็บลูกค้า หรือบริการเว็บ 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 แข็งแกร่งขึ้น¶

เพิ่มส่วนหัว Strict-Transport-Security ให้กับคำขอทั้งหมด เพื่อป้องกันไม่ให้เบราว์เซอร์ส่งคำขอ HTTP ธรรมดาไปยังโดเมนนี้ คุณจะต้องรักษาบริการ HTTPS ที่ใช้งานได้โดยมีใบรับรองที่ถูกต้องบนโดเมนนี้ตลอดเวลา ไม่เช่นนั้นผู้ใช้ของคุณจะเห็นการแจ้งเตือนด้านความปลอดภัยหรือไม่สามารถเข้าถึงได้เลย

บังคับใช้การเชื่อมต่อ HTTPS ในช่วงหนึ่งปีสำหรับผู้เยี่ยมชมทุกคนใน NGINX ด้วยบรรทัด:

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

สามารถกำหนดการกำหนดค่าเพิ่มเติมสำหรับคุกกี้ session_id ได้ คุณสามารถเพิ่มแฟล็ก 'ปลอดภัย' เพื่อให้แน่ใจว่าจะไม่ส่งผ่าน HTTP และ 'SameSite=Lax' เพื่อป้องกัน 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 จะเปิดเผยเฉพาะตำแหน่งข้อมูล HTTP หลักสำหรับเว็บลูกค้า เว็บไซต์ และ API บริการเว็บเท่านั้น เนื่องจาก Odoo ไม่ได้ควบคุมการสร้างคนทำงานอีกต่อไป จึงไม่สามารถตั้งค่าคนทำงาน cron หรือไลฟ์แชทได้

คนงาน Cron¶

จำเป็นต้องเริ่มต้นเซิร์ฟเวอร์ Odoo ในตัวตัวใดตัวหนึ่งถัดจากเซิร์ฟเวอร์ WSGI เพื่อประมวลผลงาน cron เซิร์ฟเวอร์นั้นจะต้องได้รับการกำหนดค่าให้ประมวลผลเฉพาะ crons ไม่ใช่คำขอ HTTP โดยใช้ตัวเลือก --no-http ตัวเลือก cli หรือการตั้งค่าไฟล์การกำหนดค่า http_enable = False

บนระบบที่คล้ายกับ Linux ขอแนะนำให้ใช้เซิร์ฟเวอร์ที่มีการประมวลผลหลายตัวบนเซิร์ฟเวอร์แบบมัลติเธรด เพื่อให้ได้รับประโยชน์จากการใช้ฮาร์ดแวร์ที่ดีขึ้นและความเสถียรที่เพิ่มขึ้น กล่าวคือ การใช้ --workers=-1 และ --max-cron-threads=n ตัวเลือก cli

ไลฟ์แชท¶

จำเป็นต้องใช้เซิร์ฟเวอร์ WSGI ที่เข้ากันได้กับ gevent เพื่อการทำงานที่ถูกต้องของฟีเจอร์ไลฟ์แชท เซิร์ฟเวอร์นั้นควรจะสามารถรองรับการเชื่อมต่อที่มีอายุการใช้งานยาวนานพร้อมกันจำนวนมากได้ แต่ไม่ต้องการพลังการประมวลผลมากนัก คำขอทั้งหมดที่เส้นทางเริ่มต้นด้วย /websocket/ ควรถูกส่งไปยังเซิร์ฟเวอร์นั้น ควรใช้เซิร์ฟเวอร์ WSGI ปกติ (ตามเธรด/ตามกระบวนการ) สำหรับคำขออื่นทั้งหมด

เซิร์ฟเวอร์ Odoo cron ยังสามารถใช้เพื่อให้บริการตามคำขอไลฟ์แชทได้ เพียงวางตัวเลือก cli --no-http จากเซิร์ฟเวอร์ cron และตรวจสอบให้แน่ใจว่าคำขอที่มีเส้นทางขึ้นต้นด้วย /websocket/ ถูกส่งไปยังเซิร์ฟเวอร์นี้โดยตรง บน --http-port (เซิร์ฟเวอร์แบบมัลติเธรด) หรือบน --gevent-port (เซิร์ฟเวอร์ที่มีการประมวลผลหลายตัว)

ให้บริการไฟล์ static และไฟล์แนบ¶

เพื่อความสะดวกในการพัฒนา Odoo จะให้บริการไฟล์ static และไฟล์แนบทั้งหมดในโมดูลโดยตรง อาจไม่เหมาะเมื่อพูดถึงประสิทธิภาพ และโดยทั่วไปไฟล์แบบ static ควรให้บริการโดยเซิร์ฟเวอร์ HTTP แบบ static

ให้บริการไฟล์ static¶

ไฟล์ static ของ Odoo จะอยู่ในโฟลเดอร์ static/ ของแต่ละโมดูล ดังนั้นไฟล์คงที่จึงสามารถให้บริการได้โดยการสกัดกั้นคำขอทั้งหมดที่ส่งไปยัง /MODULE/static/FILE และค้นหาโมดูลที่ถูกต้อง (และไฟล์) ในพาธแอดออนต่างๆ

ขอแนะนำให้ตั้งค่าส่วนหัว Content-Security-Policy: default-src 'none'' บนรูปภาพทั้งหมดที่ส่งโดยเว็บเซิร์ฟเวอร์ ซึ่งไม่จำเป็นอย่างยิ่งเนื่องจากผู้ใช้ไม่สามารถแก้ไข/แทรกเนื้อหาภายในโฟลเดอร์ static/ ของโมดูล และรูปภาพที่มีอยู่ถือเป็นที่สิ้นสุด (ไม่ได้ดึงทรัพยากรใหม่ด้วยตนเอง) อย่างไรก็ตาม ถือเป็นแนวปฏิบัติที่ดี

เมื่อใช้การกำหนดค่า NGINX (https) ข้างต้น ควรเพิ่มบล็อก แผนที่ และ ตำแหน่ง ต่อไปนี้เพื่อให้บริการไฟล์คงที่ผ่าน 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;
    }
}

คำสั่ง root และ try_files ที่แท้จริงนั้นขึ้นอยู่กับการติดตั้งของคุณ โดยเฉพาะใน --addons-path

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

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

ให้บริการไฟล์แนบ¶

ไฟล์แนบคือไฟล์ที่จัดเก็บไว้ในที่เก็บไฟล์ ซึ่ง Odoo ควบคุมการเข้าถึง ไม่สามารถเข้าถึงได้โดยตรงผ่านทางเว็บเซิร์ฟเวอร์แบบ static เนื่องจากการเข้าถึงไฟล์เหล่านี้จำเป็นต้องมีการค้นหาหลายครั้งในฐานข้อมูลเพื่อพิจารณาว่าไฟล์ถูกจัดเก็บไว้ที่ใด และผู้ใช้ปัจจุบันสามารถเข้าถึงไฟล์เหล่านั้นได้หรือไม่

อย่างไรก็ตาม เมื่อไฟล์ถูกพบและยืนยันสิทธิ์การเข้าถึงโดย Odoo แล้ว เป็นความคิดที่ดีที่จะให้บริการไฟล์โดยใช้เว็บเซิร์ฟเวอร์แบบ static แทน Odoo เพื่อให้ Odoo มอบหมายการให้บริการไฟล์ไปยังเว็บเซิร์ฟเวอร์แบบคงที่ X-Sendfile (apache) หรือ X-Accel (nginx) จะต้องเปิดใช้งานและกำหนดค่าบนเว็บเซิร์ฟเวอร์แบบ static เมื่อตั้งค่าแล้ว ให้เริ่ม Odoo ด้วย --x-sendfile แฟล็ก CLI (แฟล็กเฉพาะนี้ใช้สำหรับทั้ง X-Sendfile และ X-Accel)

ความปลอดภัย¶

สำหรับผู้เริ่มต้น โปรดทราบว่าการรักษาความปลอดภัยของระบบข้อมูลนั้นเป็นกระบวนการที่ต่อเนื่อง ไม่ใช่การดำเนินการเพียงครั้งเดียว คุณมีความปลอดภัยเท่าจุดอ่อนที่สุดในสภาพแวดล้อมของคุณเท่านั้น

ดังนั้น โปรดอย่าถือว่าส่วนนี้เป็นรายการมาตรการขั้นสูงสุดที่จะป้องกันปัญหาด้านความปลอดภัยทั้งหมด มีจุดมุ่งหมายเพียงเพื่อสรุปสิ่งสำคัญแรกที่คุณควรรวมไว้ในแผนปฏิบัติการด้านความปลอดภัยของคุณ ส่วนที่เหลือจะมาจากแนวทางปฏิบัติด้านความปลอดภัยที่ดีที่สุดสำหรับระบบปฏิบัติการและการเผยแพร่ของคุณ แนวทางปฏิบัติที่ดีที่สุดในแง่ของผู้ใช้ รหัสผ่าน และการจัดการการควบคุมการเข้าถึง และอื่นๆ

เมื่อปรับใช้เซิร์ฟเวอร์ที่เชื่อมต่อกับอินเทอร์เน็ต โปรดพิจารณาหัวข้อที่เกี่ยวข้องกับความปลอดภัยต่อไปนี้:

• ตั้งรหัสผ่านผู้ดูแลระบบระดับสูงที่รัดกุมเสมอ และจำกัดการเข้าถึงหน้าการจัดการฐานข้อมูลทันทีที่ตั้งค่าระบบ โปรดดู ความปลอดภัยของผู้จัดการฐานข้อมูล

• เลือกการเข้าสู่ระบบที่ไม่ซ้ำกันและรหัสผ่านที่รัดกุมสำหรับบัญชีผู้ดูแลระบบทั้งหมดในทุกฐานข้อมูล อย่าใช้ 'ผู้ดูแลระบบ' เป็นการเข้าสู่ระบบ อย่าใช้การล็อกอินเหล่านั้นสำหรับการดำเนินงานในแต่ละวัน เพียงเพื่อการควบคุม/จัดการการติดตั้งเท่านั้น ห้าม ใช้รหัสผ่านเริ่มต้นใดๆ เช่น ผู้ดูแลระบบ/ผู้ดูแลระบบ แม้แต่กับฐานข้อมูลการทดสอบ/ชั่วคราวก็ตาม

• อย่า ติดตั้งข้อมูลสาธิตบนเซิร์ฟเวอร์ที่เชื่อมต่อกับอินเทอร์เน็ต ฐานข้อมูลที่มีข้อมูลสาธิตประกอบด้วยการเข้าสู่ระบบและรหัสผ่านเริ่มต้นที่สามารถใช้เพื่อเข้าสู่ระบบของคุณและก่อให้เกิดปัญหาร้ายแรง แม้แต่ในระบบชั่วคราว/การพัฒนา

• ใช้ตัวกรองฐานข้อมูลที่เหมาะสม ( --db-filter) เพื่อจำกัดการมองเห็นฐานข้อมูลของคุณตามชื่อโฮสต์ โปรดดู dbfilter คุณยังอาจใช้ -d เพื่อจัดทำรายการฐานข้อมูลที่มีอยู่ (คั่นด้วยเครื่องหมายจุลภาค) ของคุณเองเพื่อกรอง แทนที่จะปล่อยให้ระบบดึงข้อมูลทั้งหมดจากแบ็กเอนด์ฐานข้อมูล

• เมื่อ db_name และ db_filter ได้รับการกำหนดค่าแล้ว และตรงกับฐานข้อมูลเดียวต่อชื่อโฮสต์ คุณควรตั้งค่าตัวเลือกการกำหนดค่า list_db เป็น False เพื่อป้องกันการแสดงรายการฐานข้อมูลทั้งหมด และเพื่อบล็อก เข้าถึงหน้าจอการจัดการฐานข้อมูล (ซึ่งแสดงเป็น --no-database-list ตัวเลือกบรรทัดคำสั่ง)

• ตรวจสอบให้แน่ใจว่าผู้ใช้ PostgreSQL (--db_user) เป็น ไม่ใช่ ผู้ใช้ระดับสูง และฐานข้อมูลของคุณเป็นของผู้ใช้รายอื่น ตัวอย่างเช่น ผู้ใช้ขั้นสูง postgres อาจเป็นเจ้าของได้ หากคุณใช้ db_user ที่ไม่มีสิทธิพิเศษโดยเฉพาะ ดูเพิ่มเติมที่ กำลังกำหนดค่า Odoo

• อัปเดตการติดตั้งอยู่เสมอโดยการติดตั้งบิวด์ล่าสุดเป็นประจำ ไม่ว่าจะผ่าน GitHub หรือโดยการดาวน์โหลดเวอร์ชันล่าสุดจาก https://www.odoo.com/page/download หรือ http://nightly.odoo.com

• กำหนดค่าเซิร์ฟเวอร์ของคุณในโหมดหลายกระบวนการด้วยขีดจำกัดที่เหมาะสมซึ่งตรงกับการใช้งานทั่วไปของคุณ (หน่วยความจำ/CPU/หมดเวลา) ดูเพิ่มเติม เซิร์ฟเวอร์ในตัว

• เรียกใช้ Odoo ด้านหลังเว็บเซิร์ฟเวอร์ที่ให้การยกเลิก HTTPS ด้วยใบรับรอง SSL ที่ถูกต้อง เพื่อป้องกันการดักฟังการสื่อสารข้อความที่ชัดเจน ใบรับรอง SSL มีราคาถูกและมีตัวเลือกฟรีมากมาย กำหนดค่าเว็บพร็อกซีเพื่อจำกัดขนาดของคำขอ ตั้งค่าการหมดเวลาที่เหมาะสม จากนั้นเปิดใช้งานตัวเลือก proxy mode ดูเพิ่มเติม HTTPS

• หากคุณต้องการอนุญาตให้เข้าถึง SSH ระยะไกลไปยังเซิร์ฟเวอร์ของคุณ ตรวจสอบให้แน่ใจว่าได้ตั้งรหัสผ่านที่รัดกุมสำหรับบัญชี ทั้งหมด ไม่ใช่แค่ root ขอแนะนำอย่างยิ่งให้ปิดการใช้งานการตรวจสอบสิทธิ์โดยใช้รหัสผ่านโดยสิ้นเชิง และอนุญาตเฉพาะการตรวจสอบสิทธิ์กุญแจสาธารณะเท่านั้น นอกจากนี้ ให้พิจารณาจำกัดการเข้าถึงผ่าน VPN โดยอนุญาตเฉพาะ IP ที่เชื่อถือได้ในไฟร์วอลล์ และ/หรือใช้งานระบบตรวจจับแบบ brute-force เช่น fail2ban หรือเทียบเท่า

• พิจารณาติดตั้งการจำกัดอัตราที่เหมาะสมบนพร็อกซีหรือไฟร์วอลล์ของคุณ เพื่อป้องกันการโจมตีแบบ brute-force และการโจมตีแบบปฏิเสธบริการ ดูเพิ่มเติม การปิดกั้นการโจมตีแบบ Brute Force สำหรับมาตรการเฉพาะ

  ผู้ให้บริการเครือข่ายหลายรายจัดให้มีการบรรเทาการโจมตีแบบ Distributed Denial of Service (DDOS) โดยอัตโนมัติ แต่มักเป็นบริการเสริม ดังนั้นคุณควรปรึกษากับผู้ให้บริการเครือข่ายเหล่านั้น

• เมื่อใดก็ตามที่เป็นไปได้ ให้โฮสต์อินสแตนซ์การสาธิต/การทดสอบ/การแสดงแบบสาธารณะของคุณบนเครื่องที่แตกต่างจากเครื่องที่ใช้งานจริง และใช้มาตรการรักษาความปลอดภัยเช่นเดียวกับการผลิต

• หากเซิร์ฟเวอร์ Odoo แบบสาธารณะของคุณสามารถเข้าถึงทรัพยากรเครือข่ายภายในหรือบริการที่ละเอียดอ่อน (เช่น ผ่าน VLAN ส่วนตัว) ให้ใช้กฎไฟร์วอลล์ที่เหมาะสม เพื่อปกป้องทรัพยากรภายในเหล่านั้น สิ่งนี้จะช่วยให้แน่ใจว่าเซิร์ฟเวอร์ Odoo จะไม่ถูกใช้โดยไม่ได้ตั้งใจ (หรือเป็นผลมาจากการกระทำของผู้ใช้ที่เป็นอันตราย) เพื่อเข้าถึงหรือรบกวนทรัพยากรภายในเหล่านั้น โดยทั่วไปสามารถทำได้โดยใช้กฎ DENY เริ่มต้นขาออกบนไฟร์วอลล์ จากนั้นให้อนุญาตเฉพาะการเข้าถึงทรัพยากรภายในที่เซิร์ฟเวอร์ Odoo ต้องการเข้าถึงอย่างชัดเจนเท่านั้น การควบคุมการเข้าถึงการรับส่งข้อมูล Systemd IP อาจมีประโยชน์ในการใช้การควบคุมการเข้าถึงเครือข่ายต่อกระบวนการ

• หากเซิร์ฟเวอร์ Odoo แบบสาธารณะของคุณอยู่ด้านหลังไฟร์วอลล์แอปพลิเคชันบนเว็บ, โหลดบาลานเซอร์, บริการป้องกัน DDoS ที่โปร่งใส (เช่น CloudFlare) หรืออุปกรณ์ระดับเครือข่ายที่คล้ายกัน คุณอาจต้องการหลีกเลี่ยงการเข้าถึงระบบ Odoo โดยตรง โดยทั่วไป การเก็บที่อยู่ IP ปลายทางของเซิร์ฟเวอร์ Odoo ของคุณไว้เป็นความลับนั้นเป็นเรื่องยาก ตัวอย่างเช่น อาจปรากฏในบันทึกของเว็บเซิร์ฟเวอร์เมื่อสืบค้นระบบสาธารณะ หรือในส่วนหัวของอีเมลที่โพสต์จาก Odoo ในสถานการณ์เช่นนี้ คุณอาจต้องการกำหนดค่าไฟร์วอลล์ของคุณเพื่อไม่ให้เข้าถึงจุดสิ้นสุดแบบสาธารณะ ยกเว้นจากที่อยู่ IP เฉพาะของ WAF, โหลดบาลานเซอร์ หรือบริการพร็อกซีของคุณ ผู้ให้บริการเช่น CloudFlare มักจะรักษารายการสาธารณะของช่วงที่อยู่ IP ของตนเพื่อจุดประสงค์นี้

• หากคุณโฮสต์ลูกค้าหลายราย ให้แยกข้อมูลและไฟล์ของลูกค้าออกจากกันโดยใช้คอนเทนเนอร์หรือเทคนิค "การกักขัง" ที่เหมาะสม

• ตั้งค่าการสำรองข้อมูลรายวันของฐานข้อมูลและข้อมูลพื้นที่จัดเก็บไฟล์ของคุณ และคัดลอกไปยังเซิร์ฟเวอร์การเก็บถาวรระยะไกลที่ไม่สามารถเข้าถึงได้จากเซิร์ฟเวอร์เอง

• ขอแนะนำอย่างยิ่งให้ปรับใช้ Odoo บน Linux บน Windows หากคุณเลือกที่จะปรับใช้บนแพลตฟอร์ม Windows ควรดำเนินการตรวจสอบการรักษาความปลอดภัยอย่างเข้มงวดของเซิร์ฟเวอร์และอยู่นอกเหนือขอบเขตของคู่มือนี้

การปิดกั้นการโจมตีแบบ Brute Force¶

สำหรับการปรับใช้ผ่านอินเทอร์เน็ต การโจมตีแบบ bruteforce ต่อรหัสผ่านผู้ใช้เป็นเรื่องปกติมาก และภัยคุกคามนี้ไม่ควรละเลยสำหรับเซิร์ฟเวอร์ 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

ตัวอย่างเช่น ข้อกำหนดตัวกรอง failed2ban ต่อไปนี้ควรตรงกับการเข้าสู่ระบบที่ไม่สำเร็จ:

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

สามารถใช้กับคำจำกัดความของคุกเพื่อป้องกัน IP ที่ถูกโจมตีบน HTTP(S)

ต่อไปนี้คือลักษณะที่ปรากฏสำหรับการบล็อก IP เป็นเวลา 15 นาที เมื่อตรวจพบการพยายามเข้าสู่ระบบที่ไม่สำเร็จเกินกว่า 10 ครั้งจาก IP เดียวกันภายใน 1 นาที:

[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 ซึ่งมีรายละเอียดวิธีการรีเซ็ตและเข้ารหัสรหัสผ่านหลักอีกครั้งด้วยตนเอง

เมื่อสร้างฐานข้อมูลภายในองค์กรใหม่ รหัสผ่านหลักแบบสุ่มจะถูกสร้างขึ้น Odoo ขอแนะนำให้ใช้รหัสผ่านนี้เพื่อรักษาความปลอดภัยฐานข้อมูล รหัสผ่านนี้จะถูกใช้งานตามค่าเริ่มต้น ดังนั้นจึงมีรหัสผ่านหลักที่ปลอดภัยสำหรับการปรับใช้ Odoo ภายในองค์กร

รหัสผ่านหลักระบุไว้ในไฟล์กำหนดค่า Odoo (odoo.conf หรือ odoorc (ไฟล์ที่ซ่อนอยู่)) ต้องใช้รหัสผ่านหลักของ Odoo เพื่อแก้ไข สร้าง หรือลบฐานข้อมูลผ่านทางอินเทอร์เฟซผู้ใช้แบบกราฟิก (GUI)

ค้นหาไฟล์การกำหนดค่า¶

ขั้นแรก ให้เปิดไฟล์การกำหนดค่า Odoo (odoo.conf หรือ odoorc (ไฟล์ที่ซ่อน))

เปลี่ยนรหัสผ่านเก่า¶

เมื่อเปิดไฟล์ที่เหมาะสมแล้ว ให้ดำเนินการแก้ไขรหัสผ่านเก่าในไฟล์กำหนดค่าเป็นรหัสผ่านชั่วคราว

รีสตาร์ทเซิร์ฟเวอร์ Odoo¶

หลังจากตั้งรหัสผ่านชั่วคราวแล้ว **จำเป็นต้องรีสตาร์ทเซิร์ฟเวอร์ Odoo

ใช้เว็บอินเตอร์เฟสเพื่อเข้ารหัสรหัสผ่านอีกครั้ง¶

ขั้นแรก ไปที่ /web/database/manager หรือ http://server_ip:port/web/database/manager ในเบราว์เซอร์

จากนั้นคลิก ตั้งรหัสผ่านหลัก และพิมพ์รหัสผ่านชั่วคราวที่เลือกไว้ก่อนหน้านี้ลงในช่อง รหัสผ่านหลัก ทำตามขั้นตอนนี้ พิมพ์ รหัสผ่านหลักใหม่ รหัสผ่านหลักใหม่ จะถูกแฮช (หรือเข้ารหัส) เมื่อคลิกปุ่ม ดำเนินการต่อ

ณ จุดนี้ รหัสผ่านได้รับการรีเซ็ตเรียบร้อยแล้ว และรหัสผ่านใหม่เวอร์ชันแฮชจะปรากฏในไฟล์การกำหนดค่า

เบราว์เซอร์ที่รองรับ¶

Odoo รองรับเบราว์เซอร์เดสก์ท็อปและมือถือหลักทั้งหมดที่มีอยู่ในตลาด เท่าที่ได้รับการสนับสนุนจากผู้เผยแพร่

นี่คือเบราว์เซอร์ที่รองรับ:

• Google Chrome

• Mozilla Firefox

• Microsoft Edge

• Apple Safari

1

เพื่อให้การติดตั้ง Odoo หลายรายการใช้ฐานข้อมูล PostgreSQL เดียวกัน หรือเพื่อจัดหาทรัพยากรการประมวลผลเพิ่มเติมให้กับซอฟต์แวร์ทั้งสอง

2

ในทางเทคนิคแล้ว เครื่องมืออย่าง socat สามารถใช้กับซ็อกเก็ตพร็อกซี UNIX ข้ามเครือข่ายได้ แต่ส่วนใหญ่ใช้สำหรับซอฟต์แวร์ที่สามารถใช้ได้ผ่านซ็อกเก็ต UNIX เท่านั้น

3

หรือสามารถเข้าถึงได้ผ่านเครือข่ายสวิตช์แพ็กเก็ตภายในเท่านั้น แต่ต้องใช้สวิตช์ที่ปลอดภัย การป้องกันการปลอมแปลง ARP และขัดขวางการใช้ WiFi แม้แต่บนเครือข่ายสวิตช์แพ็กเก็ตที่ปลอดภัย ขอแนะนำให้ปรับใช้ผ่าน HTTPS และค่าใช้จ่ายที่เป็นไปได้จะลดลง เนื่องจากใบรับรอง "ที่ลงนามด้วยตนเอง" จะปรับใช้ในสภาพแวดล้อมที่มีการควบคุมได้ง่ายกว่าบนอินเทอร์เน็ต