Linh kiện

Privet là một API khám phá thiết bị trên đám mây mà các dịch vụ đám mây sử dụng. Tài liệu này được sắp xếp thành các phần sau:

  1. Giới thiệu: giới thiệu về Privet
  2. Khám phá: cơ chế khám phá tại địa phương
  3. Thông báo: thông báo khám phá địa phương
  4. API: API Privet dành cho các thiết bị trên đám mây chung
  5. API Printer: API Privet mà các máy in sử dụng
  6. Phụ lục: sơ đồ bổ sung

1. Giới thiệu

Thiết bị được kết nối với đám mây có nhiều lợi ích. Họ có thể sử dụng các dịch vụ chuyển đổi trực tuyến, lưu trữ các hàng đợi công việc trong khi thiết bị không có kết nối mạng và truy cập được từ bất cứ đâu trên thế giới. Tuy nhiên, khi một người dùng có thể truy cập được nhiều thiết bị trên đám mây, chúng tôi cần cung cấp phương thức để tìm thiết bị gần nhất dựa trên vị trí. Mục đích của giao thức Privet là liên kết tính linh hoạt của các thiết bị trên đám mây với cơ chế khám phá cục bộ phù hợp để các thiết bị dễ dàng được phát hiện trong môi trường mới.

Mục tiêu của giao thức này là:
  • đặt thiết bị trên đám mây ở chế độ có thể tìm thấy tại địa phương
  • đăng ký thiết bị trên đám mây bằng dịch vụ đám mây
  • liên kết thiết bị đã đăng ký với đại diện đám mây của chúng
  • bật chức năng ngoại tuyến
  • đơn giản hoá việc triển khai để các thiết bị nhỏ có thể sử dụng

Giao thức Privet bao gồm 2 phần chính: khám phá và API. Khám phá được dùng để tìm thiết bị trên mạng cục bộ, còn API này được dùng để lấy thông tin về thiết bị và thực hiện một số thao tác. Xuyên suốt tài liệu này, thiết bị đề cập đến một thiết bị được kết nối với đám mây đang triển khai giao thức Privet.

2. Tiềm năng khám phá

Discovery là giao thức dựa trên zeroconf (mDNS + DNS-SD). Thiết bị PHẢI triển khai địa chỉ IPv4 Link-Local. Thiết bị PHẢI tuân thủ các thông số mDNS và DNS-SD.

Thiết bị PHẢI thực hiện việc giải quyết xung đột tên theo các thông số kỹ thuật ở trên.

2.1. Loại dịch vụ

Công cụ Khám phá dịch vụ DNS sử dụng định dạng sau cho các loại dịch vụ: _applicationprotocol._transportprotocol. Trong trường hợp giao thức Privet, loại dịch vụ dành cho DNS-SD phải là: _privet._tcp

Thiết bị cũng có thể triển khai các loại dịch vụ khác. Bạn nên sử dụng cùng một tên phiên bản dịch vụ cho tất cả các loại dịch vụ mà thiết bị triển khai. Ví dụ: một máy in có thể triển khai "Printer XYZ._privet._tcp" và "Printer XYZ._printer._tcp" các dịch vụ. Thao tác này sẽ đơn giản hoá việc thiết lập cho người dùng. Tuy nhiên, ứng dụng Privet sẽ chỉ tìm "_privet._tcp"

Ngoài loại dịch vụ chính, thiết bị PHẢI quảng cáo bản ghi PTR cho(các) loại phụ tương ứng (xem thông số DNS-SD: "7.1). Bảng liệt kê phiên bản chọn lọc (Loại phụ)" Định dạng phải như sau: _<subtype>._sub._privet._tcp

Hiện tại, loại thiết bị phụ duy nhất được hỗ trợ là máy in. Vì vậy, tất cả máy in PHẢI quảng cáo hai bản ghi PTR:

  • _privet._tcp.local.
  • _printer._sub._privet._tcp.local.

2.2. Bản ghi TXT

Khám phá dịch vụ DNS xác định các trường để thêm thông tin không bắt buộc về một dịch vụ trong bản ghi TXT. Bản ghi TXT bao gồm các cặp khoá/giá trị. Mỗi cặp khoá/giá trị bắt đầu từ byte độ dài, theo sau là tối đa 255 byte văn bản. Khoá là văn bản trước ký tự ‘=’ đầu tiên và giá trị là văn bản sau ký tự “=” đầu tiên cho đến cuối. Thông số kỹ thuật không cho phép ghi giá trị nào trong bản ghi. Trong trường hợp đó, ký tự sẽ không có ký tự "=" HOẶC không có văn bản sau ký tự "=". (Xem thông số DNS-SD: "6.1). Quy tắc chung về định dạng cho Bản ghi TXT DNS" cho định dạng bản ghi DNS TXT và "6.2. Kích thước bản ghi DNS-SD TXT" cho độ dài đề xuất.

Privet yêu cầu thiết bị gửi các cặp giá trị/khoá sau đây trong bản ghi TXT. Các chuỗi khoá/giá trị không phân biệt chữ hoa chữ thường, ví dụ: "CS=online" và "cs=LIVE" giống nhau. Thông tin trong bản ghi TXT PHẢI giống với thông tin có thể truy cập được qua /info API (xem 4.1). mục API.

Bạn nên duy trì kích thước bản ghi TXT dưới 512 byte.

2.2.1. txtvers

Phiên bản của cấu trúc TXT. txtvers PHẢI là bản ghi đầu tiên của cấu trúc TXT. Hiện tại, phiên bản duy nhất được hỗ trợ là 1.

txtvers=1

2.2.2. doanh nghiệp

Cung cấp tên thiết bị có thể đọc được của thiết bị. Ví dụ:

ty=Google Cloud Ready Printer Model XYZ

2.2.3. ghi chú (không bắt buộc)

Cung cấp tên thiết bị có thể đọc được của thiết bị. Ví dụ:

note=1st floor lobby printer

Lưu ý: Đây là khóa không bắt buộc và có thể bỏ qua. Tuy nhiên, nếu có, người dùng PHẢI có thể sửa đổi giá trị này. Bạn phải sử dụng cùng một nội dung mô tả khi đăng ký thiết bị.

2.2.4. url

URL máy chủ mà thiết bị này được kết nối (bao gồm giao thức). Ví dụ:

url=https://www.google.com/cloudprint

2.2.5. loại

Danh sách được phân tách bằng dấu phẩy các loại thiết bị phụ được thiết bị này hỗ trợ. Định dạng là: "type=_subtype1,_subtype2" Hiện tại, loại phụ thiết bị duy nhất được hỗ trợ là máy in.

type=printer

Mỗi loại phụ được liệt kê phải được quảng cáo bằng bản ghi PTR tương ứng. Đối với mỗi loại dịch vụ phụ mà hệ thống hỗ trợ, bạn phải có một mục tương ứng. Tên loại dịch vụ phụ (<subtype>._sub._privet._tcp) phải bằng loại thiết bị tại đây.

2.2.6. id

Mã thiết bị. Nếu thiết bị chưa được đăng ký, khóa này phải có mặt, nhưng giá trị phải trống. Ví dụ:

  id=11111111-2222-3333-4444-555555555555
  id=

2.2.7. cs

Cho biết trạng thái kết nối hiện tại của thiết bị. Bốn giá trị có thể được xác định trong quy cách này.

  • "online" cho biết thiết bị hiện đang được kết nối với đám mây.
  • "ngoại tuyến" cho biết rằng thiết bị đã có trên mạng cục bộ nhưng không thể giao tiếp với máy chủ.
  • "connection" cho biết thiết bị đang thực hiện trình tự khởi động và chưa hoàn toàn trực tuyến.
  • "chưa được định cấu hình" cho biết rằng quyền truy cập Internet của thiết bị chưa được định cấu hình. Giá trị này hiện không được sử dụng nhưng có thể hữu ích trong các phiên bản sau này của thông số kỹ thuật.
Ví dụ:
  • cs=online
  • cs=ngoại tuyến
  • cs=connection

Nếu bạn đã đăng ký thiết bị với một đám mây, thì khi khởi động, thiết bị phải kiểm tra kết nối với một máy chủ để phát hiện trạng thái kết nối (ví dụ: gọi API đám mây để nhận chế độ cài đặt thiết bị). Thiết bị có thể sử dụng trạng thái kết nối với kênh thông báo (ví dụ: WebRTC) để báo cáo giá trị này. Những thiết bị chưa đăng ký khi khởi động có thể ping một miền để phát hiện trạng thái kết nối của các thiết bị đó (ví dụ: ping www.google.com đối với các thiết bị in trên đám mây).

3. Thông báo

Khi khởi động thiết bị, tắt nguồn hoặc thay đổi trạng thái, thiết bị PHẢI thực hiện bước thông báo như được mô tả trong thông số kỹ thuật mDNS. Thông báo này PHẢI gửi thông báo tương ứng ít nhất hai lần với ít nhất một khoảng thời gian một giây giữa các thông báo đó.

3.1. Khởi động

Khi khởi động thiết bị, ứng dụng PHẢI thực hiện việc thăm dò và thông báo các bước như được mô tả trong thông số kỹ thuật của mDNS. Bản ghi SRV, PTR và TXT phải được gửi trong trường hợp này. Bạn nên nhóm tất cả bản ghi vào một phản hồi DNS nếu có thể. Nếu không, bạn nên sử dụng thứ tự sau: bản ghi SRV, PTR, TXT.

3.2. Tắt

Khi tắt thiết bị, bạn PHẢI cố gắng thông báo cho tất cả các bên quan tâm về vấn đề này bằng cách gửi "goodbye package" với TTL=0 (như mô tả trong tài liệu mDNS).

3.3. Cập nhật

Trong trường hợp có thông tin mô tả trong TXT đã thay đổi, thiết bị PHẢI gửi thông báo cập nhật. Chỉ cần gửi bản ghi TXT mới trong trường hợp này là đủ. Ví dụ: sau khi thiết bị được đăng ký, thiết bị PHẢI gửi thông báo cập nhật bao gồm cả mã thiết bị mới.

4. API

Sau khi phát hiện thiết bị trên đám mây, thiết bị sẽ bật tính năng giao tiếp trực tiếp với thiết bị qua mạng cục bộ. Tất cả các API đều dựa trên HTTP 1.1. Các định dạng dữ liệu được dựa trên JSON. Yêu cầu API có thể là yêu cầu GET hoặc POST.

Mỗi yêu cầu PHẢI chứa "X-Privet-Token" hợp lệ. Yêu cầu CHỈ được phép có tiêu đề "X-Privet-Token" trống là yêu cầu /privet/info (lưu ý rằng tiêu đề PHẢI vẫn còn). Nếu tiêu đề "X-Privet-Token" bị thiếu, thiết bị PHẢI phản hồi bằng lỗi HTTP 400 sau:

HTTP/1.1 400 Missing X-Privet-Token header.

Nếu tiêu đề "X-Privet-Token" trống hoặc không hợp lệ, thiết bị PHẢI phản hồi bằng "invalid X-Privet-Token error" (invalid_x_privet_token, xem phần Lỗi để biết chi tiết). Trường hợp ngoại lệ duy nhất là API /info. Để biết thêm thông tin về lý do tại sao việc này được thực hiện và cách tạo mã thông báo, hãy xem Phụ lục A: Các cuộc tấn công và ngăn chặn XSSI và XSRF.

Nếu API được yêu cầu không tồn tại hoặc không được hỗ trợ, thiết bị PHẢI trả về lỗi HTTP 404.

4.1. Khả năng sử dụng API

Trước khi ALL API được hiển thị (bao gồm cả /info API), thiết bị PHẢI liên hệ với máy chủ để kiểm tra các chế độ cài đặt cục bộ. Các tùy chọn cài đặt cục bộ PHẢI được giữ nguyên giữa các lần khởi động lại. Nếu không có máy chủ, bạn nên sử dụng chế độ cài đặt cục bộ đã biết gần đây nhất. Nếu bạn chưa đăng ký, thiết bị phải tuân theo chế độ cài đặt mặc định.

Thiết bị Cloud Print PHẢI làm theo các bước dưới đây để đăng ký, nhận và cập nhật chế độ cài đặt cục bộ.

4.1.1. Đơn đăng ký

Khi thiết bị đăng ký, thiết bị PHẢI chỉ định thông số "local_settings" như sau:

{
       "current": {
                "local_discovery": true,
                "access_token_enabled": true,
                "printer/local_printing_enabled": true,
                "printer/conversion_printing_enabled": true,
                "xmpp_timeout_value": 300
        }
}
Bạn có thể đặt các chế độ cài đặt sau:
Tên giá trịLoại giá trịMô tả
khám_phá_nội_dungbooleanCho biết liệu chức năng khám phá cục bộ có được cho phép hay không. Nếu "false", thì tất cả API cục bộ (bao gồm cả /thông tin) và khám phá DNS-SD đều phải bị tắt. Theo mặc định, các thiết bị mới đăng ký phải đáp ứng "true"
access_token_enabledboolean (không bắt buộc)Cho biết liệu API /accesstoken có nên được hiển thị trên mạng cục bộ hay không. Theo mặc định phải là "true"
máy in/local_printing_enabledboolean (không bắt buộc)Cho biết liệu chức năng in cục bộ (/printer/createjob, /printer/submitdoc, /printer/jobstate) có nên được hiển thị trên mạng cục bộ không. Theo mặc định phải là "true"
máy in/lượt_chuyển_đổi_in_chuyển_đổiboolean (không bắt buộc)Cho biết liệu lệnh in cục bộ có thể gửi lệnh in đến máy chủ để chuyển đổi hay không. Chỉ có ý nghĩa khi tính năng in cục bộ được bật.
giá trị xmpp_timeout_valueint (không bắt buộc)Cho biết số giây giữa các ping kênh WebRTC. Theo mặc định PHẢI là 300 (5 phút) trở lên.

Lưu ý quan trọng: Việc thiếu bất kỳ giá trị tuỳ chọn nào cho biết thiết bị không hoàn toàn hỗ trợ chức năng tương ứng.

4.1.2. Khởi động

Khi khởi động thiết bị, máy phải liên hệ với máy chủ để kiểm tra xem những API nào có thể hiển thị trong mạng cục bộ. Đối với máy in được kết nối với Cloud Print, họ phải gọi:

/cloudprint/printer?printerid=<printer_id>
hoặc
/cloudprint/list

Bạn nên ưu tiên /tCPA/printer hơn /tCPA/list, nhưng cả hai cách này đều hiệu quả.

API này trả về các thông số thiết bị hiện tại, bao gồm cả chế độ cài đặt cho API cục bộ. Câu trả lời từ máy chủ sẽ có định dạng như sau:

"local_settings": {
        "current": {
                "local_discovery": true,
                "access_token_enabled": true,
                "printer/local_printing_enabled": true,
                "printer/conversion_printing_enabled": true,
                "xmpp_timeout_value": 300
         },
         "pending": {
                "local_discovery": true,
                "access_token_enabled": true,
                "printer/local_printing_enabled": false,
                "printer/conversion_printing_enabled": false,
                "xmpp_timeout_value": 500
         }
}

"current" đối tượng cho biết cài đặt đang có hiệu lực.

"Pending" đối tượng cho biết các chế độ cài đặt nên được áp dụng cho thiết bị (có thể thiếu đối tượng này).

Sau khi thiết bị thấy "Pending" cài đặt, thiết bị PHẢI cập nhật trạng thái (xem bên dưới).

4.1.3. Cập nhật

Nếu cần cập nhật chế độ cài đặt, hệ thống sẽ gửi một thông báo WebRTC đến thiết bị. Thông báo sẽ có định dạng như sau:

<device_id>/update_settings

Khi nhận được thông báo như vậy, thiết bị PHẢI truy vấn máy chủ để tải chế độ cài đặt mới nhất. Thiết bị Cloud Print PHẢI sử dụng:

/cloudprint/printer?printerid=<printer_id>

Sau khi thiết bị nhìn thấy " pending" do kết quả của API /tCPA/printer (khi khởi động hoặc do thông báo), thiết bị PHẢI cập nhật trạng thái nội bộ để ghi nhớ các chế độ cài đặt mới. API PHẢI gọi API máy chủ để xác nhận chế độ cài đặt mới. Đối với Máy in trên đám mây, thiết bị PHẢI gọi /tCPA/update API và sử dụng thông số "local_settings" trong quá trình đăng ký.

Khi kết nối lại với kênh WebRTC, thiết bị PHẢI gọi /tCPA/printer API để kiểm tra xem cài đặt cục bộ có được thay đổi kể từ lần gần đây nhất hay không.

4.1.3.1. Đang chờ cài đặt cục bộ

"local_settings" tham số mà thiết bị sử dụng để gọi API máy chủ PHẢI KHÔNG chứa "Pending".

4.1.3.2. Cài đặt cục bộ hiện tại

CHỈ thiết bị mới có thể thay đổi phần "hiện tại" của "local_settings" Tất cả những người khác sẽ thay đổi phần "Pending" và đợi cho đến khi các thay đổi được áp dụng cho phần "current" theo thiết bị.

4.1.4. Khi không có mạng

Khi không thể liên hệ với máy chủ trong khi khởi động, sau khi thông báo, thiết bị PHẢI sử dụng các chế độ cài đặt cục bộ đã biết gần đây nhất.

4.1.5. Xóa thiết bị khỏi dịch vụ

Nếu thiết bị đã bị xóa khỏi dịch vụ (ví dụ: GCP), thông báo OpenGL sẽ được gửi đến thiết bị. Thông báo sẽ có định dạng như sau:

<device_id>/delete

Khi nhận được thông báo như vậy, thiết bị PHẢI chuyển đến máy chủ để kiểm tra trạng thái thông báo. Thiết bị in trên đám mây PHẢI sử dụng:

/cloudprint/printer?printerid=<printer_id>

Thiết bị PHẢI nhận được câu trả lời HTTP thành công với nội dung mô tả thành công=không có thiết bị/máy in. Điều đó có nghĩa là thiết bị đã bị xóa khỏi máy chủ và thiết bị PHẢI xóa thông tin đăng nhập của thiết bị đó rồi chuyển đến chế độ cài đặt mặc định ban đầu.

Bất cứ khi nào thiết bị nhận được phản hồi cho biết thiết bị đã bị xoá do API /gtag/printer (khởi động, thông báo cài đặt cập nhật, ping hằng ngày), thiết bị PHẢI xoá thông tin xác thực và chuyển sang chế độ mặc định.

4.2. API /privet/info

API thông tin là MANDATORY và PHẢI được triển khai bởi mọi thiết bị. Đây là yêu cầu GET HTTP cho "/privet/info" url: GET /privet/info HTTP/1.1

API thông tin trả về thông tin cơ bản về một thiết bị và chức năng mà API này hỗ trợ. API này KHÔNG bao giờ được thay đổi trạng thái của thiết bị hoặc thực hiện bất kỳ hành động nào vì API này dễ bị tấn công bằng XSRF. Đây là API CHỈ được phép có tiêu đề "X-Privet-Token" trống. Ứng dụng khách nên gọi /privet/info API với "X-Privet-Token" tiêu đề được đặt thành X-Privet-Token: ""

API thông tin PHẢI trả về dữ liệu nhất quán với dữ liệu có sẵn trong bản ghi TXT trong khi khám phá.

4.2.1. Đầu vào

/privet/info API không có tham số đầu vào.

4.2.2. Hai chiều

/privet/info API trả về thông tin cơ bản về thiết bị và chức năng được hỗ trợ.

Cột TXT cho biết trường tương ứng trong bản ghi DNS-SD TXT.

Tên giá trịLoại giá trịMô tảTXT
phiên bảnstringPhiên bản API cao nhất (major.minor) được hỗ trợ, hiện tại 1.0
tênstringTên thiết bị có thể đọc được.doanh nghiệp
nội dung mô tảstring(không bắt buộc) Nội dung mô tả thiết bị. PHẢI là người dùng có thể sửa đổi.ghi chú
urlstringURL của máy chủ mà thiết bị này đang trò chuyện. URL PHẢI bao gồm thông số kỹ thuật của giao thức, ví dụ: https://www.google.com/tCPA.url
loạidanh sách chuỗiDanh sách các loại thiết bị được hỗ trợ.loại
idstringId thiết bị, trống nếu thiết bị chưa được đăng ký. id
trạng thái [device_state]stringTrạng thái của thiết bị.
Không hoạt động có nghĩa là thiết bị đã sẵn sàng
đang xử lý có nghĩa là thiết bị đang bận và chức năng có thể bị giới hạn trong một khoảng thời gian
đã dừng có nghĩa là thiết bị không hoạt động và người dùng cần có sự can thiệp
trạng thái kết nốistringTrạng thái kết nối với máy chủ (base_url)
trực tuyến – có kết nối
ngoại tuyến – chưa kết nối
kết nối – thực hiện các bước khởi động
chưa định cấu hình – chưa kết nối
Một thiết bị đã đăng ký có thể báo cáo trạng thái kết nối dựa trên trạng thái của kênh thông báo (ví dụ: trạng thái kết nối WebRTC).
cs
nhà sản xuấtstringTên nhà sản xuất thiết bị
kiểu máystringMẫu thiết bị
số_dãystringMã nhận dạng thiết bị duy nhất. Trong quy cách này, PHẢI PHẢI là UUID. (Thông số kỹ thuật GCP 1.1)
(không bắt buộc) Bạn nên sử dụng cùng một mã số sê-ri ở mọi nơi để khách hàng có thể xác định cùng một thiết bị. Ví dụ: các máy in triển khai IPP có thể sử dụng mã số sê-ri này trong trường "printer-device-id".
chương trình cơ sởstringPhiên bản chương trình cơ sở của thiết bị
thời gian hoạt độngintSố giây khởi động thiết bị.
thiết lập_urlstringURL (không bắt buộc) (bao gồm giao thức) của trang kèm theo hướng dẫn thiết lập
support_urlstringURL (không bắt buộc) (bao gồm giao thức) của trang có hỗ trợ, Thông tin câu hỏi thường gặp
cập nhật_urlstringURL (không bắt buộc) (bao gồm giao thức) của trang kèm theo hướng dẫn cập nhật chương trình cơ sở
x-privet-tokenstringGiá trị của tiêu đề X-Privet-Token phải được truyền đến tất cả các API để ngăn chặn các cuộc tấn công XSSI và XSRF. Xem 6.1. để biết chi tiết.
APImô tả về các APIDanh sách API được hỗ trợ (như mô tả bên dưới)
trạng thái ngữ nghĩaJSON(không bắt buộc) Trạng thái ngữ nghĩa của thiết bị ở định dạng CloudDeviceState.

api – là danh sách JSON chứa danh sách API có sẵn qua mạng cục bộ. Lưu ý rằng không phải API nào cũng dùng được cùng một lúc trên mạng cục bộ. Ví dụ: một thiết bị mới kết nối chỉ nên hỗ trợ API /register:

"api": [
        "/privet/register",
]
Sau khi đăng ký thiết bị, thiết bị PHẢI ngừng hỗ trợ API /register. Thiết bị cũng nên kiểm tra với dịch vụ để cung cấp các API có thể được hiển thị qua mạng cục bộ. Ví dụ:
"api": [
        "/privet/accesstoken",
        "/privet/capabilities",
        "/privet/printer/submitdoc",
]

Hiện tại, bạn có thể sử dụng các API sau:

  • /privet/register – API để đăng ký thiết bị qua mạng cục bộ. (hãy xem /privet/register API để biết chi tiết). API PHẢI PHẢI ẩn sau khi thiết bị được đăng ký thành công trên đám mây.
  • /privet/accesstoken – API để yêu cầu mã thông báo truy cập từ thiết bị (xem /privet/accesstoken API để biết thông tin chi tiết).
  • /privet/capabilities – API để truy xuất các tính năng của thiết bị (xem API /privet/chức năng để biết thông tin chi tiết).
  • /privet/printer/* - API dành riêng cho loại thiết bị "printer", xem các API dành riêng cho máy in để biết chi tiết.
Dưới đây là ví dụ về phản hồi trong /privet/info. (Xin lưu ý rằng việc thiếu /privet/register API, vì đây là thiết bị đã đăng ký):
{
        "version": "1.0",
        "name": "Gene’s printer",
        "description": "Printer connected through Chrome connector",
        "url": "https://www.google.com/cloudprint",
        "type": [
                "printer"
        ],
        "id": "11111111-2222-3333-4444-555555555555",
        "device_state": "idle",
        "connection_state": "online",
        "manufacturer": "Google",
        "model": "Google Chrome",
        "serial_number": "1111-22222-33333-4444",
        "firmware": "24.0.1312.52",
        "uptime": 600,
        "setup_url": "http://support.google.com/cloudprint/answer/1686197/?hl=en",
        "support_url": "http://support.google.com/cloudprint/?hl=en",
        "update_url": "http://support.google.com/cloudprint/?hl=en",
        "x-privet-token": "AIp06DjQd80yMoGYuGmT_VDAApuBZbInsQ:1358377509659",
        "api": [
                "/privet/accesstoken",
                "/privet/capabilities",
                "/privet/printer/submitdoc",
        ]
}
Dưới đây là ví dụ về phản hồi /privet/info cho một máy in hết pin (thông báo trường semantic_state):
{
        "version": "1.0",
        "name": "Gene’s printer",
        "description": "Printer connected through Chrome connector",
        "url": "https://www.google.com/cloudprint",
        "type": [
                "printer"
        ],
        "id": "11111111-2222-3333-4444-555555555555",
        "device_state": "stopped",
        "connection_state": "online",
        "manufacturer": "Google",
        "model": "Google Chrome",
        "serial_number": "1111-22222-33333-4444",
        "firmware": "24.0.1312.52",
        "uptime": 600,
        "setup_url": "http://support.google.com/cloudprint/answer/1686197/?hl=en",
        "support_url": "http://support.google.com/cloudprint/?hl=en",
        "update_url": "http://support.google.com/cloudprint/?hl=en",
        "x-privet-token": "AIp06DjQd80yMoGYuGmT_VDAApuBZbInsQ:1358377509659",
        "api": [
                "/privet/accesstoken",
                "/privet/capabilities",
                "/privet/printer/submitdoc",
        ],
        "semantic_state": {
                "version": "1.0",
                "printer": {
                        "state": "STOPPED",
                        "marker_state": {
                                "item": [
                                        {
                                                "vendor_id": "ink",
                                                "state": "EXHAUSTED",
                                                "level_percent": 0
                                        }
                                ]
                        }
                }
        }
}

4.2.3. Lỗi

/privet/info API CHỈ trả về lỗi nếu thiếu tiêu đề X-Privet-Token. Đó PHẢI PHẢI là lỗi HTTP 400:

HTTP/1.1 400 Missing X-Privet-Token header.

4.3. /privet/register API

/privet/register API là OPTIONAL. Đây là yêu cầu POST qua HTTP. /privet/register API PHẢI kiểm tra để có tiêu đề X-Privet-Token hợp lệ. Thiết bị PHẢI triển khai API này trên "/privet/register" url:

POST /privet/register?action=start&user=user@domain.com HTTP/1.1
POST /privet/register?action=complete&user=user@domain.com HTTP/1.1

Thiết bị sẽ chỉ hiển thị /privet/register API khi thiết bị cho phép đăng ký ẩn danh. Ví dụ:

  • Khi thiết bị đang bật (hoặc sau khi nhấp vào một nút đặc biệt trên thiết bị) và chưa được đăng ký, thiết bị sẽ hiển thị API /privet/register để cho phép người dùng từ mạng cục bộ xác nhận quyền sở hữu máy in.
  • Sau khi đăng ký xong, thiết bị sẽ ngừng hiển thị API /privet/register để ngăn người dùng khác trên mạng cục bộ xác nhận lại quyền sở hữu thiết bị.
  • Một số thiết bị có thể có các cách đăng ký thiết bị khác nhau và hoàn toàn không hiển thị API /privet/register (ví dụ: trình kết nối Chrome Cloud Print).

Quá trình đăng ký bao gồm 3 bước (xem ẩn danh cho Cloud Print).

  1. Bắt đầu quy trình đăng ký ẩn danh.
  2. Máy khách sẽ bắt đầu quá trình này bằng cách gọi API /privet/register. Thiết bị có thể đợi xác nhận người dùng tại thời điểm đó.
  3. Nhận mã thông báo xác nhận quyền sở hữu.

Các cuộc thăm dò ý kiến khách hàng để biết thời điểm thiết bị sẵn sàng tiếp tục. Khi đã sẵn sàng, thiết bị sẽ gửi yêu cầu đến máy chủ để truy xuất mã thông báo đăng ký và URL đăng ký. Đã nhận được mã thông báo và URL PHẢI được trả về ứng dụng khách. Trong bước này, nếu thiết bị nhận được một lệnh gọi khác để bắt đầu quá trình đăng ký, thiết bị phải:

  • Nếu cùng một người dùng đã bắt đầu quy trình đăng ký, hãy loại bỏ tất cả dữ liệu trước đó (nếu có) và bắt đầu quy trình đăng ký mới.
  • Nếu đây là người dùng khác, hãy trả về lỗi device_bận và thời gian chờ 30 giây.

Hoàn tất quy trình đăng ký.

Sau khi xác nhận quyền sở hữu thiết bị, khách hàng phải thông báo cho thiết bị để hoàn tất quá trình đăng ký. Sau khi quá trình đăng ký hoàn tất, thiết bị sẽ gửi thông báo cập nhật, bao gồm cả mã thiết bị mới thu được.

Lưu ý: Khi thiết bị đang xử lý một lệnh gọi API /privet/register, thì không thể xử lý đồng thời các lệnh gọi API /privet/register khác. Thiết bị PHẢI trả về lỗi device_bận và thời gian chờ 30 giây.

Người dùng rất nên xác nhận việc đăng ký trên thiết bị. Nếu được triển khai, thiết bị PHẢI đợi người dùng xác nhận SAU KHI nhận được lệnh gọi /privet/register?action=start API. Khách hàng sẽ gọi /privet/register?action=getClaimToken API để tìm hiểu khi quá trình xác nhận người dùng hoàn tất và có mã thông báo xác nhận quyền sở hữu. Nếu người dùng huỷ đăng ký trên thiết bị (ví dụ: nhấn nút Hủy), thì PHẢI trả về lỗi user_cancel. Nếu người dùng chưa xác nhận đăng ký trong một khoảng thời gian nhất định, thì PHẢI trả về lỗi Confirmation_timeout. Hãy xem phần mặc định để biết thêm chi tiết.

4.3.1. Đầu vào

/privet/register API có các thông số đầu vào sau:
TênGiá trị
hành độngCó thể làm một trong những việc sau:
start (bắt đầu) – để bắt đầu quy trình đăng ký
getClaimToken – truy xuất mã thông báo xác nhận quyền sở hữu trên thiết bị
cancel – để huỷ quy trình đăng ký
complete - để hoàn tất quá trình đăng ký
người dùngEmail của người dùng sẽ xác nhận quyền sở hữu thiết bị này.

Thiết bị PHẢI kiểm tra để đảm bảo địa chỉ email trong tất cả các hành động (bắt đầu, getclaimToken, hủy, hoàn tất) khớp.

4.3.2. Hai chiều

/privet/register API trả về dữ liệu sau:
Tên giá trịLoại giá trịMô tả
hành độngstringHành động tương tự như trong thông số đầu vào.
người dùngchuỗi (không bắt buộc)Cùng một người dùng như trong tham số đầu vào (có thể bị thiếu nếu bị bỏ qua trong đầu vào).
mã thông báochuỗi (không bắt buộc)Mã thông báo đăng ký (bắt buộc đối với "getClaimToken" phản hồi, được bỏ qua đối với "start", "complete", "cancel").
khiếu nại_urlchuỗi (không bắt buộc)URL đăng ký (bắt buộc đối với "getClaimToken" phản hồi, được bỏ qua đối với "start", "complete", "cancel"). Đối với Máy in trên đám mây, tên này phải là "complete_Invitation_url" nhận được từ máy chủ.
Các_url_xác_nhận_tự_độngchuỗi (không bắt buộc)URL đăng ký (bắt buộc đối với "getClaimToken" phản hồi, được bỏ qua đối với "start", "complete", "cancel"). Đối với Máy in trên đám mây, tên này phải là "automatic_Invitation_url" nhận được từ máy chủ.
mã_thiết_bịchuỗi (không bắt buộc)Mã thiết bị mới (bỏ qua cho "start" phản hồi, bắt buộc đối với "complete"

Sau khi đăng ký, thiết bị PHẢI trả về mã thiết bị trong phản hồi API /privet/info.

Ví dụ 1:

{
        "action": "start",
        "user": "user@domain.com",
}

Ví dụ 2:

{
        "action": "getClaimToken",
        "user": "user@domain.com",
        "token": "AAA111222333444555666777",
        "claim_url": "https://domain.com/SoMeUrL",
}

Ví dụ 3:

{
        "action": "complete",
        "user": "user@domain.com",
        "device_id": "11111111-2222-3333-4444-555555555555",
}

4.3.3. Lỗi

/privet/register API có thể trả về các lỗi sau (xem phần Lỗi để biết chi tiết):
LỗiMô tả
device_bậnThiết bị đang bận và không thể thực hiện hành động đã yêu cầu. Hãy thử lại sau khi hết thời gian chờ.
đang_hoạt_động_của_người_dùngĐể phản hồi yêu cầu "getClaimToken" lỗi này cho biết rằng thiết bị vẫn đang chờ người dùng xác nhận và "getclaimToken" yêu cầu sẽ được thử lại sau khi hết thời gian chờ.
huỷ_người_dùngNgười dùng đã hủy quy trình đăng ký khỏi thiết bị một cách rõ ràng.
Confirmation_timeoutHết thời gian chờ xác nhận của người dùng.
hành động_không hợp lệHành động không hợp lệ được gọi. Ví dụ: nếu ứng dụng được gọi là action=complete trước khi gọi action=start và action=getClaimToken.
valid_params (thông số không hợp lệ)Tham số không hợp lệ được chỉ định trong yêu cầu. (Bạn nên bỏ qua những tham số không xác định một cách an toàn để đảm bảo khả năng tương thích trong tương lai. Ví dụ: trả về kết quả này nếu ứng dụng gọi là action=unknown hoặc user=.
lỗi_cấu_hình_thiết_bịNgày/giờ (hoặc một số chế độ cài đặt khác) bị sai ở phía thiết bị. Người dùng cần truy cập (vào trang web nội bộ của thiết bị) và định cấu hình các chế độ cài đặt của thiết bị.
ngoại tuyếnThiết bị này hiện không kết nối mạng và không thể giao tiếp với máy chủ.
lỗi_máy_chủLỗi máy chủ trong quá trình đăng ký.
valid_x_privet_tokenX-Privet-Token không hợp lệ hoặc bị trống trong yêu cầu.

Thiết bị PHẢI ngừng hiển thị API /privet/register sau khi đăng ký thành công. Nếu thiết bị không cho thấy API /privet/register, thiết bị PHẢI trả về lỗi HTTP 404. Do đó, nếu một thiết bị đã được đăng ký, hãy gọi API này PHẢI trả về mã 404. Nếu thiếu tiêu đề X-Privet-Token, thiết bị PHẢI trả về lỗi HTTP 400.

4.4. API /privet/accesstoken

/privet/accesstoken API là KHÔNG BẮT BUỘC. Đây là yêu cầu GET HTTP. /privet/accesstoken API PHẢI kiểm tra cho tiêu đề "X-Privet-Token" hợp lệ. Thiết bị PHẢI triển khai API này trên &"/privet/accesstoken" url:
GET /privet/accesstoken HTTP/1.1

Khi nhận được lệnh gọi API /accesstoken, thiết bị phải gọi máy chủ để truy xuất mã truy cập của người dùng đã cho và trả lại mã thông báo cho ứng dụng. Sau đó, ứng dụng đó sẽ dùng mã truy cập để truy cập vào thiết bị này qua đám mây.

Thiết bị Cloud Print PHẢI gọi API sau:

/cloudprint/proximitytoken
và chuyển "printerid='lt;printer_id>" và "user" thông số từ API địa phương. Nếu thành công, phản hồi của máy chủ sẽ chứa đối tượng sau:
"proximity_token": {
        "user": "user@domain.com",
        "token": "AAA111222333444555666777",
        "expires_in": 600
}
Thiết bị Cloud Print PHẢI chuyển giá trị của đối tượng "proximity_token" trong phản hồi đến các lệnh gọi API cục bộ /privet/accesstoken. Sẽ thuận lợi hơn (trong tương lai) nếu thiết bị có thể vượt qua TẤT CẢ thông số (bao gồm cả những thông số không được mô tả trong thông số kỹ thuật này).

4.4.1. Đầu vào

API /privet/accesstoken có các thông số đầu vào sau:
TênGiá trị
người dùngEmail của người dùng có ý định sử dụng mã truy cập này. Có thể để trống trong yêu cầu.

4.4.2. Hai chiều

/privet/accesstoken API trả về dữ liệu sau:
Tên giá trịLoại giá trịMô tả
mã thông báostringMã truy cập mà máy chủ trả về
người dùngstringCùng một người dùng như trong thông số đầu vào.
expiration_in .intSố giây cho đến khi mã thông báo này hết hạn. Nhận từ máy chủ và chuyển vào phản hồi này.

Ví dụ:

{
        "token": "AAA111222333444555666777",
        "user": "user@domain.com",
        "expires_in": 600
}

4.4.3. Lỗi

/privet/accesstoken API có thể trả về các lỗi sau (xem phần Lỗi để biết chi tiết):
LỗiMô tả
ngoại tuyếnThiết bị hiện không kết nối mạng và không thể giao tiếp với máy chủ.
quyền_truy_cậpKhông đủ quyền. Truy cập bị từ chối. Thiết bị sẽ trả về lỗi này khi máy chủ đã từ chối yêu cầu một cách rõ ràng.
valid_params (thông số không hợp lệ)Tham số không hợp lệ được chỉ định trong yêu cầu. (Bạn nên bỏ qua những tham số không xác định một cách an toàn để đảm bảo khả năng tương thích trong tương lai. Ví dụ: nếu ứng dụng khách có tên là /accesstoken?user= hoặc /accesstoken.
lỗi_máy_chủLỗi máy chủ.
valid_x_privet_tokenX-Privet-Token không hợp lệ hoặc bị trống trong yêu cầu.

Nếu thiết bị không cho thấy API /privet/accesstoken thì thiết bị PHẢI trả về lỗi HTTP 404. Nếu thiếu tiêu đề X-Privet-Token, thiết bị PHẢI trả về lỗi HTTP 400.

4.5. API /privet/chức năng

/privet/capabilities API là KHÔNG BẮT BUỘC. Đây là yêu cầu GET HTTP. /privet/capabilities API PHẢI kiểm tra để có tiêu đề "X-Privet-Token" hợp lệ. Thiết bị PHẢI triển khai API này trên &"/privet/capabilities" url:
GET /privet/capabilities HTTP/1.1
Khi thiết bị nhận /capabilities API lệnh gọi, nếu thiết bị có thể, thiết bị PHẢI liên hệ với máy chủ để nhận khả năng được cập nhật. Ví dụ: nếu máy in hỗ trợ đăng một lệnh in (nhận tại máy tính) thông qua dịch vụ Cloud Print, thì máy in sẽ trả về các tính năng mà dịch vụ Cloud Print trả về. Trong trường hợp này, Cloud Print có thể thay đổi tính năng ban đầu cho máy in bằng cách thêm các tính năng mới mà chức năng này có thể thực hiện trước khi gửi lệnh in đến máy in. Trường hợp phổ biến nhất là danh sách các loại tài liệu được hỗ trợ. Nếu không có kết nối mạng, máy in sẽ trả về các loại tài liệu mà máy in hỗ trợ. Tuy nhiên, nếu máy in trực tuyến và được đăng ký với Cloud Print, thì MUST trả về "*/*" là một trong các loại được hỗ trợ. Dịch vụ Cloud Print sẽ thực hiện lượt chuyển đổi cần thiết trong trường hợp này. Để in ngoại tuyến, máy in PHẢI hỗ trợ định dạng ít nhất là "image/pwg-raster"

4.5.1. Đầu vào

API /privet/capabilities có các thông số đầu vào sau:
TênGiá trị
ngoại tuyến(không bắt buộc) Chỉ có thể là "ngoại tuyến=1" Trong trường hợp này, thiết bị phải trả về các tính năng sử dụng ngoại tuyến (nếu các tính năng đó khác với "online" chức năng).

4.5.2. Hai chiều

/privet/capabilities API trả về các tính năng của thiết bị ở định dạng JSON Mô tả thiết bị trên đám mây (CDD) (xem tài liệu CDD để biết chi tiết). Máy in ở mức tối thiểu PHẢI trả về danh sách các loại được hỗ trợ tại đây. Ví dụ: một máy in có tính năng CloudReady đang hoạt động có thể trả về một giá trị như vậy (tối thiểu)
{
        "version": "1.0",
        "printer": {
                "supported_content_type": [
                        {
                                "content_type": "application/pdf",
                                "min_version": "1.4"
                        },
                        { "content_type": "image/pwg-raster" },
                        { "content_type": "image/jpeg" },
                        { "content_type": "*/*" }
                ]
        }
}
và khi bị ngắt kết nối khỏi máy chủ, máy in có thể trả về:
{
        "version": "1.0",
        "printer": {
                "supported_content_type": [
                        {
                                "content_type": "application/pdf",
                                "min_version": "1.4"
                        },
                        { "content_type": "image/pwg-raster" },
                        { "content_type": "image/jpeg" }
                ]
        }
}

Lưu ý: Máy in thể hiện mức độ ưu tiên loại nội dung được hỗ trợ bằng thứ tự. Ví dụ: trong các mẫu ở trên, máy in chỉ định rằng nó ưu tiên "application/pdf" dữ liệu qua "image/pwg-raster" và "image/jpeg" Ứng dụng phải tuân thủ mức độ ưu tiên của máy in nếu có thể (xem tài liệu CDD để biết thông tin chi tiết).

4.5.3. Lỗi

/privet/capabilities API có thể trả về các lỗi sau (xem phần Lỗi để biết chi tiết):
LỗiMô tả
valid_x_privet_tokenX-Privet-Token không hợp lệ hoặc bị trống trong yêu cầu.

Nếu thiết bị không cho thấy API /privet/capabilities, thì thiết bị PHẢI trả về lỗi HTTP 404. Nếu tiêu đề X-Privet-Token bị thiếu, thiết bị PHẢI trả về lỗi HTTP 400.

4.6. Lỗi

Lỗi được trả về từ các API ở trên theo định dạng sau:
Tên giá trịLoại giá trịMô tả
errorstringLoại lỗi (được xác định cho mỗi API)
nội dung mô tảchuỗi (không bắt buộc)Nội dung mô tả lỗi có thể đọc được.
máy chủ_apichuỗi (không bắt buộc)Trong trường hợp xảy ra lỗi máy chủ, trường này chứa API máy chủ không thực hiện được.
máy chủ_mãint (không bắt buộc)Trong trường hợp xảy ra lỗi máy chủ, trường này chứa mã lỗi mà máy chủ trả về.
máy chủ_http_mãint (không bắt buộc)Trong trường hợp lỗi HTTP của máy chủ, trường này chứa máy chủ mã lỗi HTTP được trả về.
thời gian chờint (không bắt buộc)Số giây để khách hàng đợi trước khi thử lại (chỉ dành cho các lỗi có thể khôi phục). Ứng dụng khách PHẢI sắp xếp thời gian chờ thực tế từ giá trị này đến giá trị + 20%.

Tất cả các API PHẢI trả về lỗi HTTP 400 nếu thiếu tiêu đề X-Privet-Token.

HTTP/1.1 400 Thiếu tiêu đề X-Privet-Token.

Ví dụ 1:

{
        "error": "server_error",
        "description": "Service unavailable",
        "server_api": "/submit",
        "server_http_code": 503
}

Ví dụ 2:

{
        "error": "printer_busy",
        "description": "Printer is currently printing other job",
        "timeout": 15
}

5. API Máy in

Một trong những loại thiết bị mà giao thức này hỗ trợ là loại máy in. Các thiết bị hỗ trợ loại này CÓ THỂ triển khai một số chức năng dành riêng cho máy in. Lý tưởng nhất là việc in bằng máy in kết nối đám mây sẽ qua máy chủ Cloud Print:

Trong một số trường hợp, khách hàng có thể cần phải gửi tài liệu trên máy. Có thể cần thiết khi máy khách không có mã Google hoặc không thể giao tiếp với máy chủ Cloud Print. Trong trường hợp đó, lệnh in sẽ được gửi cục bộ đến máy in. Máy in sẽ sử dụng dịch vụ Cloud Print để xếp hàng và chuyển đổi lệnh in. Máy in sẽ đăng lại lệnh in đã gửi cục bộ lên dịch vụ Cloud Print rồi yêu cầu lệnh in vì lệnh đã được gửi qua đám mây. Quá trình này sẽ mang lại trải nghiệm người dùng linh hoạt về dịch vụ (chuyển đổi) cũng như tính năng quản lý/theo dõi lệnh in.

Vì dịch vụ Cloud Print triển khai tính năng chuyển đổi, nên máy in PHẢI quảng cáo hỗ trợ tất cả định dạng đầu vào ("*/*") trong danh sách các loại nội dung được hỗ trợ:

{
        "version": "1.0",
        "printer": {
                "supported_content_type": [
                        { "content_type": "image/pwg-raster" },
                        { "content_type": "*/*" }
                ]
        }
}

Trong một số trường hợp, bạn muốn có giải pháp hoàn toàn ngoại tuyến. Vì máy in hỗ trợ một số lượng định dạng đầu vào có giới hạn nên khách hàng sẽ cần chuyển đổi tài liệu sang một vài định dạng máy in được hỗ trợ gốc.

Thông số này yêu cầu tất cả máy in phải hỗ trợ định dạng PWG Raster ("image/pwg-raster") ít nhất cho trường hợp in ngoại tuyến. Một máy in có thể hỗ trợ các định dạng khác (ví dụ: JPEG) và nếu một ứng dụng khách hỗ trợ định dạng đó, thì máy in có thể gửi các tài liệu ở định dạng đó. Máy in PHẢI hiển thị các loại được hỗ trợ thông qua API /capabilities, ví dụ:

{
        "version": "1.0",
        "printer": {
                "supported_content_type": [
                        { "content_type": "image/pwg-raster" },
                        { "content_type": "image/jpeg" }
                ]
        }
}
Có hai cách mà khách hàng có thể bắt đầu in qua mạng cục bộ.

In đơn giản – ứng dụng gửi tài liệu qua mạng cục bộ đến API /submitdoc (mà không cần chỉ định thông số Job_id). Tài liệu đã gửi sẽ được in bằng chế độ cài đặt vé in mặc định và bạn không cần trạng thái lệnh in. Nếu máy in CHỈ hỗ trợ loại in này, thì PHẢI quảng cáo CHỈ API /submitdoc trong phản hồi API /privet/info.

"api": [
        "/privet/accesstoken",
        "/privet/capabilities",
        "/privet/printer/submitdoc",
]

In nâng cao – trước tiên, máy khách nên tạo một lệnh in trên máy in bằng cách gọi API /privet/printer/createjob với vé in CJT hợp lệ trong yêu cầu. Máy in PHẢI PHẢI lưu trữ vé in trong bộ nhớ và trả về một Job_id cho máy khách. Sau đó, ứng dụng sẽ gọi API /printer/submitdoc và chỉ định job_id đã nhận trước đó. Khi đó, máy in sẽ bắt đầu in. Máy khách sẽ thăm dò trạng thái lệnh in của máy in bằng cách gọi API /privet/printer/jobstate.

Trong môi trường nhiều khách hàng, không có gì đảm bảo cách API này được gọi. Một khách hàng có thể gọi /createjob giữa các lệnh gọi /createjob->/submitdoc của ứng dụng khác. Để loại bỏ các tình huống tắc nghẽn có thể xảy ra và cải thiện khả năng sử dụng, bạn nên có một hàng đợi nhỏ về các lệnh in đang chờ xử lý trên máy in (ít nhất 3 đến 5):

  • /createjob chiếm vị trí đầu tiên trong hàng đợi.
  • Thời gian làm việc (trong hàng đợi) ít nhất là 5 phút.
  • Nếu tất cả các vị trí trong hàng đợi được chọn, thì lệnh in cũ nhất, không in được sẽ bị xóa và một lệnh mới sẽ được đặt ở đó.
  • Nếu một lệnh in hiện đang in trên thiết bị (in đơn giản hoặc nâng cao), /submitdoc sẽ trả về trạng thái bận và đề xuất thời gian chờ để thử lại lệnh in này.
  • Nếu /submitdoc đề cập đến một công việc đã bị xóa khỏi hàng đợi (do thay thế hoặc hết thời gian chờ), thì máy in sẽ trả về lỗi invalid_print_job và ứng dụng sẽ thử lại quy trình này từ bước /createjob. Ứng dụng khách PHẢI đợi trong khoảng thời gian chờ ngẫu nhiên tối đa 5 giây trước khi thử lại.

Nếu các hạn chế về bộ nhớ ngăn chặn việc lưu trữ nhiều lệnh đang chờ xử lý trên thiết bị, thì bạn có thể tạo một hàng đợi gồm 1 lệnh in dài. Chương trình thử nghiệm vẫn phải tuân theo cùng một giao thức như trên. Sau khi lệnh in hoàn tất hoặc không thành công kèm theo lỗi, máy in sẽ lưu trữ thông tin về trạng thái của lệnh đó trong ít nhất 5 phút. Kích thước hàng đợi để lưu trữ trạng thái công việc đã hoàn thành tối thiểu là 10. Nếu cần lưu trữ thêm trạng thái công việc, chúng tôi có thể xoá trạng thái công việc cũ nhất khỏi hàng đợi trước khi hết 5 phút.

Lưu ý: Hiện tại, khách hàng sẽ thăm dò ý kiến về trạng thái công việc. Trong tương lai, chúng tôi có thể yêu cầu máy in gửi thông báo TXT DNS khi BẤT KỲ trạng thái lệnh in nào thay đổi.

5.1. API /privet/printer/createjob

/privet/printer/createjob API là KHÔNG BẮT BUỘC (xem In đơn giản ở trên). Đây là yêu cầu HTTP POST. /privet/printer/createjob API PHẢI kiểm tra tiêu đề "X-Privet-Token" hợp lệ. Thiết bị PHẢI triển khai API này trên "/privet/printer/createjob" url:

POST /privet/printer/createjob HTTP/1.1
Khi nhận được lệnh gọi API /privet/printer/createjob, máy in PHẢI tạo một mã lệnh in mới, lưu trữ vé đã nhận ở định dạng CJT và trả lại mã lệnh in

5.1.1. Đầu vào

/privet/printer/createjob API không có thông số đầu vào trong URL. Phần nội dung yêu cầu phải chứa dữ liệu về vé lệnh in ở định dạng CJT.

5.1.2. Hai chiều

/privet/printer/createjob API trả về dữ liệu sau:
Tên giá trịLoại giá trịMô tả
Job_id (Mã công việc)stringMã của lệnh in mới tạo.
expiration_in .intSố giây của lệnh in này là hợp lệ.

Ví dụ:

{
        "job_id": "123",
        "expires_in": 600
}

5.1.3. Lỗi

/privet/printer/createjob API có thể trả về các lỗi sau (xem phần Lỗi để biết chi tiết):
LỗiMô tả
vé_không hợp lệVé in đã gửi không hợp lệ.
máy in_bậnMáy in đang bận và hiện không thể xử lý /createjob. Hãy thử lại sau khi hết thời gian chờ.
lỗi_máy_inMáy in đang ở trạng thái lỗi và cần người dùng tương tác để khắc phục. Nội dung mô tả phải có nội dung giải thích chi tiết hơn (ví dụ: "Kệm giấy trong Khay 1").
valid_x_privet_tokenX-Privet-Token không hợp lệ hoặc bị trống trong yêu cầu.

Nếu thiết bị không hiển thị /privet/printer/createjob, thì thiết bị PHẢI trả về lỗi HTTP 404. Nếu thiếu tiêu đề X-Privet-Token, thiết bị PHẢI trả về lỗi HTTP 400.

5.2. API /privet/printer/submitdoc

Cần có /privet/printer/submitdoc API để triển khai in qua mạng cục bộ (ngoại tuyến hoặc đăng lại lên Cloud Print). Đây là yêu cầu POST qua HTTP. /privet/printer/submitdoc API PHẢI kiểm tra tiêu đề "X-Privet-Token" hợp lệ. Thiết bị PHẢI triển khai API này trên &"/privet/printer/submitdoc" url:
POST /privet/printer/submitdoc HTTP/1.1
Khi nhận được lệnh gọi API /privet/printer/submitdoc, máy in sẽ bắt đầu in. Nếu không thể bắt đầu in, thì bạn PHẢI trả về lỗi print_bận và khoảng thời gian chờ đề xuất để ứng dụng chờ trước khi thử lại.

Nếu không thể giữ tất cả dữ liệu trong vùng đệm nội bộ, thì máy in PHẢI sử dụng cơ chế TCP để giảm tốc độ truyền dữ liệu cho đến khi in được một phần tài liệu, khiến một phần của vùng đệm khả dụng trở lại. (Ví dụ: máy in có thể đặt windowsize=0 trên các lớp TCP. Điều này sẽ khiến ứng dụng khách chờ đợi.)

Việc gửi tài liệu đến máy in có thể mất nhiều thời gian. Ứng dụng cần có thể kiểm tra trạng thái của máy in và lệnh in (in nâng cao) trong khi đang in. Để làm được việc đó, máy in PHẢI cho phép ứng dụng gọi /privet/info và /privet/printer/jobstate API trong khi xử lý các lệnh gọi API /privet/printer/submitdoc. Tất cả khách hàng nên bắt đầu một luồng mới để thực thi lệnh gọi API /privet/printer/submitdoc. Như vậy, luồng chính có thể sử dụng các API /privet/info và /privet/printer/jobstate để kiểm tra máy in và trạng thái công việc.

Lưu ý: Sau khi hoàn thành hoặc hủy bỏ lệnh in tại địa phương, bạn nên (và sẽ yêu cầu trong phiên bản tương lai của thông số này) để báo cáo trạng thái cuối cùng của việc làm cho giao diện /tCPA/submit cho mục đích kế toán và trải nghiệm người dùng. Các thông số "printerid", "title", "contentType" và "final_semantic_state" (ở định dạng PrintJobState) là & các thông số "tag" (thông số lặp lại) và "vé" (vé của Cloudquỹ) Xin lưu ý rằng PrintJobState mà bạn cung cấp phải thực sự là loại cuối cùng, tức là loại đó phải là XONG hoặc ĐÃ ABOR. Bạn phải cung cấp nguyên nhân trong trường hợp đó là ABORTED (xem JobState để biết thông tin chi tiết). Ngoài ra, xin lưu ý rằng việc sử dụng giao diện /ROUND/submit để báo cáo các lệnh in cục bộ không được đề cập trong quy cách của phần tử đó vì phần đó nhằm mô tả cách sử dụng chính của giao diện: gửi lệnh in kèm theo tài liệu để in bằng tham số "content"

5.2.1. Đầu vào

API /privet/printer/submitdoc có các thông số đầu vào sau:
TênGiá trị
Job_id (Mã công việc)(không bắt buộc) Mã lệnh in. Có thể bị bỏ qua đối với trường hợp in đơn giản (xem ở trên). Phải khớp với kết quả mà máy in trả về.
Tên_người_dùng(không bắt buộc) Tên người dùng có thể đọc được. Đây không phải là quyết định chắc chắn và chỉ nên dùng cho chú thích lệnh in. Nếu lệnh in được đăng lại lên dịch vụ Cloud Print, chuỗi này phải được đính kèm vào lệnh in trên Cloud Print.
client_name [tên_khách_hàng](không bắt buộc) Tên của ứng dụng khách thực hiện yêu cầu này. Chỉ dành cho mục đích hiển thị. Nếu lệnh in được đăng lại lên dịch vụ Cloud Print, chuỗi này phải được đính kèm với lệnh in trên Cloud Print.
Job_name [tên_công_việc](không bắt buộc) Tên của lệnh in cần ghi. Nếu lệnh in được đăng lại cho dịch vụ Cloud Print, chuỗi này phải được đính kèm vào lệnh in trên Cloud Print.
ngoại tuyến(không bắt buộc) Chỉ có thể là "ngoại tuyến=1" Trong trường hợp này, máy in sẽ chỉ thử in khi không có mạng (không đăng lại lên máy chủ Cloud Print).

Phần nội dung yêu cầu phải chứa tài liệu hợp lệ để in. "Content-Length" phải bao gồm độ dài chính xác của yêu cầu. "Content-Type" tiêu đề phải được đặt thành loại MIME tài liệu và khớp với một trong các loại trong CDD (trừ khi CDD chỉ định "*/*"

Bạn nên cung cấp cho khách hàng một tên người dùng (hoặc email) hợp lệ, tên khách hàng và tên công việc cùng với yêu cầu này. Các trường đó chỉ được dùng trong giao diện người dùng để cải thiện trải nghiệm người dùng.

5.2.2. Hai chiều

/privet/printer/submitdoc API trả về dữ liệu sau:
Tên giá trịLoại giá trịMô tả
Job_id (Mã công việc)stringMã của lệnh in mới tạo (bản in đơn giản) hoặc Job_id được chỉ định trong yêu cầu (in nâng cao).
expiration_in .intSố giây của lệnh in này là hợp lệ.
Job_typestringLoại nội dung của tài liệu đã gửi.
kích thước công việcint 64 bitKích thước của dữ liệu in tính bằng byte.
Job_name [tên_công_việc]string(không bắt buộc) Tên công việc giống như khi nhập (nếu có).

Ví dụ:

{
        "job_id": "123",
        "expires_in": 500,
        "job_type": "application/pdf",
        "job_size": 123456,
        "job_name": "My PDF document"
}

5.2.3. Lỗi

/privet/printer/submitdoc API có thể trả về các lỗi sau (xem phần Lỗi để biết thêm chi tiết):
LỗiMô tả
giá_trị_hàng_không hợp lệMã công việc không hợp lệ/đã hết hạn được chỉ định trong yêu cầu. Hãy thử lại sau khi hết thời gian chờ.
type_document_typeLoại máy in không hỗ trợ loại MIME tài liệu.
tài_khoản_không_hợp_lệGiấy tờ đã gửi không hợp lệ.
document_too_largeTài liệu vượt quá kích thước tối đa cho phép.
máy in_bậnMáy in đang bận và không thể xử lý tài liệu. Hãy thử lại sau khi hết thời gian chờ.
lỗi_máy_inMáy in đang ở trạng thái lỗi và cần người dùng tương tác để khắc phục. Nội dung mô tả phải có nội dung giải thích chi tiết hơn (ví dụ: "Kệm giấy trong Khay 1").
valid_params (thông số không hợp lệ)Tham số không hợp lệ được chỉ định trong yêu cầu. (Bạn nên bỏ qua những tham số không xác định một cách an toàn để đảm bảo khả năng tương thích trong tương lai.)
huỷ_người_dùngNgười dùng đã hủy quy trình in một cách rõ ràng khỏi thiết bị.
lỗi_máy_chủKhông đăng được tài liệu lên Cloud Print.
valid_x_privet_tokenX-Privet-Token không hợp lệ hoặc bị trống trong yêu cầu.

Nếu thiết bị không hiển thị /privet/printer/submitdoc, thì thiết bị PHẢI trả về lỗi HTTP 404. Nếu thiếu tiêu đề X-Privet-Token, thiết bị PHẢI trả về lỗi HTTP 400.

Lưu ý: /privet/printer/submitdoc API có thể yêu cầu xử lý đặc biệt ở phía máy in (do tệp đính kèm lớn có tải trọng lớn). Trong một số trường hợp (phụ thuộc vào cách thức triển khai và nền tảng máy chủ HTTP của máy in), máy in có thể đóng ổ cắm TRƯỚC KHI gặp lỗi HTTP. Ngược lại, máy in có thể trả về lỗi 503 (thay vì lỗi Privet). Máy in PHẢI thử nhiều nhất có thể để trả về Privet. Tuy nhiên, mọi ứng dụng khách triển khai đặc tả Privet PHẢI có thể xử lý cổng đóng (không có lỗi HTTP) và các trường hợp lỗi HTTP 503 đối với API /privet/printer/submitdoc. Trong trường hợp này, ứng dụng khách PHẢI xử lý dưới dạng Privet "printer_bận" lỗi với "timeout" được đặt thành 15 giây. Để tránh các lần thử vô hạn, khách hàng có thể ngừng thử lại sau một số lần thử hợp lý (ví dụ: 3 lần).

5.3. /privet/printer/jobstate API

/privet/printer/jobstate API là KHÔNG BẮT BUỘC (xem In đơn giản ở trên). Đây là yêu cầu GET HTTP. /privet/printer/jobstate API PHẢI kiểm tra một tiêu đề "X-Privet-Token" hợp lệ. Thiết bị PHẢI triển khai API này trên "/privet/printer/jobstate" url:
GET /privet/printer/jobstate HTTP/1.1
Khi nhận được lệnh gọi API /privet/printer/jobstate, một máy in sẽ trả về trạng thái của lệnh in được yêu cầu hoặc valid_print_job.

5.3.1. Đầu vào

/privet/printer/jobstate API có các thông số đầu vào sau:
TênGiá trị
Job_id (Mã công việc)Mã lệnh in để trả về trạng thái.

5.3.2. Hai chiều

/privet/printer/jobstate API trả về dữ liệu sau:
Tên giá trịLoại giá trịMô tả
Job_id (Mã công việc)stringMã lệnh in có thông tin trạng thái.
tiểu bangstring nháp - lệnh in đã được tạo trên thiết bị (chưa nhận được /privet/printer/submitdoc cuộc gọi).
đã đưa vào hàng đợi – lệnh in đã được nhận và đang xếp hàng, nhưng quá trình in chưa bắt đầu.
in_progress - đang in đang trong quá trình in.
đã dừng – lệnh in đã bị tạm dừng nhưng có thể được khởi động lại theo cách thủ công hoặc tự động.
Xong – lệnh in đã hoàn tất.
đã hủy – lệnh in không thành công.
nội dung mô tảstring(không bắt buộc) Thông tin mô tả mà người dùng có thể đọc về trạng thái lệnh in. Nên bao gồm thông tin bổ sung nếu trạng thái< dừng hoặc bị hủy. Trường semantic_state thường cung cấp thông tin mô tả tốt hơn và có ý nghĩa hơn cho ứng dụng.
expiration_in .intSố giây của lệnh in này là hợp lệ.
Job_typestring(không bắt buộc) Loại nội dung của tài liệu đã gửi.
kích thước công việcint 64 bit(không bắt buộc) Kích thước của dữ liệu in tính bằng byte.
Job_name [tên_công_việc]string(không bắt buộc) Tên công việc giống như khi nhập (nếu có).
máy chủ_công việc_mãstring(không bắt buộc) Mã của lệnh in trả về từ máy chủ (nếu lệnh đã được đăng lên dịch vụ Cloud Print). Bị bỏ qua khi in ngoại tuyến.
trạng thái ngữ nghĩaJSON(không bắt buộc) Trạng thái ngữ nghĩa của lệnh in ở định dạng PrintJobState.

Ví dụ (in bằng cách báo cáo thông qua Cloud Print):

{
        "job_id": "123",
        "state": "in_progress",
        "expires_in": 100,
        "job_type": "application/pdf",
        "job_size": 123456,
        "job_name": "My PDF document",
        "server_job_id": "1111-2222-3333-4444"
}

Ví dụ (lỗi in ngoại tuyến):

{
        "job_id": "123",
        "state": "stopped",
        "description": "Out of paper",
        "expires_in": 100,
        "job_type": "application/pdf",
        "job_size": 123456,
        "job_name": "My PDF document"
}

Ví dụ (lệnh in bị người dùng hủy):

{
        "job_id": "123",
        "state": "aborted",
        "description": "User action",
        "expires_in": 100,
        "job_type": "application/pdf",
        "job_size": 123456,
        "job_name": "My PDF document",
        "semantic_state": {
                "version": "1.0",
                "state": {
                        "type": "ABORTED",
                        "user_action_cause": {"action_code": "CANCELLED"}
                },
                "pages_printed": 7
        }
}

Ví dụ (công việc in đã ngừng do hết giấy). Hãy lưu ý thông tin tham chiếu đến trạng thái của thiết bị. Ứng dụng khách cần gọi /privet/info API để biết thêm thông tin chi tiết về trạng thái thiết bị:

{
        "job_id": "123",
        "state": "stopped",
        "description": "Out of paper",
        "expires_in": 100,
        "job_type": "application/pdf",
        "job_size": "123456",
        "job_name": "My PDF document",
        "semantic_state": {
                "version": "1.0",
                "state": {
                        "type": "STOPPED",
                        "device_state_cause": {"error_code": "INPUT_TRAY"}
                },
                "pages_printed": 7
        }
}

5.3.3. Lỗi

/privet/printer/jobstate API có thể trả về các lỗi sau (xem phần Lỗi để biết chi tiết):
LỗiMô tả
giá_trị_hàng_không hợp lệMã công việc không hợp lệ/đã hết hạn được chỉ định trong yêu cầu.
lỗi_máy_chủKhông tải được trạng thái lệnh in (đối với lệnh in đăng lên Cloud Print) .
valid_x_privet_tokenX-Privet-Token không hợp lệ hoặc bị trống trong yêu cầu.

Nếu thiết bị không hiển thị /privet/printer/jobstate, thì thiết bị PHẢI trả về lỗi HTTP 404. Nếu thiếu tiêu đề X-Privet-Token, thiết bị PHẢI trả về lỗi HTTP 400.

6. Phụ lục

6.1. Hành vi và chế độ cài đặt mặc định

Phần này sẽ giải thích hành vi mặc định mà chúng tôi kỳ vọng từ TẤT CẢ các thiết bị tương thích với Privet.
  • Thiết bị có sẵn chỉ nên hỗ trợ API /privet/info/privet/register. Tất cả các API khác (ví dụ: /privet/accesstoken, in cục bộ) nên bị tắt.
  • Khi đăng ký, bạn sẽ phải tương tác với thiết bị.
    • Người dùng PHẢI thực hiện thao tác vật lý trên thiết bị (ví dụ: nhấn một nút) để xác nhận quyền truy cập của họ vào thiết bị.
    • Sau khi người dùng thực hiện hành động đã nêu ở trên, máy in sẽ gửi yêu cầu /tCPA/register. Nó sẽ không gửi yêu cầu này cho đến khi hành động được thực hiện (xem Sơ đồ trình tự 1).
    • Nếu thiết bị đang xử lý một yêu cầu /privet/register (ví dụ: đợi hành động ở trên), thì thiết bị phải từ chối tất cả các yêu cầu /privet/register khác. Thiết bị PHẢI trả về lỗi device_bận trong trường hợp này.
    • Thiết bị sẽ hết thời gian chờ mọi yêu cầu /register không nhận được hành động thực tế nêu trên trong vòng 60 giây. Thiết bị PHẢI trả về lỗi Confirmation_timeout trong trường hợp này.
    • Không bắt buộc: Bạn nên sử dụng nhưng không bắt buộc, vì những cách sau có thể cải thiện trải nghiệm người dùng:
      • Máy in có thể nhấp nháy đèn hoặc màn hình để cho biết người dùng cần thực hiện thao tác xác nhận đăng ký.
      • Trên máy in có thể nêu rõ "đang được đăng ký với Google Cloud Print" cho người dùng "abc@def.com" – nhấn OK để tiếp tục", trong đó abc@def.com là thông số người dùng từ lệnh gọi API /register. Điều này sẽ giúp người dùng biết rõ hơn rằng:
        • chính yêu cầu đăng ký của họ là họ xác nhận
        • điều gì sẽ xảy ra nếu người đó không kích hoạt yêu cầu.
      • Cùng với hành động xác nhận từ máy in (ví dụ: "Nhấn nút OK"), máy in cũng có thể cung cấp cho người dùng nút huỷ yêu cầu (ví dụ: "Nhấn nút Hủy để từ chối"). Thao tác này sẽ cho phép những người dùng không kích hoạt yêu cầu đăng ký huỷ trước khi hết thời gian chờ 60 giây. Thiết bị PHẢI trả về lỗi user_cancel trong trường hợp này.
  • Yêu cầu chuyển nhượng quyền sở hữu:
    • Thiết bị có thể bị xóa hoàn toàn khỏi dịch vụ Đám mây.
      • Nếu thiết bị nhận được thành công nhưng không có nội dung mô tả thiết bị do kết quả của lệnh gọi /tCPA/printer (đối với GCP), thì thiết bị đó PHẢI PHẢI chuyển về chế độ mặc định (out-of-the-box).
      • Nếu thông tin đăng nhập của thiết bị không còn hoạt động nữa (tức là do thông tin xác thực "không hợp lệ" phản hồi từ máy chủ), thì PHẢI PHẢI hoàn nguyên về chế độ mặc định (out-of-the-box).
    • Đặt lại về trạng thái ban đầu PHẢI xóa thông tin đăng nhập của thiết bị và đặt ở trạng thái mặc định.
    • Không bắt buộc: Thiết bị có thể cung cấp một mục trong trình đơn để xóa thông tin xác thực và đặt mục đó vào chế độ mặc định.
  • Thiết bị hỗ trợ thông báo DKIM PHẢI có khả năng ping máy chủ. Thời gian chờ ping PHẢI kiểm soát được từ máy chủ thông qua "local_settings"
  • Thiết bị có thể ping một cách rõ ràng (ví dụ: ping/API máy in cho GCP), máy chủ có thể ping một cách rõ ràng không quá ping một lần mỗi ngày (24 giờ) để đảm bảo các quá trình này được đồng bộ hóa. Bạn nên sắp xếp ngẫu nhiên cửa sổ kiểm tra trong khoảng thời gian 24-32 giờ.
  • Không bắt buộc: Đối với các thiết bị Cloud Print, bạn nên nhưng không cần yêu cầu cách thủ công (nút) để cho phép người dùng bắt đầu kiểm tra lệnh in mới từ thiết bị. Một số máy in đã có tính năng này.
  • Không bắt buộc. Máy in dành cho doanh nghiệp có thể tắt hoàn toàn tính năng khám phá trên máy. Trong trường hợp đó, thiết bị PHẢI cập nhật các chế độ cài đặt cục bộ này trên máy chủ. Cài đặt cục bộ mới PHẢI để trống (cài đặt "local_Discovery" thành "false", nghĩa là có thể bật lại chế độ này từ Dịch vụ GCP).

6.1.2 Sơ đồ đăng ký mặc định

6.2. Các cuộc tấn công và ngăn chặn XSSI và XSRF

Phần này sẽ giải thích khả năng XSSI và XSRF bị tấn công trên thiết bị cũng như cách bảo vệ chúng (bao gồm cả các kỹ thuật tạo mã thông báo).
Thông tin chi tiết có tại đây: http://googleonlinesecurity.blogspot.com/2011/05/website-security-for-webmasters.html
Thông thường, bạn có thể gặp phải XSSI và XSRF khi sử dụng cơ chế xác thực cookie. Mặc dù Google không sử dụng cookie với Dịch vụ Cloud Print của mình, nhưng các cuộc tấn công đó vẫn có thể xảy ra. Theo thiết kế, quyền truy cập mạng cục bộ hoàn toàn tin tưởng các yêu cầu.

6.2.1. XSSI

Các trang web độc hại có thể đoán địa chỉ IP và số cổng của thiết bị tương thích với Privet và cố gắng gọi API Privet bằng "src=%lt;api name>" bên trong &<script> thẻ:
<script type="text/javascript" src="http://192.168.1.42:8080/privet/info"></script>
Nếu không có biện pháp bảo vệ, các trang web độc hại sẽ có thể thực thi lệnh gọi API và kết quả truy cập.
Để ngăn chặn kiểu tấn công này, TẤT CẢ các lệnh gọi API Privet PHẢI yêu cầu tiêu đề &&tt;X-Privet-Token" trong yêu cầu. "src=%lt;api>" thẻ tập lệnh không thể thêm tiêu đề, giúp bảo vệ chống lại loại tấn công này một cách hiệu quả.

6.2.2. XSRF

http://en.wikipedia.org/wiki/cross-site_request_forgery
Một trang web độc hại có thể đoán địa chỉ IP và số cổng của thiết bị tương thích với Privet và cố gắng gọi API Privet bằng <iframe>, biểu mẫu hoặc một số cơ chế tải trang web khác. Những kẻ tấn công không thể truy cập kết quả của yêu cầu, nhưng nếu yêu cầu thực hiện một hành động (ví dụ như in), thì chúng có thể kích hoạt yêu cầu đó.

Để ngăn chặn cuộc tấn công này, chúng tôi yêu cầu phải có biện pháp bảo vệ sau đây:

  • Để API /privet/info mở cho XSRF
  • /privet/info API PHẢI KHÔNG thực hiện bất kỳ hành động nào trên thiết bị
  • Sử dụng /privet/info API để nhận x-privet-token
  • Tất cả các API khác PHẢI kiểm tra tiêu đề x-privet-token hợp lệ trong "X-Privet-Token".
  • x-privet-token NÊN chỉ có hiệu lực trong 24 giờ.

Ngay cả khi kẻ tấn công có thể thực thi API /privet/info, họ sẽ không thể đọc x-privet-token từ phản hồi và do đó, sẽ không thể gọi bất kỳ API nào khác.

Bạn nên tạo mã thông báo XSRF bằng thuật toán sau:

XSRF_token = base64( SHA1(device_secret + DELIMITER + issue_timecounter) + DELIMITER + issue_timecounter )

Các phần tử tạo mã thông báo XSRF:

  • DELIMITER là một ký tự đặc biệt, thường là ":"
  • issue_time đếm là số giây kể từ khi một số sự kiện (khoảng thời gian bắt đầu của hệ thống) hoặc thời gian khởi động của thiết bị (đối với bộ đếm CPU). issue_timeCounter liên tục tăng khi thiết bị hoạt động (xem mã xác minh mã thông báo bên dưới).
  • SHA1 – hàm băm sử dụng thuật toán SHA1
  • base64 - mã hóa base64
  • device_bí - bí mật dành riêng cho thiết bị. Mã PIN thiết bị PHẢI được cập nhật mỗi lần khởi động lại.

Các cách tạo bí mật thiết bị được đề xuất:

  • Tạo UUID mới mỗi lần khởi động lại
  • Tạo một số ngẫu nhiên trong 64 bit mỗi lần khởi động lại

Thiết bị không bắt buộc phải lưu trữ tất cả mã thông báo XSRF mà thiết bị đã cấp. Khi cần xác minh mã thông báo XSRF để xác thực tính hợp lệ, thiết bị phải giải mã mã thông báo base64. Lấy issue_timeCounter từ nửa sau (văn bản rõ ràng) và thử tạo hàm băm SHA1 của device_ sau + thiết bị + Việt Nam +. Nếu SHA1 mới tạo khớp với mã trong mã thông báo, thì thiết bị phải kiểm tra xem issue_timecó nằm trong khoảng thời gian có hiệu lực kể từ (24 giờ) của bộ đếm thời gian hiện tại hay không. Để làm như vậy, thiết bị sẽ lấy bộ đếm thời gian hiện tại (ví dụ: bộ đếm CPU) rồi trừ bộ đếm thời gian sự cố. Kết quả PHẢI là số giây kể từ khi có vấn đề về mã thông báo.

Lưu ý quan trọng: Đây là cách được đề xuất để triển khai tính năng bảo vệ XSRF. Máy khách của thông số kỹ thuật Privet không được cố gắng tìm hiểu mã thông báo XSRF, thay vào đó, chúng sẽ được coi là một hộp đen. Hình 6.2.3 minh hoạ một cách được đề xuất để triển khai X-Privet-Token và xác minh một yêu cầu thông thường.

6.2.3 Sơ đồ tạo mã thông báo và trình tự xác minh X-Privet

6.3. Sơ đồ quy trình

Phần này sẽ minh họa quy trình làm việc trong nhiều trường hợp.

6.3.1. Quy trình máy in ngay lập tức

6.3.2. Khởi động máy in đã đăng ký

6.3.3 Quy trình xử lý thông báo DKIM

6.3.4. Kiểm tra quy trình cài đặt máy in