Prive, क्लाउड डिवाइस लोकल डिस्कवरी एपीआई है. इसका इस्तेमाल क्लाउड सेवाओं में किया जाता है. इस दस्तावेज़ को इन सेक्शन में व्यवस्थित किया गया है:
- परिचय: Privet का परिचय
- डिस्कवरी: स्थानीय डिस्कवरी मैकेनिज़्म
- एलान: स्थानीय डिस्कवरी से जुड़ी सूचनाएं
- एपीआई: सामान्य क्लाउड डिवाइस के लिए Privet API
- प्रिंटर API: प्रिंटर में इस्तेमाल होने वाले Privet API
- कुछ और जानकारी: पूरक डायग्राम
1. परिचय
क्लाउड से कनेक्ट किए गए डिवाइसों के कई फ़ायदे हैं. डिवाइस ऑनलाइन रहने के दौरान, वे ऑनलाइन कन्वर्ज़न सेवाओं का इस्तेमाल कर सकते हैं. साथ ही, नौकरी की सूचियों को होस्ट कर सकते हैं. साथ ही, इन्हें दुनिया भर में कहीं से भी ऐक्सेस किया जा सकता है. हालांकि, किसी उपयोगकर्ता के पास कई क्लाउड डिवाइस ऐक्सेस करने की सुविधा होती है. इसलिए, हमें जगह के हिसाब से नज़दीकी डिवाइस ढूंढने का तरीका उपलब्ध कराना होता है. Privet प्रोटोकॉल का मकसद, क्लाउड डिवाइसों को सुविधाजनक तरीके से स्थानीय खोज के तरीके से जोड़ना है, ताकि नए डिवाइसों में डिवाइसों को आसानी से खोजा जा सके.
इस प्रोटोकॉल के लक्ष्य ये हैं:- क्लाउड डिवाइस को स्थानीय स्तर पर खोजे जाने लायक बनाएं
- क्लाउड सेवा के साथ क्लाउड डिवाइस पंजीकृत करें
- रजिस्टर किए गए डिवाइसों को क्लाउड से जोड़ें
- ऑफ़लाइन काम की क्षमता को चालू करें
- छोटे डिवाइसों को आसानी से इस्तेमाल करने के लिए, उन्हें इस्तेमाल करना आसान बनाएं
Privet प्रोटोकॉल के दो मुख्य हिस्से होते हैं: डिस्कवरी और एपीआई. खोज का इस्तेमाल लोकल नेटवर्क पर डिवाइस की पहचान करने के लिए किया जाता है. साथ ही, एपीआई का इस्तेमाल डिवाइस के बारे में जानकारी पाने और कुछ कार्रवाइयां करने के लिए किया जाता है. इस पूरे दस्तावेज़ में डिवाइस, क्लाउड से कनेक्ट किए गए डिवाइस के बारे में बताता है, जो Privet प्रोटोकॉल को लागू करता है.
2. डिस्कवरी
डिस्कवरी, शून्य पर आधारित (mDNS + DNS-SD) प्रोटोकॉल है. डिवाइस को IPv4 लिंक-स्थानीय पता लागू करना होगा. यह ज़रूरी है कि डिवाइस mDNS और डीएनएस-एसडी की विशेषताओं के मुताबिक हो.
- http://www.rfc-editor.org/rfc/rfc3927.txt (IPv4 लिंक-स्थानीय)
- http://www.rfc-editor.org/rfc/rfc4862.txt (IPv6 लिंक-स्थानीय)
- http://www.rfc-editor.org/rfc/rfc6762.txt (mDNS)
- http://www.rfc-editor.org/rfc/rfc6763.txt (DNS-SD)
डिवाइस को ऊपर दी गई जानकारी के मुताबिक नाम के विवाद सुलझाने की प्रक्रिया पूरी करनी होगी.
2.1. सेवा प्रकार
डीएनएस सेवा की खोज, सेवा के इन फ़ॉर्मैट के लिए इस फ़ॉर्मैट का इस्तेमाल करती है: _applicationprotocol._transitportprotocol. Privet प्रोटोकॉल के मामले में, डीएनएस-एसडी का सेवा टाइप ऐसा होना चाहिए: _privet._tcp
डिवाइस दूसरी सेवाओं के प्रकार भी लागू कर सकता है. हमारा सुझाव है कि सेवा के सभी टाइप के लिए, सेवा के इंस्टेंस का एक ही नाम इस्तेमाल करें. उदाहरण के लिए: प्रिंटर, प्रिंटर और XYZ._privet._tcp" और "Printer XYZ._printer._tcp" सेवाओं का इस्तेमाल कर सकता है. इससे, उपयोगकर्ता के लिए सेट अप करना आसान हो जाएगा. हालांकि, Privet क्लाइंट सिर्फ़ "_privet._tcp" को खोजेगा.
डिवाइस को मुख्य सेवा के तौर पर दिखाने के अलावा, डिवाइस को PTR रिकॉर्ड के लिए विज्ञापन भी दिखाना होगा. यह सब-टाइप, डीएनएस-एसडी की खास जानकारी: "7.1 देखें). चुनिंदा इंस्टेंस की गिनती (उपप्रकार)"). फ़ॉर्मैट इस तरह होना चाहिए: _<subtype>._sub._privet._tcp
फ़िलहाल, डिवाइस का सिर्फ़ एक सब-टाइप प्रिंटर के साथ काम करता है. इसलिए, सभी प्रिंटर को दो पीटीआर रिकॉर्ड का विज्ञापन करना होगा:
- _privet._tcp.local.
- _printer._sub._privet._tcp.local.
2.2. TXT रिकॉर्ड
डीएनएस सर्विस डिस्कवरी फ़ील्ड, TXT रिकॉर्ड में सेवा के बारे में वैकल्पिक जानकारी जोड़ने के लिए फ़ील्ड के बारे में बताता है. TXT रिकॉर्ड में की/वैल्यू पेयर शामिल हैं. हर की/वैल्यू पेयर, लंबाई वाले बाइट से शुरू होता है. इसके बाद, टेक्स्ट की लंबाई 255 बाइट तक होती है. कुंजी, पहले ‘=’ वर्ण से पहले का टेक्स्ट और आखिरी '=' वर्ण के आखिर तक मौजूद टेक्स्ट की वैल्यू होती है. खास जानकारी में रिकॉर्ड में कोई वैल्यू नहीं डाली जा सकती है. ऐसे में, कोई भी वर्ण '=' नहीं होगा या '=' वर्ण के बाद कोई टेक्स्ट नहीं होगा. (डीएनएस-एसडी की खास जानकारी देखें: "6.1). डीएनएस TXT रिकॉर्ड और कोट के लिए सामान्य फ़ॉर्मैट के नियम और&TXT रिकॉर्ड फ़ॉर्मैट "6.2. डीएनएस-एसडी TXT रिकॉर्ड साइज़ कोट (सुझाई गई लंबाई के लिए).
Privet के लिए यह ज़रूरी है कि डिवाइस, TXT रिकॉर्ड में नीचे दिए गए की/वैल्यू पेयर भेजे. की/वैल्यू स्ट्रिंग, केस-इनसेंसिटिव होती हैं. जैसे, "CS=online" और quot;cs=online" एक ही होती हैं. TXT रिकॉर्ड में जानकारी वही होनी चाहिए जो /info API के ज़रिए ऐक्सेस की जा सकती है (4.1 देखें). एपीआई सेक्शन).
हमारा सुझाव है कि आप TXT रिकॉर्ड का साइज़ 512 बाइट से कम रखें.
2.2.1. वर्शन
TXT संरचना का वर्शन. TXTvers TXT स्ट्रक्चर का पहला रिकॉर्ड होना चाहिए. फ़िलहाल, 1 वर्शन ही काम करता है.
txtvers=1
2.2.2. टाइ
इस नीति से डिवाइस का ऐसा नाम मिलता है जिसे उपयोगकर्ता पढ़ सकते हैं. उदाहरण के लिए:
ty=Google Cloud Ready Printer Model XYZ
2.2.3. नोट (वैकल्पिक)
इस नीति से डिवाइस का ऐसा नाम मिलता है जिसे उपयोगकर्ता पढ़ सकते हैं. उदाहरण के लिए:
note=1st floor lobby printer
ध्यान दें: यह एक वैकल्पिक कुंजी है और इसे छोड़ा जा सकता है. हालांकि, उपयोगकर्ताओं के इस वैल्यू में बदलाव करने की अनुमति होनी चाहिए. डिवाइस का रजिस्ट्रेशन करते समय भी यही जानकारी इस्तेमाल की जानी चाहिए.
2.2.4. यूआरएल
वह सर्वर यूआरएल जिससे यह डिवाइस कनेक्ट है. इसमें प्रोटोकॉल भी शामिल है. उदाहरण के लिए:
url=https://www.google.com/cloudprint
2.2.5. प्रकार
कॉमा से अलग की गई, डिवाइस के सब-टाइप की सूची. फ़ॉर्मैट यह है: "type=_subtype1,_subtype2". फ़िलहाल, डिवाइस का सिर्फ़ एक सब-टाइप प्रिंटर है.
type=printer
सूची में शामिल, हर सब-टाइप के लिए एक संबंधित PTR रिकॉर्ड का इस्तेमाल किया जाना चाहिए. सेवा के लिए इस्तेमाल होने वाले हर सब-टाइप के लिए, उससे जुड़ा एक आइटम होना चाहिए. सेवा के सब-टाइप का नाम (<subtype>._sub._privet._tcp) यहां डिवाइस टाइप के बराबर होना चाहिए.
2.2.6. आईडी
डिवाइस आईडी. अगर डिवाइस को अब तक रजिस्टर नहीं किया गया है, तो यह कुंजी मौजूद होनी चाहिए, लेकिन वैल्यू खाली होनी चाहिए. उदाहरण के लिए:
id=11111111-2222-3333-4444-555555555555 id=
2.2.7. 0 सीएसएस
डिवाइस की मौजूदा कनेक्शन स्थिति दिखाता है. इस स्पेसिफ़िकेशन में, चार संभावित वैल्यू के बारे में बताया गया है.
- "online" बताता है कि डिवाइस अभी क्लाउड से कनेक्ट है.
- "ऑफ़लाइन" बताती है कि डिवाइस लोकल नेटवर्क पर उपलब्ध है लेकिन सर्वर से बात नहीं कर सकता.
- "connecting" बताता है कि डिवाइस अपने स्टार्टअप क्रम को परफ़ॉर्म कर रहा है और अभी तक पूरी तरह से ऑनलाइन नहीं है.
- "कॉन्फ़िगर नहीं की गई है" डिवाइस का इंटरनेट ऐक्सेस अभी तक कॉन्फ़िगर नहीं किया गया है. फ़िलहाल, इस वैल्यू का इस्तेमाल नहीं किया गया है. हालांकि, यह आने वाले समय में निर्देशों के वर्शन में मददगार हो सकता है.
- cs=online
- cs=ऑफ़लाइन
- cs=कनेक्टिंग
अगर डिवाइस को क्लाउड के साथ रजिस्टर किया गया है, तो इसे चालू करते समय सर्वर की कनेक्टिविटी की जांच की जानी चाहिए. ऐसा करने से, सर्वर की कनेक्शन की स्थिति का पता चलता है. उदाहरण के लिए, डिवाइस की सेटिंग पाने के लिए, क्लाउड एपीआई को कॉल करना. यह वैल्यू रिपोर्ट करने के लिए, डिवाइस अपने सूचना चैनल (उदाहरण के लिए, XMPP) कनेक्शन की स्थिति का इस्तेमाल कर सकता है. शुरू करने पर, रजिस्टर नहीं किए गए डिवाइस किसी डोमेन को पिंग कर सकते हैं, ताकि वे कनेक्शन की स्थिति का पता लगा सकें. उदाहरण के लिए, क्लाउड प्रिंट डिवाइसों के लिए, www.google.com पर पिंग करें.
3. सूचनाएं
डिवाइस चालू होने पर, बंद होने या उसकी स्थिति में बदलाव होने पर, डिवाइस को एलान का चरण पूरा करना होगा जैसा कि mDNS के निर्देशों में बताया गया है. इस सुविधा को, इससे जुड़ी सूचना कम से कम दो बार भेजनी चाहिए. साथ ही, इसमें कम से कम एक सेकंड का इंटरवल होना चाहिए.
3.1. स्टार्टअप
डिवाइस चालू होने पर, जांच करनी होगी और mDNS के निर्देशों में बताए गए तरीके के मुताबिक निर्देश देने होंगे. इस मामले में, SRV, PTR और TXT रिकॉर्ड भेजे जाने चाहिए. हमारा सुझाव है कि अगर मुमकिन हो, तो सभी रिकॉर्ड को एक डीएनएस रिस्पॉन्स में ग्रुप करें. अगर नहीं, तो नीचे दिए गए ऑर्डर का सुझाव दिया जाता है: SRV, PTR, TXT रिकॉर्ड.
3.2. शटडाउन
डिवाइस बंद होने पर इसे सभी दिलचस्पी वाले पक्षों को TTL=0 (जैसा कि mDNS के दस्तावेज़ में बताया गया है) भेजकर इसकी सूचना देनी चाहिए. ऐसा करने के लिए उन सभी लोगों को इसकी सूचना देनी चाहिए जो इसके बारे में जानना चाहते हैं.
3.3. अपडेट
अगर TXT में दी गई किसी भी जानकारी में बदलाव किया गया है, तो डिवाइस को अपडेट का एलान करना होगा. इस मामले में, सिर्फ़ नया TXT रिकॉर्ड भेजना काफ़ी है. उदाहरण के लिए, किसी डिवाइस को रजिस्टर करने के बाद, उसे नए डिवाइस आईडी के साथ अपडेट से जुड़ी सूचना भेजना ज़रूरी होता है.
4. एपीआई
क्लाउड डिवाइस का पता चलने के बाद, क्लाइंट से सीधे डिवाइस पर लोकल कम्यूनिकेशन चालू हो जाता है. सभी एपीआई एचटीटीपी 1.1 पर आधारित हैं. डेटा फ़ॉर्मैट, JSON के आधार पर होते हैं. एपीआई अनुरोध, जीईटी या पोस्ट अनुरोध हो सकते हैं.
हर अनुरोध में एक मान्य "X-Privet-Token" हेडर होना चाहिए. सिर्फ़ इस अनुरोध के लिए एक खाली "X-Privet-Token" हेडर इस्तेमाल करने की अनुमति है /privet/info अनुरोध (ध्यान दें कि हेडर अब भी मौजूद होना चाहिए). अगर "X-Privet-Token" हेडर मौजूद नहीं है, तो डिवाइस को इन एचटीटीपी 400 गड़बड़ी के साथ जवाब देना चाहिए:
HTTP/1.1 400 Missing X-Privet-Token header.
अगर "X-Privet-Token" हेडर खाली है या अमान्य है, तो डिवाइस के लिए "अमान्य X-Privet-Token गड़बड़ी" (अमान्य_x_privet_token) की जानकारी वाला सेक्शन देखें. इसका अपवाद सिर्फ़ /info API है. ऐसा क्यों किया जाता है और टोकन कैसे जनरेट होने चाहिए, इस बारे में ज़्यादा जानकारी के लिए, अपेंडिक्स A: XSSI और XSRF के हमले और रोकथाम देखें.
अगर अनुरोध किया गया एपीआई मौजूद नहीं है या उसके साथ काम नहीं करता, तो डिवाइस को एचटीटीपी 404 वाली गड़बड़ी दिखानी चाहिए.
4.1. एपीआई की उपलब्धता
किसी भी एपीआई के दिखाए जाने (/info API सहित) से पहले, डिवाइस को स्थानीय सेटिंग की जांच करने के लिए सर्वर से संपर्क करना होगा. लोकल सेटिंग को रीस्टार्ट होने के बीच सुरक्षित रखा जाना चाहिए. अगर सर्वर उपलब्ध नहीं है, तो आखिरी बार इस्तेमाल की गई लोकल सेटिंग का इस्तेमाल किया जाना चाहिए. अगर डिवाइस को अब तक रजिस्टर नहीं किया गया है, तो इसे डिफ़ॉल्ट सेटिंग के मुताबिक होना चाहिए.
क्लाउड प्रिंट डिवाइस को स्थानीय सेटिंग रजिस्टर करने, पाने, और अपडेट करने के लिए नीचे दिया गया तरीका अपनाना होगा.
4.1.1. रजिस्ट्रेशन
डिवाइस के रजिस्टर होने पर, "local_settings" पैरामीटर इस तरह से बताना चाहिए:
{ "current": { "local_discovery": true, "access_token_enabled": true, "printer/local_printing_enabled": true, "printer/conversion_printing_enabled": true, "xmpp_timeout_value": 300 } }ये सेटिंग सेट की जा सकती हैं:
वैल्यू का नाम | वैल्यू टाइप | ब्यौरा |
---|---|---|
local_डिस्कवरी | बूलियन | इससे पता चलता है कि स्थानीय खोज सुविधा की अनुमति है या नहीं. अगर इसमें "false" हैं तो सभी स्थानीय एपीआई (/info सहित) और डीएनएस-एसडी खोज बंद होने चाहिए. डिफ़ॉल्ट रूप से, रजिस्टर करने वाले नए डिवाइसों को "true" पास करना चाहिए. |
access_token_Enabled | बूलियन (ज़रूरी नहीं) | यह बताता है कि स्थानीय नेटवर्क पर /accesstoken API को दिखाया जाना चाहिए या नहीं. डिफ़ॉल्ट रूप से, "true" होना चाहिए. |
प्रिंटर/local_printing_Enabled | बूलियन (ज़रूरी नहीं) | यह बताता है कि स्थानीय प्रिंटिंग की सुविधा (/printer/createjob, /printer/submitdoc, /printer/jobstate) को स्थानीय नेटवर्क पर दिखाया जाना चाहिए या नहीं. डिफ़ॉल्ट रूप से, "true" होना चाहिए. |
प्रिंटर/कन्वर्ज़न_प्रिंटिंग चालू है | बूलियन (ज़रूरी नहीं) | इससे पता चलता है कि स्थानीय प्रिंटिंग की सुविधा, कन्वर्ज़न के लिए सर्वर को जॉब भेज सकती है या नहीं. यह सिर्फ़ तब ही काम करता है, जब लोकल प्रिंटिंग की सुविधा चालू हो. |
xmpp_timeout_value | int (ज़रूरी नहीं) | इससे, XMPP चैनल के पिंग के बीच के सेकंड की संख्या का पता चलता है. डिफ़ॉल्ट रूप से यह 300 (5 मिनट) या उससे ज़्यादा होना चाहिए. |
अहम जानकारी: कोई भी वैकल्पिक वैल्यू न होने का मतलब है कि डिवाइस पर, उससे जुड़ी सुविधाएं काम नहीं करती हैं.
4.1.2. स्टार्टअप
डिवाइस को चालू करने पर, उसे सर्वर से संपर्क करके यह पता करना चाहिए कि स्थानीय नेटवर्क पर दिखाने के लिए कौनसे एपीआई उपलब्ध हैं. क्लाउड प्रिंट से कनेक्ट किए गए प्रिंटर के लिए, उन्हें कॉल करना चाहिए:
/cloudprint/printer?printerid=<printer_id>या
/cloudprint/list
/cloudprint/printer को /sort/list के मुकाबले ज़्यादा पसंद किया जाता है. हालांकि, दोनों काम करेंगे.
यह एपीआई, डिवाइस के मौजूदा पैरामीटर दिखाता है. इसमें लोकल एपीआई की सेटिंग भी शामिल हैं. सर्वर से दिए जाने वाले जवाब का फ़ॉर्मैट यह होगा:
"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" object उन सेटिंग को दिखाता है जो इस समय दी गई हैं.
"pending"Object उन सेटिंग को दिखाता है जिन्हें डिवाइस पर लागू किया जाना चाहिए (हो सकता है कि यह ऑब्जेक्ट मौजूद न हो).
जब डिवाइस में "बताया गया"सेटिंग दिख जाती हैं, तो उसकी स्थिति अपडेट होनी ज़रूरी है (नीचे देखें).
4.1.3. अपडेट
अगर सेटिंग को अपडेट करना ज़रूरी होगा, तो डिवाइस पर XMPP सूचना भेजी जाएगी. सूचना इस फ़ॉर्मैट में होगी:
<device_id>/update_settings
ऐसी सूचना मिलने पर, डिवाइस को नई सेटिंग पाने के लिए सर्वर से क्वेरी करनी होगी. क्लाउड प्रिंट डिवाइसों को इन चीज़ों का इस्तेमाल करना चाहिए:
/cloudprint/printer?printerid=<printer_id>
जब डिवाइस /cloudprint/printer एपीआई (शुरुआती पेज पर या सूचना की वजह से) की वजह से रुका होता है, तब उसे नई सेटिंग को याद रखने की ज़रूरत होती है. ऐसा होने पर, डिवाइस का अंदरूनी हिस्सा अपडेट होना चाहिए. नई सेटिंग की पुष्टि करने के लिए, इसे सर्वर एपीआई को कॉल करना होगा. क्लाउड प्रिंटर के लिए, डिवाइस को रजिस्ट्रेशन के दौरान /sort/update API और quot;local_settings" पैरामीटर का इस्तेमाल करना होगा.
XMPP चैनल से दोबारा कनेक्ट करने पर, डिवाइस को /cloudprint/printer एपीआई कॉल करना चाहिए. इससे यह पता लगाया जा सकता है कि स्थानीय सेटिंग में पिछली बार बदलाव हुआ है या नहीं.
4.1.3.1. स्थानीय सेटिंग अभी बाकी है
"local_settings" पैरामीटर, जिसे डिवाइस कॉल करने के लिए सर्वर एपीआई का इस्तेमाल करता है, उसमें कभी भी "quot;pending" सेक्शन नहीं होना चाहिए.
4.1.3.2. स्थानीय सेटिंग वर्तमान
सिर्फ़ डिवाइस, "local_settings" सेक्शन के सेक्शन को बदल सकता है. दूसरे सभी लोग "pending" सेक्शन को बदल देंगे और डिवाइस के हिसाब से "current" सेक्शन में बदलावों के लागू होने का इंतज़ार करते हैं.
4.1.4. ऑफ़लाइन
सूचना लॉन्च होने के बाद, सर्वर से संपर्क न कर पाने पर, डिवाइस को आखिरी बार इस्तेमाल की गई स्थानीय सेटिंग का इस्तेमाल करना होगा.
4.1.5. डिवाइस को सेवा से मिटाया जा रहा है
अगर डिवाइस को सेवा से मिटा दिया गया है (उदाहरण के लिए, GCP) तो उस डिवाइस पर एक XMPP सूचना भेजी जाएगी. सूचना इस फ़ॉर्मैट में होगी:
<device_id>/delete
ऐसी सूचना मिलने पर, डिवाइस को सर्वर के पास जाकर उसकी स्थिति देखनी होगी. क्लाउड प्रिंट डिवाइस को इन चीज़ों का इस्तेमाल करना होगा:
/cloudprint/printer?printerid=<printer_id>
डिवाइस को सक्सेस=गलत और सही डिवाइस/प्रिंटर के बारे में जानकारी नहीं होनी चाहिए. इसका मतलब है कि डिवाइस को सर्वर से हटा दिया गया है और डिवाइस को अपने क्रेडेंशियल हमेशा के लिए मिटाने होंगे और डिफ़ॉल्ट फ़ैक्ट्री सेटिंग मोड पर जाना होगा.
जब भी डिवाइस को कोई जवाब मिलता है, जिसमें बताया जाता है कि /cloudprint/printer एपीआई (स्टार्टअप, अपडेट सेटिंग की सूचना, हर दिन पिंग) की वजह से उसे मिटाया गया है, तो उसे अपने क्रेडेंशियल मिटाने और डिफ़ॉल्ट मोड में जाना होगा.
4.2. /privet/info एपीआई
जानकारी की एपीआई ज़रूरी है और हर डिवाइस से इसे लागू किया जाना चाहिए. यह एचटीटीपी जीईटी अनुरोध है. इसे कोटेशन के लिए इस्तेमाल करें;/privet/info" यूआरएल: GET /privet/info एचटीटीपी/1.1
जानकारी देने वाले एपीआई से, डिवाइस और उसके साथ काम करने वाले फ़ंक्शन के बारे में बुनियादी जानकारी मिलती है. इस एपीआई को कभी भी डिवाइस का स्टेटस नहीं बदलना चाहिए और न ही कोई कार्रवाई करनी चाहिए, क्योंकि इस पर XSRF के हमले का जोखिम हो सकता है. सिर्फ़ इस एपीआई का इस्तेमाल करने की अनुमति है, जिसमें खाली और कोट;X-Privet-Token" हेडर है. क्लाइंट को /privet/info API को "X-Privet-Token" हेडर पर X-Privet-Token: "" पर सेट करना चाहिए
जानकारी एपीआई को खोज के दौरान TXT रिकॉर्ड में मौजूद डेटा की जानकारी को दिखाना होगा.
4.2.1. इनपुट
/privet/info एपीआई में कोई इनपुट पैरामीटर नहीं है.
4.2.2. रिटर्न टिकट
/privet/info API, डिवाइस और काम करने वाले फ़ंक्शन के बारे में बुनियादी जानकारी देता है.
TXT कॉलम, डीएनएस-एसडी TXT रिकॉर्ड में मौजूद फ़ील्ड के बारे में बताता है.
वैल्यू का नाम | वैल्यू टाइप | ब्यौरा | TXT |
---|---|---|---|
वर्शन | स्ट्रिंग | एपीआई का सबसे नया वर्शन (major.minor) इस्तेमाल किया जा सकता है, जो फ़िलहाल 1.0 है | |
नाम | स्ट्रिंग | डिवाइस का ऐसा नाम जिसे आसानी से पढ़ा जा सके. | टाय |
जानकारी | स्ट्रिंग | (ज़रूरी नहीं) डिवाइस का ब्यौरा. उपयोगकर्ता को बदला जा सकता चाहिए. | ध्यान दें |
यूआरएल | स्ट्रिंग | उस सर्वर का यूआरएल जिस पर यह डिवाइस बात कर रहा है. यूआरएल में प्रोटोकॉल की खास जानकारी शामिल होनी चाहिए, उदाहरण के लिए: https://www.google.com/cloudprint. | यूआरएल |
टाइप करें | स्ट्रिंग की सूची | काम करने वाले डिवाइसों के टाइप की सूची. | टाइप करें |
id | स्ट्रिंग | अगर डिवाइस अभी तक रजिस्टर नहीं किया गया है, तो डिवाइस आईडी खाली है. | id |
device_state | स्ट्रिंग | डिवाइस की स्थिति | |
कनेक्शन_स्थिति | स्ट्रिंग | सर्वर से कनेक्शन की स्थिति (base_url)
ऑनलाइन - कनेक्शन उपलब्ध है ऑफ़लाइन - कोई कनेक्शन नहीं कनेक्ट किया जा रहा है - शुरू करने के तरीके लागू किए जा रहे हैं कॉन्फ़िगर नहीं की गई - कनेक्शन अब तक कॉन्फ़िगर नहीं किया गया है सूचना के चैनल के आधार पर, रजिस्टर किया गया डिवाइस कनेक्शन की स्थिति की रिपोर्ट कर सकता है (जैसे, XMPP कनेक्शन की स्थिति). | cs |
निर्माता | स्ट्रिंग | डिवाइस बनाने वाली कंपनी का नाम | |
मॉडल | स्ट्रिंग | डिवाइस का मॉडल | |
सीरियल नंबर | स्ट्रिंग | यूनीक डिवाइस आइडेंटिफ़ायर. इस खास जानकारी में, यह एक UUID होना चाहिए. (GCP 1.1 की खास जानकारी)
(ज़रूरी नहीं) हम हर जगह एक ही सीरियल नंबर आईडी का इस्तेमाल करने का सुझाव देते हैं, ताकि अलग-अलग क्लाइंट एक ही डिवाइस की पहचान कर सकें. उदाहरण के लिए, IPP लागू करने वाले प्रिंटर इस क्रमांक की आईडी का उपयोग "printer-device-id" फ़ील्ड में कर सकते हैं. | |
फ़र्मवेयर | स्ट्रिंग | डिवाइस फ़र्मवेयर वर्शन | |
अपटाइम | int | डिवाइस बूट की ओर से सेकंड की संख्या. | |
सेट अप यूआरएल | स्ट्रिंग | (ज़रूरी नहीं) सेट अप करने के निर्देशों की मदद से, पेज का यूआरएल (इसमें प्रोटोकॉल शामिल है) | |
support_url | स्ट्रिंग | (ज़रूरी नहीं) सहायता (अक्सर पूछे जाने वाले सवाल) की जानकारी वाले पेज का यूआरएल (इसमें प्रोटोकॉल शामिल है) | |
अपडेट_का_यूआरएल | स्ट्रिंग | (वैकल्पिक) अपडेट फ़र्मवेयर निर्देशों वाले पेज का यूआरएल (प्रोटोकॉल भी शामिल) | |
एक्स-प्राइट-टोकन | स्ट्रिंग | S-Privet-Token हेडर की वैल्यू, जिसे XSSI और XSRF के हमलों से बचने के लिए, सभी एपीआई को भेजा जाना चाहिए. ज़्यादा जानकारी के लिए 6.1. देखें. | |
एपीआई | एपीआई की जानकारी | काम करने वाले एपीआई की सूची (नीचे दी गई है) | |
सिमैंटिक_स्टेट | JSON | (ज़रूरी नहीं) CloudDeviceState फ़ॉर्मैट में डिवाइस की सिमैंटिक स्थिति. |
api - एक JSON सूची है जिसमें लोकल नेटवर्क के ज़रिए उपलब्ध एपीआई की सूची होती है. ध्यान दें, हो सकता है कि लोकल नेटवर्क पर एक ही समय पर, सभी एपीआई उपलब्ध न हों. उदाहरण के लिए, हाल ही में कनेक्ट किए गए डिवाइस को सिर्फ़ /registration api के साथ काम करना चाहिए:
"api": [ "/privet/register", ]डिवाइस का रजिस्ट्रेशन पूरा होने के बाद, डिवाइस को /रजिस्टर एपीआई का इस्तेमाल बंद कर देना चाहिए. डिवाइस को सेवा से जुड़ी जानकारी उपलब्ध कराना चाहिए, ताकि यह पता चल सके कि स्थानीय नेटवर्क पर कौन-कौनसे एपीआई बिना अनुमति के सार्वजनिक किए जा सकते हैं. उदाहरण के लिए:
"api": [ "/privet/accesstoken", "/privet/capabilities", "/privet/printer/submitdoc", ]
इस समय नीचे दिए गए एपीआई उपलब्ध हैं:
- /privet/register - लोकल नेटवर्क पर डिवाइस पंजीकरण के लिए एपीआई. (ज़्यादा जानकारी के लिए, /privet/register एपीआई देखें). इस डिवाइस को क्लाउड में रजिस्टर करने के बाद, इस एपीआई को छिपाना होगा.
- /privet/accesstoken - डिवाइस से ऐक्सेस टोकन के लिए अनुरोध करने वाला एपीआई (ज़्यादा जानकारी के लिए /privet/accesstoken API देखें).
- /privet/capabilies - डिवाइस की क्षमताएं जानने के लिए एपीआई (ज़्यादा जानकारी के लिए /privet/capabilies एपीआई देखें).
- /privet/printer/* - डिवाइस के हिसाब से खास एपीआई (कोटेशन) और कोटेशन; जानकारी के लिए प्रिंटर से जुड़े एपीआई देखें.
{ "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", ] }यहां ऐसे प्रिंटर के /privet/info जवाब का उदाहरण दिया गया है जो इंक खत्म हो गया है (ध्यान दें not_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. गड़बड़ियां
/privet/info एपीआई सिर्फ़ तब गड़बड़ी दिखाता है, जब X-Privet-Token हेडर मौजूद नहीं होता. इसमें एचटीटीपी 400 से जुड़ी गड़बड़ी होनी ज़रूरी है:
HTTP/1.1 400 Missing X-Privet-Token header.
4.3. /privet/register API
/privet/register API वैकल्पिक है. यह एचटीटीपी पोस्ट अनुरोध है. /privet/registration एपीआई के लिए मान्य X-Privet-Token हेडर ज़रूरी है. डिवाइस को इस एपीआई को "/privet/register" यूआरएल पर लागू करना होगा:
POST /privet/register?action=start&user=user@domain.com HTTP/1.1 POST /privet/register?action=complete&user=user@domain.com HTTP/1.1
डिवाइस को एपीआई /privet/register सिर्फ़ तब दिखाना चाहिए, जब वह बिना पहचान वाले रजिस्ट्रेशन की अनुमति देता हो. उदाहरण के लिए:
- जब डिवाइस चालू हो (या डिवाइस पर किसी खास बटन पर क्लिक करने के बाद) और अभी तक रजिस्टर न किया गया हो, तो उसे /privet/register एपीआई दिखाना चाहिए, ताकि स्थानीय नेटवर्क का कोई उपयोगकर्ता प्रिंटर पर दावा कर सके.
- रजिस्ट्रेशन पूरा होने के बाद, डिवाइस को /privet/register API दिखाना बंद कर देना चाहिए, ताकि लोकल नेटवर्क पर मौजूद कोई दूसरा उपयोगकर्ता उसे फिर से इस्तेमाल न कर सके.
- कुछ डिवाइसों में, रजिस्टर करने के अलग-अलग तरीके हो सकते हैं. हो सकता है कि वे /privet/register API बिल्कुल भी ज़ाहिर न करें (उदाहरण के लिए, Chrome Cloud Print Connector).
रजिस्ट्रेशन की प्रोसेस में तीन चरण होते हैं (क्लाउड प्रिंट के लिए बिना पहचान वाला रजिस्ट्रेशन देखें).
- पहचान छिपाकर, रजिस्ट्रेशन की प्रक्रिया शुरू करें.
- क्लाइंट /privet/register API कॉल करके यह प्रक्रिया शुरू करता है. डिवाइस को उस समय उपयोगकर्ता की पुष्टि होने का इंतज़ार करना चाहिए.
- दावा टोकन पाएं.
क्लाइंट के पोल की मदद से, यह पता लगाया जाएगा कि डिवाइस कब से इस्तेमाल के लिए तैयार है. डिवाइस तैयार होने के बाद, यह सर्वर को रजिस्ट्रेशन टोकन और रजिस्ट्रेशन यूआरएल पाने का अनुरोध भेजता है. मिला टोकन और यूआरएल, क्लाइंट को वापस किया जाना चाहिए. इस चरण के दौरान, अगर डिवाइस को रजिस्ट्रेशन शुरू करने के लिए दूसरा कॉल मिलता है, तो:
- अगर यह उपयोगकर्ता पहले ही रजिस्ट्रेशन शुरू कर चुका है, तो सारा पुराना डेटा (अगर कोई है) हटा दें और एक नई रजिस्ट्रेशन प्रोसेस शुरू करें.
- अगर यह अलग उपयोगकर्ता करता है, तो device_व्यस्त गड़बड़ी और 30 सेकंड का टाइम आउट दिखाएं.
रजिस्ट्रेशन की प्रक्रिया पूरी करें.
क्लाइंट के डिवाइस पर दावा करने के बाद, क्लाइंट को डिवाइस रजिस्टर करना होगा. रजिस्ट्रेशन की प्रोसेस पूरी होने के बाद, डिवाइस को अपडेट की सूचना भेजी जानी चाहिए. इसमें, हाल ही में मिले डिवाइस आईडी की जानकारी भी शामिल होनी चाहिए.
ध्यान दें: जब डिवाइस /privet/रजिस्टर एपीआई कॉल को प्रोसेस कर रहा हो, तो किसी दूसरे /privet/register एपीआई कॉल को एक साथ प्रोसेस नहीं किया जा सकता. डिवाइस को, device_व्यस्त की गड़बड़ी और 30 सेकंड का टाइम आउट दिखना चाहिए.
डिवाइस पर रजिस्ट्रेशन के लिए उपयोगकर्ता की पुष्टि करने का सुझाव दिया जाता है. अगर लागू हो, तो डिवाइस को /privet/register?action=start API कॉल मिलने के बाद उपयोगकर्ता की पुष्टि के लिए इंतज़ार करना चाहिए. उपयोगकर्ता /privet/register?action=getClaimToken API पर कॉल करके पता लगाएगा कि उपयोगकर्ता की पुष्टि कब पूरी हुई और दावे का टोकन उपलब्ध है या नहीं. अगर उपयोगकर्ता, डिवाइस पर रजिस्ट्रेशन रद्द करता है (जैसे, रद्द करें बटन दबाना), तो user_cancel गड़बड़ी का पता चलना चाहिए. अगर उपयोगकर्ता ने किसी तय समय के अंदर रजिस्ट्रेशन की पुष्टि नहीं की है, तो safety_timeout को गड़बड़ी के तौर पर दिखाया जाना चाहिए. ज़्यादा जानकारी के लिए, डिफ़ॉल्ट सेक्शन देखें.
4.3.1. इनपुट
/privet/register API में नीचे दिए गए इनपुट पैरामीटर होते हैं:नाम | वैल्यू |
---|---|
किसी खास रूटीन से जुड़ी कार्रवाई | इनमें से कोई एक विकल्प हो सकता है:
start - रजिस्ट्रेशन की प्रोसेस शुरू करने के लिए getClaimToken - डिवाइस के लिए दावा टोकन वापस पाएं cancel - रजिस्ट्रेशन की प्रोसेस रद्द करने के लिए complete - रजिस्ट्रेशन की प्रोसेस पूरी करने के लिए |
उपयोगकर्ता | उस उपयोगकर्ता का ईमेल जो इस डिवाइस का दावा करेगा. |
डिवाइस को देखना होगा कि सभी कार्रवाइयों से शुरू होने वाला ईमेल पता (start, getClaimToken, cancelling, पूरा हो गया) है.
4.3.2. रिटर्न टिकट
/privet/record एपीआई नीचे दिया गया डेटा दिखाता है:मान का नाम | वैल्यू टाइप | ब्यौरा |
---|---|---|
किसी खास रूटीन से जुड़ी कार्रवाई | स्ट्रिंग | इनपुट पैरामीटर के जैसी ही कार्रवाई. |
उपयोगकर्ता | स्ट्रिंग (ज़रूरी नहीं) | इनपुट पैरामीटर के समान उपयोगकर्ता (शामिल नहीं होने पर, अगर इनपुट में छोड़ा गया हो). |
टोकन | स्ट्रिंग (ज़रूरी नहीं) | रजिस्ट्रेशन टोकन (ज़रूरी और "getClaimToken" जवाब, ज़रूरी "start", "complete", "cancel" के लिए ज़रूरी है) |
दावा_यूआरएल | स्ट्रिंग (ज़रूरी नहीं) | रजिस्ट्रेशन यूआरएल (ज़रूरी है और "getClaimToken" जवाब, "start", "complete", "cancel" के लिए छोड़ा गया). क्लाउड प्रिंटर के लिए यह सर्वर से मिला "complete_sign_url" होना चाहिए. |
स्वचालित_दावा_URL | स्ट्रिंग (ज़रूरी नहीं) | रजिस्ट्रेशन यूआरएल (ज़रूरी है और "getClaimToken" जवाब, "start", "complete", "cancel" के लिए छोड़ा गया). क्लाउड प्रिंटर के लिए यह सर्वर से मिला "automatic_sign_url" होना चाहिए. |
device_id | स्ट्रिंग (ज़रूरी नहीं) | नया डिवाइस आईडी ("start" रिस्पॉन्स, "complete" के लिए ज़रूरी है). |
डिवाइस को रजिस्ट्रेशन पूरा होने के बाद ही /privet/info API रिस्पॉन्स में अपना डिवाइस आईडी दिखाना होगा.
उदाहरण 1:
{ "action": "start", "user": "user@domain.com", }
उदाहरण 2:
{ "action": "getClaimToken", "user": "user@domain.com", "token": "AAA111222333444555666777", "claim_url": "https://domain.com/SoMeUrL", }
तीसरा उदाहरण:
{ "action": "complete", "user": "user@domain.com", "device_id": "11111111-2222-3333-4444-555555555555", }
4.3.3. गड़बड़ियां
/privet/रजिस्टर एपीआई इन गड़बड़ियों को दिखा सकता है (जानकारी के लिए गड़बड़ी सेक्शन देखें):कोई गड़बड़ी हुई | ब्यौरा |
---|---|
डिवाइस का_व्यस्त | डिवाइस व्यस्त है और अनुरोध की गई कार्रवाई नहीं कर सकता. टाइम आउट के बाद, फिर से कोशिश करें. |
Pending_user_action | "quot;getClaimToken" के जवाब में यह गड़बड़ी बताती है कि डिवाइस की उपयोगकर्ता की पुष्टि अब भी बाकी है. "getClaimToken" अनुरोध को फिर से टाइम आउट करने के बाद फिर से कोशिश करनी चाहिए. |
user_cancel. | उपयोगकर्ता ने डिवाइस से रजिस्ट्रेशन की प्रक्रिया साफ़ तौर पर रद्द कर दी है. |
पुष्टि करने का समय खत्म (टाइम आउट) | उपयोगकर्ता की पुष्टि का समय खत्म. |
अमान्य_कार्रवाई | अमान्य कार्रवाई को कॉल किया जाता है. उदाहरण के लिए, अगर क्लाइंट ने action=start और action=getClaimToken को कॉल करने से पहले action=complete कहा है. |
अमान्य_पैरामीटर | अनुरोध में डाले गए अमान्य पैरामीटर. (अज्ञात पैरामीटर भविष्य के संगत होने के लिए सुरक्षित रूप से अनदेखा किए जाने चाहिए.) उदाहरण के लिए, अगर क्लाइंट ने action=Unknown या user= को कॉल किया हो, तो इसे दिखाएं. |
device_config_error | डिवाइस की तरफ़, तारीख/समय (या दूसरी कुछ सेटिंग) गलत है. उपयोगकर्ता को डिवाइस की वेबसाइट पर जाना होगा और डिवाइस की सेटिंग कॉन्फ़िगर करनी होंगी. |
अॉफ़लाइन | फ़िलहाल, यह डिवाइस ऑफ़लाइन है और सर्वर से कनेक्ट नहीं हो सकता. |
Server_error | रजिस्ट्रेशन के दौरान सर्वर में गड़बड़ी हुई. |
अमान्य_x_privet_token | X-Privet-Token अनुरोध में अमान्य या खाली है. |
रजिस्ट्रेशन पूरा होने के बाद, डिवाइस को /privet/रजिस्टर एपीआई के बारे में बताना बंद करना होगा. अगर डिवाइस /privet/registration एपीआई को सार्वजनिक नहीं कर रहा है, तो यह ज़रूरी है कि इसमें एचटीटीपी 404 गड़बड़ी दिखे. इसलिए, अगर कोई डिवाइस पहले से रजिस्टर किया गया है, तो इस एपीआई को कॉल करने के लिए, 404 गड़बड़ी का मैसेज दिखाना ज़रूरी है. अगर X-Privet-Token हेडर मौजूद नहीं है, तो डिवाइस को एचटीटीपी 400 गड़बड़ी दिखानी चाहिए.
4.4. /privet/accesstoken एपीआई
/privet/accesstoken एपीआई ज़रूरी नहीं है. यह एचटीटीपी जीईटी अनुरोध है. /privet/accesstoken API के लिए मान्य और कोटेशन की जांच करनी चाहिए;X-Privet-Token" हेडर. डिवाइस को इस API को "/privet/accesstoken" यूआरएल पर लागू करना होगा:GET /privet/accesstoken HTTP/1.1
जब डिवाइस को /accesstoken API कॉल मिलता है, तो उसे सर्वर को कॉल करना चाहिए, ताकि वह उपयोगकर्ता को ऐक्सेस टोकन दे सके और क्लाइंट को टोकन लौटा सके. इसके बाद, क्लाइंट क्लाउड के ज़रिए इस डिवाइस को ऐक्सेस करने के लिए, ऐक्सेस टोकन का इस्तेमाल करेगा.
क्लाउड प्रिंट डिवाइस को इन एपीआई को कॉल करना होगा:
/cloudprint/proximitytokenस्थानीय एपीआई से लिया गया पैरामीटर और पास और कोट अगर यह सही से काम करता है, तो सर्वर के रिस्पॉन्स में यह ऑब्जेक्ट शामिल होगा:
"proximity_token": { "user": "user@domain.com", "token": "AAA111222333444555666777", "expires_in": 600 }Cloud Print डिवाइसों को "proximity_token" की वैल्यू को, लोकल /privet/accesstoken API कॉल के जवाब में पास करना होगा. अगर डिवाइस सभी पैरामीटर को पास कर सकता है, तो यह ज़्यादा फ़ायदेमंद है. इसमें ऐसे पैरामीटर भी शामिल हैं जिनके बारे में इस स्पेसिफ़िकेशन में नहीं बताया गया है.
4.4.1. इनपुट
/privet/accesstoken API में ये इनपुट पैरामीटर शामिल होते हैं:नाम | वैल्यू |
---|---|
उपयोगकर्ता | उस उपयोगकर्ता का ईमेल जो इस ऐक्सेस टोकन का इस्तेमाल करना चाहता था. अनुरोध में खाली हो सकता है. |
4.4.2. रिटर्न टिकट
/privet/accesstoken API इस डेटा को दिखाता है:मान का नाम | वैल्यू टाइप | ब्यौरा |
---|---|---|
टोकन | स्ट्रिंग | सर्वर से लौटाया गया ऐक्सेस टोकन |
उपयोगकर्ता | स्ट्रिंग | इनपुट पैरामीटर के समान उपयोगकर्ता. |
समयसीमा खत्म होने की तारीख [in_in] | int | इस टोकन की समय-सीमा खत्म होने तक सेकंड की संख्या. सर्वर से मिला और इस रिस्पॉन्स में पास किया गया है. |
उदाहरण:
{ "token": "AAA111222333444555666777", "user": "user@domain.com", "expires_in": 600 }
4.4.3. गड़बड़ियां
/privet/accesstoken एपीआई इन गड़बड़ियों को दिखा सकता है (जानकारी के लिए गड़बड़ियां सेक्शन देखें):कोई गड़बड़ी हुई | ब्यौरा |
---|---|
अॉफ़लाइन | फ़िलहाल, डिवाइस ऑफ़लाइन है. इसलिए, सर्वर से कनेक्ट नहीं हो पा रहा. |
access_dened | अपर्याप्त अधिकार. ऐक्सेस नामंजूर. डिवाइस को यह गड़बड़ी तब डालनी चाहिए, जब सर्वर ने अनुरोध साफ़ तौर पर अस्वीकार कर दिया हो. |
अमान्य_पैरामीटर | अनुरोध में डाले गए अमान्य पैरामीटर. (अज्ञात पैरामीटर भविष्य के संगत होने के लिए सुरक्षित रूप से अनदेखा किए जाने चाहिए.) उदाहरण के लिए, अगर क्लाइंट ने /accesstoken?user= या /accesstoken को कॉल किया हो. |
Server_error | सर्वर में गड़बड़ी. |
अमान्य_x_privet_token | अनुरोध में X-Privet-Token अमान्य है या खाली है. |
अगर डिवाइस /privet/accesstoken API को सार्वजनिक नहीं कर रहा है, तो यह ज़रूरी है कि वह एचटीटीपी 404 गड़बड़ी दिखाए. अगर X-Privet-Token हेडर मौजूद नहीं है, तो डिवाइस को एचटीटीपी 400 गड़बड़ी दिखानी चाहिए.
4.5. /privet/capability एपीआई
/privet/capabilities एपीआई ज़रूरी नहीं है. यह एचटीटीपी जीईटी अनुरोध है. /privet/capability API के लिए मान्य और "X-Privet-Token" हेडर की जांच ज़रूरी है. डिवाइस को इस एपीआई को "/privet/capabilities" यूआरएल पर लागू करना होगा:GET /privet/capabilities HTTP/1.1डिवाइस को /capabilities एपीआई कॉल मिलने पर, अगर डिवाइस चालू हो, तो अपडेट की गई क्षमताओं के बारे में जानने के लिए उसे सर्वर से संपर्क करना चाहिए. उदाहरण के लिए, अगर कोई प्रिंटर, क्लाउड प्रिंट सेवा के ज़रिए खुद को (जिसे स्थानीय रूप से मिलता है) प्रिंट जॉब पोस्ट करने की सुविधा देता है, तो उसे वे सुविधाएं देनी चाहिए जिन्हें क्लाउड प्रिंट सेवा ने लौटाया है. इस मामले में, 'क्लाउड प्रिंट' मूल प्रिंटर की क्षमताओं में बदलाव कर सकता है. ऐसा करने के लिए, हो सकता है कि प्रिंटर में कोई नई सुविधा जोड़ने से पहले प्रिंटर नई सुविधाएं जोड़ सके. सबसे सामान्य उदाहरण, काम करने वाले दस्तावेज़ की सूची है. अगर प्रिंटर ऑफ़लाइन है, तो उसे काम करने वाले दस्तावेज़ के प्रकार दिखाने चाहिए. हालांकि, अगर प्रिंटर ऑनलाइन है और Cloud Print के साथ रजिस्टर किया गया है, तो यह ज़रूरी है कि वह रिटर्न और कोट;*/*" के साथ काम करे. क्लाउड प्रिंट सेवा इस मामले में ज़रूरी कन्वर्ज़न करेगी. ऑफ़लाइन प्रिंटिंग के लिए, प्रिंटर को कम से कम "image/pwg-raster" फ़ॉर्मैट का इस्तेमाल करना ज़रूरी है.
4.5.1. इनपुट
/privet/capabilities एपीआई में ये इनपुट पैरामीटर होते हैं:नाम | वैल्यू |
---|---|
अॉफ़लाइन | (ज़रूरी नहीं) सिर्फ़ "ऑफ़लाइन=1" हो सकता है. इस मामले में, डिवाइस को ऑफ़लाइन इस्तेमाल के लिए, क्षमताएं देनी चाहिए (अगर वे "ऑनलाइन" क्षमताएं से अलग हैं). |
4.5.2. रिटर्न टिकट
/privet/capabilities एपीआई क्लाउड डिवाइस की जानकारी (CDD) JSON फ़ॉर्मैट में डिवाइस की क्षमताएं दिखाता है (जानकारी के लिए सीडीडी दस्तावेज़ देखें). जिन प्रिंटर को कम से कम इस्तेमाल करना ज़रूरी है उनकी सूची यहां दी गई है. उदाहरण के लिए, क्लाउड के साथ काम करने वाले ऐसे प्रिंटर जो फ़िलहाल ऑनलाइन है, वह कुछ ऐसा दिखा सकता है (कम से कम):{ "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": "*/*" } ] } }और जब यह सर्वर से डिसकनेक्ट होगा, तब यह दिख सकता है:
{ "version": "1.0", "printer": { "supported_content_type": [ { "content_type": "application/pdf", "min_version": "1.4" }, { "content_type": "image/pwg-raster" }, { "content_type": "image/jpeg" } ] } }
ध्यान दें: प्रिंटर, क्रम में काम करने वाले कॉन्टेंट टाइप को प्राथमिकता देते हैं. उदाहरण के लिए, ऊपर दिए गए नमूने में, प्रिंटर यह बताता है कि वह "application/pdf" डेटा और "image/pwg-raster" और "image/jpeg" को प्राथमिकता देता है. अगर संभव हो, तो क्लाइंट को प्रिंटर की प्राथमिकता का ध्यान रखना चाहिए (ज़्यादा जानकारी के लिए सीडीडी दस्तावेज़ देखें).
4.5.3. गड़बड़ियां
/privet/capabilities एपीआई इन गड़बड़ियों को दिखा सकता है (जानकारी के लिए गड़बड़ियों वाला सेक्शन देखें):कोई गड़बड़ी हुई | ब्यौरा |
---|---|
अमान्य_x_privet_token | X-Privet-Token अनुरोध में अमान्य या खाली है. |
अगर डिवाइस /privet/capabilities एपीआई नहीं दिखा रहा है, तो उसे एचटीटीपी 404 गड़बड़ी बताई जानी चाहिए. अगर X-Privet-Token हेडर मौजूद नहीं है, तो डिवाइस को एचटीटीपी 400 गड़बड़ी दिखानी चाहिए.
4.6. गड़बड़ियां
ऊपर दिए गए एपीआई के ज़रिए इस फ़ॉर्मैट में गड़बड़ियां मिलती हैं:मान का नाम | वैल्यू टाइप | ब्यौरा |
---|---|---|
गड़बड़ी | स्ट्रिंग | गड़बड़ी का टाइप (हर एपीआई के हिसाब से) |
जानकारी | स्ट्रिंग (ज़रूरी नहीं) | गड़बड़ी के बारे में ऐसी जानकारी जिसे उपयोगकर्ता ने पढ़ा हो. |
Server_api | स्ट्रिंग (ज़रूरी नहीं) | सर्वर की गड़बड़ी की स्थिति में, इस फ़ील्ड में सर्वर की जांच नहीं हो सकी. |
Server_code (सर्वर_कोड) | int (ज़रूरी नहीं) | सर्वर में गड़बड़ी होने पर, इस फ़ील्ड में वह गड़बड़ी कोड दिखता है जो सर्वर ने लौटाया है. |
Server_http_कोड | int (ज़रूरी नहीं) | सर्वर एचटीटीपी की गड़बड़ी होने पर, इस फ़ील्ड में एचटीटीपी गड़बड़ी कोड सर्वर दिखाया जाता है. |
टाइम आउट | int (ज़रूरी नहीं) | फिर से कोशिश करने से पहले, क्लाइंट को इंतज़ार करने के लिए सेकंड की संख्या (सिर्फ़ वापस पाने में होने वाली गड़बड़ियों के लिए). क्लाइंट के लिए, इस वैल्यू को बिना किसी तय क्रम के टाइम आउट करना ज़रूरी है. यह वैल्यू + 20% होनी चाहिए. |
अगर X-Privet-Token हेडर मौजूद नहीं है, तो सभी एपीआई को एचटीटीपी 400 से जुड़ी गड़बड़ी दिखनी चाहिए.
एचटीटीपी/1.1 400 X-Privet-Token हेडर मौजूद नहीं है.
उदाहरण 1:
{ "error": "server_error", "description": "Service unavailable", "server_api": "/submit", "server_http_code": 503 }
उदाहरण 2:
{ "error": "printer_busy", "description": "Printer is currently printing other job", "timeout": 15 }
5. प्रिंटर API
इस प्रोटोकॉल के साथ काम करने वाले डिवाइसों में से एक प्रिंटर है. इस तरह के डिवाइस पर काम करने वाले डिवाइस, प्रिंटर से जुड़ी खास सुविधाएं लागू कर सकते हैं. आम तौर पर, क्लाउड-रेडी प्रिंटर से प्रिंट करने के लिए, क्लाउड प्रिंट सर्वर का इस्तेमाल किया जा सकता है:
कुछ मामलों में, क्लाइंट को स्थानीय तौर पर दस्तावेज़ भेजना पड़ सकता है. इसकी ज़रूरत तब हो सकती है, जब क्लाइंट के पास Google आईडी न हो या वह क्लाउड प्रिंट सर्वर से बात न कर पा रहा हो. ऐसे मामले में, प्रिंट जॉब को प्रिंटर पर स्थानीय रूप से सबमिट किया जाएगा. ऐसा करने पर, प्रिंटर जॉब की सूची बनाने और कन्वर्ज़न के लिए, क्लाउड प्रिंट सेवा का इस्तेमाल करेगा. प्रिंटर, क्लाउड पर प्रिंट करने की सेवा पर सबमिट किए गए काम को फिर से पोस्ट करेगा. इसके बाद, वह अनुरोध करेगा, क्योंकि इसे क्लाउड से सबमिट किया गया था. इस प्रोसेस से, उपयोगकर्ता को सेवा की शर्तों (कन्वर्ज़न) और प्रिंट जॉब को मैनेज करने/ट्रैकिंग के लिए, ज़रूरत के हिसाब से अनुभव मिलेगा.
क्लाउड प्रिंट सेवा, कन्वर्ज़न को लागू करती है. इसलिए, प्रिंटर को ऐसे सभी फ़ॉर्मैट ("*/*") के साथ काम करने वाला विज्ञापन दिखाना चाहिए जो इस्तेमाल किए जा सकने वाले कॉन्टेंट की सूची में शामिल हैं:
{ "version": "1.0", "printer": { "supported_content_type": [ { "content_type": "image/pwg-raster" }, { "content_type": "*/*" } ] } }
कुछ मामलों में, पूरी तरह से ऑफ़लाइन होने पर समाधान की ज़रूरत होती है. प्रिंटर, इनपुट फ़ॉर्मैट की एक तय संख्या के हिसाब से ही काम करते हैं. इसलिए, क्लाइंट को दस्तावेज़ों को कुछ ऐसे फ़ॉर्मैट में बदलना होगा जो स्थानीय तौर पर काम करते हों.
इस एट्रिब्यूट में, सभी प्रिंटर के लिए ऑफ़लाइन प्रिंटिंग केस का कम से कम PWG Raster ("image/pwg-raster") फ़ॉर्मैट इस्तेमाल किया जाता है. प्रिंटर दूसरे फ़ॉर्मैट (उदाहरण के लिए, JPEG) के साथ काम कर सकता है. साथ ही, अगर कोई क्लाइंट इस फ़ॉर्मैट में काम करता है, तो वह उस फ़ॉर्मैट में दस्तावेज़ भेज सकता है. प्रिंटर को /capabilies एपीआई के ज़रिए काम करने वाले टाइप ज़रूर दिखाने चाहिए, उदाहरण के लिए:
{ "version": "1.0", "printer": { "supported_content_type": [ { "content_type": "image/pwg-raster" }, { "content_type": "image/jpeg" } ] } }क्लाइंट दो तरीकों से लोकल नेटवर्क पर प्रिंट करना शुरू कर सकता है.
आसान प्रिंटिंग - क्लाइंट, लोकल नेटवर्क पर दस्तावेज़ को /submitdoc API में भेजता है (job_id पैरामीटर तय किए बिना). सबमिट किए गए दस्तावेज़ को प्रिंट करने की डिफ़ॉल्ट सेटिंग का इस्तेमाल करके प्रिंट किया जाएगा. इसके लिए, आपको प्रिंट जॉब की स्थिति की ज़रूरत नहीं पड़ेगी. अगर प्रिंटर सिर्फ़ इस तरह की प्रिंटिंग के साथ काम करता है, तो उसे /privet /info एपीआई रिस्पॉन्स में सिर्फ़/submitdoc एपीआई का विज्ञापन करना होगा.
"api": [ "/privet/accesstoken", "/privet/capabilities", "/privet/printer/submitdoc", ]
बेहतर प्रिंटिंग - सबसे पहले क्लाइंट को अनुरोध में मान्य CJT जॉब टिकट के साथ /privet/printer/createjob एपीआई पर कॉल करके, प्रिंटर पर प्रिंट जॉब बनाना चाहिए. प्रिंटर को प्रिंट टिकट को मेमोरी में सेव करना होगा और जॉब_आईडी को क्लाइंट के पास वापस लाना होगा. इसके बाद, क्लाइंट /printer/submitdoc एपीआई को कॉल करेगा और पहले दिए गए job_id के बारे में बताएगा. उस समय, प्रिंटर प्रिंट होना शुरू हो जाएगा. क्लाइंट /privet/printer/jobstate एपीआई को कॉल करके, प्रिंट जॉब की स्थिति के लिए प्रिंटर को पोल करेगा.
एक से ज़्यादा क्लाइंट वाले एनवायरमेंट में, इस बात की कोई गारंटी नहीं है कि इस एपीआई को कैसे इस्तेमाल किया जाएगा. एक क्लाइंट के पास दूसरे क्लाइंट के /createjob->/submit डॉक कॉल के बीच /createjob को कॉल करने की सुविधा है. समय खत्म होने से जुड़ी संभावित समस्या दूर करने और बेहतर तरीके से काम करने के लिए, हमने यह सुझाव दिया है कि प्रिंटर पर छोटी प्रिंट जॉब की एक छोटी सूची बनाई जाए (कम से कम तीन से पांच):
- /createjob सूची में पहले उपलब्ध जगह को लेता है.
- नौकरी की अवधि (सूची में) कम से कम पांच मिनट होनी चाहिए.
- अगर सूची में मौजूद सभी जगहों की जानकारी हटा दी जाती है, तो सबसे पुरानी नौकरी को हटा दिया जाएगा और उसकी जगह एक नया विज्ञापन डाला जाएगा.
- अगर डिवाइस पर कोई प्रिंट जॉब अभी प्रिंट किया जा रहा है (आसान या बेहतर प्रिंटिंग), तो /submitdoc को स्थिति को व्यस्त दिखाकर, इस प्रिंट जॉब के लिए फिर से कोशिश करने का समय बताना चाहिए.
- अगर /submitdoc ऐसी नौकरी के बारे में बताता है जिसे सूची से हटा दिया गया है (बदलने या टाइम आउट होने की वजह से), तो प्रिंटर को अमान्य_print_job गड़बड़ी का मैसेज दिखाना चाहिए और क्लाइंट /createjob चरण की प्रोसेस के लिए फिर से कोशिश करेगा. क्लाइंट को फिर से कोशिश करने से पहले, पांच सेकंड तक रैंडम टाइम आउट का इंतज़ार करना होगा.
अगर मेमोरी कंस्ट्रेंट, डिवाइस पर एक से ज़्यादा ऐसी नौकरियों को सेव करने से रोकता है जिन्हें मंज़ूरी मिलना बाकी है, तो हो सकता है कि इसके लिए एक प्रिंट जॉब की सूची हो. हालांकि, इसे अब भी ऊपर दिए गए प्रोटोकॉल का पालन करना चाहिए. किसी गड़बड़ी को ठीक करने या गड़बड़ी होने पर, प्रिंटर को कम से कम पांच मिनट के लिए, नौकरी की स्थिति के बारे में जानकारी सेव करनी चाहिए. पूरी हो चुकी नौकरी की स्थितियों को सेव करने के लिए, कम से कम 10 लोगों की सूची होनी चाहिए. अगर आपको नौकरी के लिए और भी ऑफ़र सबमिट करने हैं, तो सबसे पुराना 5 मिनट का समय खत्म होने से पहले, उन्हें सूची से हटाया जा सकता है.
ध्यान दें: फ़िलहाल, क्लाइंट नौकरी की स्थिति के बारे में पोल करेंगे. आने वाले समय में, अगर प्रिंट जॉब की स्थिति में कोई बदलाव होता है, तो हम प्रिंटर को TXT डीएनएस सूचना भेज सकते हैं.
5.1. /privet/printer/createjob API
/privet/printer/createjob API वैकल्पिक है (ऊपर दिए गए आसान प्रिंटिंग देखें). यह एक एचटीटीपी पोस्ट अनुरोध है. /privet/printer/createjob API को मान्य "X-Privet-Token" हेडर की जांच करनी होगी. डिवाइस को इस एपीआई को "/privet/printer/createjob" यूआरएल पर लागू करना होगा:
POST /privet/printer/createjob HTTP/1.1{4/}
5.1.1. इनपुट
/privet/printer/createjob API में यूआरएल में कोई इनपुट पैरामीटर नहीं है. अनुरोध के मुख्य हिस्से में CJT फ़ॉर्मैट में प्रिंट जॉब टिकट का डेटा शामिल होना चाहिए.5.1.2. रिटर्न टिकट
/privet/printer/createjob API यह डेटा दिखाता है:मान का नाम | वैल्यू टाइप | ब्यौरा |
---|---|---|
जॉब_आईडी | स्ट्रिंग | नए बनाए गए प्रिंट जॉब का आईडी. |
समयसीमा खत्म होने की तारीख [in_in] | int | इस प्रिंट जॉब का कुल सेकंड मान्य है. |
उदाहरण:
{ "job_id": "123", "expires_in": 600 }
5.1.3. गड़बड़ियां
/privet/printer/createjob API ये गड़बड़ियां दिखा सकता है (जानकारी के लिए गड़बड़ियों वाला सेक्शन देखें):कोई गड़बड़ी हुई | ब्यौरा |
---|---|
अमान्य_टिकट | सबमिट किया गया प्रिंट टिकट अमान्य है. |
प्रिंटर_व्यस्त | प्रिंटर व्यस्त है और इस समय /createjob को प्रोसेस नहीं किया जा सकता. टाइम आउट के बाद, फिर से कोशिश करें. |
प्रिंटर_गड़बड़ी | प्रिंटर गड़बड़ी की स्थिति में है और उसे ठीक करने के लिए उपयोगकर्ता से इंटरैक्शन की ज़रूरत है. ब्यौरे में ज़्यादा जानकारी दी जानी चाहिए (उदाहरण के लिए, ट्रे 1" में पेपर पेपर). |
अमान्य_x_privet_token | X-Privet-Token अनुरोध में अमान्य या खाली है. |
अगर डिवाइस की जानकारी /privet/printer/createjob नहीं है, तो ज़रूरी है कि यह एचटीटीपी 404 गड़बड़ी दिखाए. अगर X-Privet-Token हेडर मौजूद नहीं है, तो डिवाइस को एचटीटीपी 400 गड़बड़ी दिखानी चाहिए.
5.2. /privet/printer/submitdoc एपीआई
स्थानीय नेटवर्क पर ऑफ़लाइन लागू करने के लिए /privet/printer/submitdoc एपीआई ज़रूरी है (ऑफ़लाइन या क्लाउड प्रिंट पर फिर से पोस्ट करना). यह एचटीटीपी पोस्ट अनुरोध है. /privet/printer/submitdoc API एक मान्य "X-Privet-Token" हेडर की जांच करने के लिए ज़रूरी है. डिवाइस को इस एपीआई को "/privet/printer/submitdoc" यूआरएल पर लागू करना होगा:POST /privet/printer/submitdoc HTTP/1.1/privet/printer/submitdoc API कॉल मिलने पर, प्रिंटर को प्रिंट करना शुरू कर देना चाहिए. अगर प्रिंट करना शुरू नहीं हो पा रहा है, तो फिर से कोशिश करने से पहले, गड़बड़ी प्रिंटर_व्यस्त और गड़बड़ी का टाइम आउट दिखाएं.
अगर प्रिंटर अपने इंटरनल बफ़र में पूरा डेटा सेव नहीं कर पाता है, तो उसे टीसीपी मैकेनिज़्म का इस्तेमाल करके, डेटा ट्रांसफ़र की प्रोसेस को धीमी करना चाहिए. ऐसा तब तक करना चाहिए, जब तक कि दस्तावेज़ का कोई हिस्सा प्रिंट नहीं हो जाता और बफ़र का कुछ हिस्सा फिर से उपलब्ध हो जाता है. (उदाहरण के लिए, प्रिंटर टीसीपी लेयर पर विंडो का साइज़=0 सेट कर सकता है, जिससे क्लाइंट को इंतज़ार करना पड़ेगा.)
प्रिंटर पर किसी दस्तावेज़ को सबमिट करने में काफ़ी समय लग सकता है. प्रिंट करने के दौरान, क्लाइंट को प्रिंटर की स्थिति और जॉब (बेहतर प्रिंटिंग) की स्थिति देखने की सुविधा होनी चाहिए. ऐसा करने के लिए, प्रिंटर को /privet/printer/submitdoc API कॉल को संसाधित करते समय क्लाइंट को/privet/info और /privet/printer/jobstate API को कॉल करने की अनुमति देनी होगी. हमारा सुझाव है कि सभी क्लाइंट को नया थ्रेड शुरू करने के लिए /privet/printer/submitdoc API कॉल का इस्तेमाल करना चाहिए, ताकि मुख्य थ्रेड, /privet/info और /privet/printer/jobstate API का इस्तेमाल करके, प्रिंटर और नौकरी की स्थितियां देख सके.
नोट: स्थानीय प्रिंट जॉब के पूरा होने या गर्भपात होने पर, सुझाव दिया जाता है और अकाउंटिंग और उपयोगकर्ता अनुभव के मकसद से /sort/submit इंटरफ़ेस में नौकरी की आखिरी स्थिति रिपोर्ट करने के लिए (इस खास निर्देश के आने वाले वर्शन में ज़रूरी होगा). पैरामीटर और "printerid", "title", "contentType" &"final_sym_state" ( (PrintJobState फ़ॉर्मैट में) ज़रूरी हैं, और "टिकट और टिकट का टिकट (जॉट फ़ॉर्मैट) का टिकट (कोट) का टिकट. ध्यान दें कि दिया गया PrintJobState तय किया गया होना चाहिए.जैसे, इसका टाइप 'हो गया' या 'AOBED' होना चाहिए. ABORTED होने की स्थिति में कोई वजह ज़रूर देनी चाहिए, ज़्यादा जानकारी के लिए JobState देखें. यह भी ध्यान रखें कि /sort/submit इंटरफ़ेस का इस्तेमाल करके, स्थानीय प्रिंट जॉब की जानकारी देना इसके खास निर्देशों में नहीं बताया गया है. ऐसा इसलिए किया गया है, क्योंकि इस सेक्शन का मकसद इंटरफ़ेस के बारे में जानकारी देना है. साथ ही, इसके मुख्य इस्तेमाल के बारे में बताने के लिए, दस्तावेज़ के साथ प्रिंट जॉब सबमिट करना होगा. इस फ़िल्टर को "content" पैरामीटर में दिया जाना चाहिए.
5.2.1. इनपुट
/privet/printer/submitdoc API में ये इनपुट पैरामीटर होते हैं:नाम | वैल्यू |
---|---|
जॉब_आईडी | (ज़रूरी नहीं) प्रिंट जॉब का आईडी. सामान्य प्रिंटिंग केस के लिए हटाया जा सकता है (ऊपर देखें). यह प्रिंटर की ओर से लौटाए गए प्रिंटर से मेल खाना चाहिए. |
user_name | (ज़रूरी नहीं) उपयोगकर्ता का नाम, जिसे आसानी से पढ़ा जा सके. यह तय नहीं है और इसे सिर्फ़ प्रिंट जॉब के एनोटेशन के लिए इस्तेमाल किया जाना चाहिए. अगर जॉब को क्लाउड प्रिंट सेवा पर फिर से पोस्ट किया जाता है, तो यह स्ट्रिंग क्लाउड प्रिंट जॉब के साथ अटैच होनी चाहिए. |
Client_name | (ज़रूरी नहीं) यह अनुरोध करने वाले क्लाइंट ऐप्लिकेशन का नाम. यह सिर्फ़ डिसप्ले के लिए है. अगर जॉब को क्लाउड प्रिंट सेवा पर फिर से पोस्ट किया जाता है, तो यह स्ट्रिंग क्लाउड प्रिंट जॉब से अटैच होनी चाहिए. |
जॉब_नाम | (ज़रूरी नहीं) प्रिंट जॉब का नाम रिकॉर्ड किया जाना चाहिए. अगर जॉब को क्लाउड प्रिंट सेवा पर फिर से पोस्ट किया जाता है, तो यह स्ट्रिंग क्लाउड प्रिंट जॉब के साथ अटैच होनी चाहिए. |
अॉफ़लाइन | (ज़रूरी नहीं) सिर्फ़ "ऑफ़लाइन=1" हो सकता है. इस मामले में, प्रिंटर को सिर्फ़ ऑफ़लाइन प्रिंट करना चाहिए (क्लाउड प्रिंट सर्वर पर फिर से पोस्ट नहीं करना चाहिए). |
अनुरोध के मुख्य हिस्से में प्रिंट करने के लिए, मान्य दस्तावेज़ होना चाहिए. "Content-Length" इसमें अनुरोध की सही लंबाई शामिल होनी चाहिए. "Content-Type" हेडर को MIME टाइप रिकॉर्ड करने के लिए सेट किया जाना चाहिए और CDD के किसी एक टाइप से मेल खाना चाहिए (जब तक कि सीडीडी न बताए और कोट;*/*").
क्लाइंट को हमारा सुझाव दिया जाता है कि वे एक मान्य उपयोगकर्ता नाम (या ईमेल), क्लाइंट का नाम और इस अनुरोध के साथ नौकरी का नाम बताएं. उन फ़ील्ड का इस्तेमाल सिर्फ़ यूज़र इंटरफ़ेस (यूआई) में किया जाता है, ताकि उपयोगकर्ता को बेहतर अनुभव मिल सके.
5.2.2. रिटर्न टिकट
/privet/printer/submitdoc API नीचे दिया गया डेटा दिखाता है:मान का नाम | वैल्यू टाइप | ब्यौरा |
---|---|---|
जॉब_आईडी | स्ट्रिंग | हाल ही में बनाई गई प्रिंट जॉब का आईडी (आसान प्रिंटिंग) या अनुरोध में बताया गया Job_id (बेहतर प्रिंटिंग). |
समयसीमा खत्म होने की तारीख [in_in] | int | इस प्रिंट जॉब का कुल सेकंड मान्य है. |
जॉब टाइप | स्ट्रिंग | सबमिट किए गए दस्तावेज़ का कॉन्टेंट टाइप. |
जॉब_साइज़ | int 64 बिट | प्रिंट डेटा का साइज़ बाइट में. |
जॉब_नाम | स्ट्रिंग | (ज़रूरी नहीं) इनपुट में वही नाम डालें जो इनपुट में दिया गया है (अगर कोई हो). |
उदाहरण:
{ "job_id": "123", "expires_in": 500, "job_type": "application/pdf", "job_size": 123456, "job_name": "My PDF document" }
5.2.3. गड़बड़ियां
/privet/printer/submitdoc API ये गड़बड़ियां दिखा सकता है (जानकारी के लिए गड़बड़ियों वाला सेक्शन देखें):कोई गड़बड़ी हुई | ब्यौरा |
---|---|
अमान्य_प्रिंट_नौकरी | अनुरोध में अमान्य/समय-सीमा खत्म हो चुकी नौकरी का आईडी है. टाइम आउट के बाद फिर से कोशिश करें. |
अमान्य_दस्तावेज़_प्रकार | MIME टाइप वाला प्रिंटर, प्रिंटर में काम नहीं करता. |
अमान्य_दस्तावेज़ | सबमिट किया गया दस्तावेज़ अमान्य है. |
document_too_large | दस्तावेज़ की लंबाई, तय किए गए साइज़ से ज़्यादा है. |
प्रिंटर_व्यस्त | प्रिंटर व्यस्त है और अभी दस्तावेज़ प्रोसेस नहीं किया जा सकता. टाइम आउट के बाद, फिर से कोशिश करें. |
प्रिंटर_गड़बड़ी | प्रिंटर गड़बड़ी की स्थिति में है और उसे ठीक करने के लिए उपयोगकर्ता से इंटरैक्शन की ज़रूरत है. ब्यौरे में ज़्यादा जानकारी दी जानी चाहिए (उदाहरण के लिए, ट्रे 1" में पेपर पेपर). |
अमान्य_पैरामीटर | अनुरोध में डाले गए अमान्य पैरामीटर. (जिन पैरामीटर के बारे में नहीं पता है उन्हें आने वाले समय के लिए सुरक्षित तरीके से अनदेखा किया जाना चाहिए) |
user_cancel. | उपयोगकर्ता ने डिवाइस से प्रिंट करने की प्रक्रिया को साफ़ तौर पर रद्द कर दिया है. |
Server_error | क्लाउड प्रिंट पर दस्तावेज़ पोस्ट नहीं किया जा सका. |
अमान्य_x_privet_token | X-Privet-Token अनुरोध में अमान्य या खाली है. |
अगर डिवाइस /privet/printer/submitdoc की जानकारी नहीं दिखा रहा है, तो उसे एचटीटीपी 404 की गड़बड़ी दिखानी चाहिए. अगर X-Privet-Token हेडर मौजूद नहीं है, तो डिवाइस को एचटीटीपी 400 गड़बड़ी दिखानी चाहिए.
ध्यान दें: /privet/printer/submitdoc API (एपीआई) को प्रिंटर साइड पर खास हैंडलिंग की ज़रूरत हो सकती है (क्योंकि बड़ी पेलोड अटैच होता है). कुछ मामलों में, प्रिंटर एचटीटीपी एचटीटीपी सर्वर को लागू और प्लैटफ़ॉर्म पर निर्भर करता है. यह एचटीटीपी गड़बड़ी दिखाने से पहले, सॉकेट को बंद कर सकता है. दूसरे मामलों में, प्रिंटर 503 गड़बड़ी दिखा सकता है ('Privet गड़बड़ी' के बजाय). प्रिंटर को Privet लौटाने की ज़्यादा से ज़्यादा कोशिश करनी चाहिए. हालांकि, 'Privet की खास बातें' लागू करने वाले हर क्लाइंट के पास socket Close (कोई एचटीटीपी गड़बड़ी नहीं) होनी चाहिए. साथ ही, /privet/printer/submitdoc एपीआई के लिए, एचटीटीपी गड़बड़ी के 503 मामलों को हैंडल किया जाना चाहिए. इस मामले में, क्लाइंट को इसे Privet "printer_व्यस्त" गड़बड़ी में "timeout" के तौर पर हैंडल करना चाहिए, जो 15 सेकंड में सेट होना चाहिए. बार-बार कोशिश करने से बचने के लिए, क्लाइंट कई बार कोशिश करने के बाद भी कोशिश करना बंद कर सकता है. जैसे, तीन.
5.3. /privet/printer/jobstate एपीआई
/privet/printer/jobstate API वैकल्पिक है (ऊपर दिए गए आसान प्रिंटिंग देखें). यह एचटीटीपी जीईटी अनुरोध है. /privet/printer/jobstate API (एपीआई) के लिए मान्य "X-Privet-Token" हेडर की जांच करना ज़रूरी है. डिवाइस को इस एपीआई को "/privet/printer/jobstate" यूआरएल पर लागू करना होगा:GET /privet/printer/jobstate HTTP/1.1प्रिंटर को /privet/printer/jobstate API कॉल मिलने पर, प्रिंटर को अनुरोध किए गए प्रिंट जॉब या valid_print_job गड़बड़ी की स्थिति देनी चाहिए.
5.3.1. इनपुट
/privet/printer/jobstate API में ये इनपुट पैरामीटर होते हैं:नाम | वैल्यू |
---|---|
जॉब_आईडी | स्थिति दिखाने के लिए, जॉब आईडी प्रिंट करें. |
5.3.2. रिटर्न टिकट
/privet/printer/jobstate API यह डेटा दिखाता है:मान का नाम | वैल्यू टाइप | ब्यौरा |
---|---|---|
जॉब_आईडी | स्ट्रिंग | वहां स्टेटस जॉब की जानकारी प्रिंट करें. |
राज्य | स्ट्रिंग | ड्राफ़्ट - डिवाइस पर प्रिंट जॉब बनाया गया है. अभी तक /privet/printer/submitdoc कॉल नहीं मिले हैं.
सूची में शामिल है - प्रिंट जॉब मिला और उसे प्रिंट किया गया. हालांकि, अभी तक प्रिंट करना शुरू नहीं हुआ है. in_progress - प्रिंट जॉब प्रिंट होने की प्रोसेस जारी है. रोका गया - प्रिंट जॉब रोक दिया गया है, लेकिन इसे मैन्युअल रूप से या अपने आप फिर से शुरू किया जा सकता है. हो गया - प्रिंट जॉब पूरा हो गया है. रद्द किया गया - प्रिंट जॉब विफल रहा. |
जानकारी | स्ट्रिंग | (ज़रूरी नहीं) प्रिंट जॉब की स्थिति के बारे में व्यक्ति का ब्यौरा. अगर स्थिति&की जानकारी बंद है या रद्द की गई है, तो अलग से जानकारी शामिल करें. सिमेंटिक_स्टेट फ़ील्ड आम तौर पर क्लाइंट को बेहतर और ज़्यादा जानकारी देता है. |
समयसीमा खत्म होने की तारीख [in_in] | int | इस प्रिंट जॉब का कुल सेकंड मान्य है. |
जॉब टाइप | स्ट्रिंग | (ज़रूरी नहीं) सबमिट किए गए दस्तावेज़ का कॉन्टेंट टाइप. |
जॉब_साइज़ | int 64 बिट | (ज़रूरी नहीं) प्रिंट डेटा का साइज़ बाइट में. |
जॉब_नाम | स्ट्रिंग | (ज़रूरी नहीं) इनपुट में वही नाम डालें जो इनपुट में दिया गया है (अगर कोई हो). |
Server_job_id | स्ट्रिंग | (ज़रूरी नहीं) सर्वर से लौटाए गए जॉब का आईडी (अगर नौकरी को क्लाउड प्रिंट सेवा पर पोस्ट किया गया है). ऑफ़लाइन प्रिंटिंग के लिए हटा दिया गया है. |
सिमैंटिक_स्टेट | JSON | (ज़रूरी नहीं) PrintJobState फ़ॉर्मैट में नौकरी के सिमेंटिक स्टेटस. |
उदाहरण (क्लाउड प्रिंट के ज़रिए रिपोर्ट करके प्रिंट करना):
{ "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" }
उदाहरण (ऑफ़लाइन प्रिंटिंग गड़बड़ी):
{ "job_id": "123", "state": "stopped", "description": "Out of paper", "expires_in": 100, "job_type": "application/pdf", "job_size": 123456, "job_name": "My PDF document" }
उदाहरण (प्रिंट जॉब को उपयोगकर्ता ने रद्द कर दिया):
{ "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 } }
उदाहरण (प्रिंट आउट होने की वजह से प्रिंट जॉब रोक दिया गया). डिवाइस की स्थिति पर ध्यान दें. डिवाइस की स्थिति के बारे में ज़्यादा जानकारी के लिए, क्लाइंट को /privet/info एपीआई कॉल करना होगा:
{ "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. गड़बड़ियां
/privet/printer/jobstate API (एपीआई) नीचे दी गई गड़बड़ियां दिखा सकता है (जानकारी के लिए गड़बड़ी सेक्शन देखें):कोई गड़बड़ी हुई | ब्यौरा |
---|---|
अमान्य_प्रिंट_नौकरी | अनुरोध में अमान्य/समय-सीमा खत्म हो चुकी नौकरी का आईडी दिया गया है. |
Server_error | प्रिंट जॉब का स्टेटस (क्लाउड प्रिंट पर पोस्ट किए गए प्रिंट जॉब के लिए) नहीं मिल सका. |
अमान्य_x_privet_token | X-Privet-Token अनुरोध में अमान्य या खाली है. |
अगर डिवाइस में /privet/printer/jobstate नहीं दिखाई जा रही है, तो इसे एचटीटीपी 404 की गड़बड़ी दिखानी चाहिए. अगर X-Privet-Token हेडर मौजूद नहीं है, तो डिवाइस को एचटीटीपी 400 गड़बड़ी दिखानी चाहिए.
6. आखिर में जोड़ी गई अलग से जानकारी
6.1. डिफ़ॉल्ट व्यवहार और सेटिंग
इस सेक्शन में, डिफ़ॉल्ट तौर पर की जाने वाली सभी कार्रवाइयों के बारे में बताया जाएगा. ये ऐसे डिवाइस हैं जिनके लिए, Privet के साथ काम करने वाले सभी डिवाइसों से हमें उम्मीद है.- प्रॉडक्ट के साथ मिलने वाले डिवाइस पर, सिर्फ़ /privet/info और /privet/register एपीआई काम करने चाहिए. दूसरे सभी एपीआई (उदाहरण के लिए, /privet/accesstoken, लोकल प्रिंटिंग) बंद होने चाहिए.
- रजिस्ट्रेशन के लिए, डिवाइस के साथ फ़िज़िकल इंटरैक्शन ज़रूरी है.
- उपयोगकर्ता को डिवाइस पर ऐक्सेस की पुष्टि करने के लिए, डिवाइस पर कोई कार्रवाई करने (जैसे, कोई बटन दबाना) की ज़रूरत होगी.
- उपयोगकर्ता के ऊपर बताई गई कार्रवाई करने के बाद, प्रिंटर को /cloudprint/रजिस्टर करने का अनुरोध भेजना चाहिए. जब तक कार्रवाई पूरी न हो जाए, तब तक इस अनुरोध को नहीं भेजा जाना चाहिए (क्रम 1 का डायग्राम देखें).
- अगर डिवाइस /privet/register अनुरोध (उदाहरण के लिए, ऊपर कार्रवाई पर प्रतीक्षा कर रहा है) को संसाधित कर रहा है, तो यह सभी अन्य /privet/register अनुरोधों को अस्वीकार कर देगा. इस मामले में, डिवाइस के लिए डिवाइस की_व्यस्त गड़बड़ी को दिखाना ज़रूरी है.
- डिवाइस को ऐसे /रजिस्टर करने के अनुरोध का समय खत्म हो जाना चाहिए जो 60 सेकंड में ऊपर बताई गई शारीरिक कार्रवाई का अनुरोध नहीं देता है. ऐसे में, डिवाइस को पुष्टिकरण_टाइम आउट गड़बड़ी देनी चाहिए.
- ज़रूरी नहीं: इन बातों का सुझाव दिया जाता है, लेकिन ये ज़रूरी नहीं हैं. इनसे, उपयोगकर्ता अनुभव को बेहतर बनाया जा सकता है:
- प्रिंटर यह बताने के लिए लाइट या स्क्रीन को फ़्लैश कर सकता है कि उपयोगकर्ता को रजिस्ट्रेशन की पुष्टि करने के लिए कोई कार्रवाई करनी है.
- प्रिंटर अपनी स्क्रीन पर यह बता सकता है कि ‘यह Google Cloud Print, उपयोगकर्ता ‘abc@def.com’ के लिए रजिस्टर किया जा रहा है - जारी रखने के लिए, OK दबाएं. यहां abc@def.com /register API कॉल का उपयोगकर्ता पैरामीटर है. इससे उपयोगकर्ता को यह साफ़ तौर पर पता चल जाएगा कि:
- यह रजिस्ट्रेशन का अनुरोध है, जिसकी पुष्टि वे कर रहे हैं
- अगर अनुरोध ट्रिगर नहीं किया गया है, तो क्या हो रहा है.
- प्रिंटर से पुष्टि करने के लिए शारीरिक कार्रवाई के अलावा (उदाहरण, 'ठीक है' बटन दबाएं', प्रिंटर उपयोगकर्ता को अनुरोध रद्द करने का बटन भी ऑफ़र कर सकता है (उदाहरण के लिए, 'अस्वीकार करने के लिए रद्द करें' दबाएं). ऐसा करने से ऐसे उपयोगकर्ता जिन्होंने 60 सेकंड से पहले टाइम आउट करने से पहले रजिस्ट्रेशन का अनुरोध ट्रिगर नहीं किया था. इस मामले में, डिवाइस के लिए user_cancel गड़बड़ी का मैसेज दिखाना ज़रूरी है.
- मालिकाना हक के ट्रांसफ़र से जुड़े अनुरोध:
- हो सकता है कि डिवाइस को क्लाउड सेवा से साफ़ तौर पर मिटाया गया हो.
- अगर डिवाइस सही तरीके से दिखता है, लेकिन /sort/printer (जीसीपी के लिए) कॉल की वजह से डिवाइस की जानकारी नहीं मिलती, तो वह डिफ़ॉल्ट (आउट-ऑफ़-द-बॉक्स) मोड में वापस आ जाएगी.
- अगर डिवाइस के क्रेडेंशियल अब काम नहीं करते हैं, तो यह डिफ़ॉल्ट रूप से, डिफ़ॉल्ट सर्वर पर रीडायरेक्ट होना चाहिए.
- लोकल फ़ैक्ट्री रीसेट करने के लिए, डिवाइस के क्रेडेंशियल मिटाना और इसे डिफ़ॉल्ट स्थिति पर सेट करना ज़रूरी है.
- वैकल्पिक: डिवाइस, क्रेडेंशियल को मिटाने और उसे डिफ़ॉल्ट मोड में रखने के लिए, एक मेन्यू आइटम दे सकता है.
- XMPP नोटिफ़िकेशन का समर्थन करने वाले डिवाइस में सर्वर को पिंग करना आवश्यक होना चाहिए. पिंग टाइम आउट को सर्वर से "local_settings" के ज़रिए कंट्रोल किया जा सकता है.
- डिवाइस, सिंक करने के लिए एक दिन में 24 घंटे से ज़्यादा एक बार, सर्वर के लिए सर्वर (/cloudprint/printer API) के साथ-साथ, XMPP पिंग के बारे में साफ़ तौर पर पिंग कर सकता है. हमारा सुझाव है कि आप जांच विंडो को 24 से 32 घंटे के अंदर किसी भी क्रम में लगाएं.
- ज़रूरी नहीं: हमारा सुझाव है कि क्लाउड प्रिंट डिवाइसों का इस्तेमाल करने के लिए, मैन्युअल तरीके (बटन) का इस्तेमाल न करें. इससे, उपयोगकर्ता को डिवाइस से नई प्रिंट जॉब की जांच करने की सुविधा मिलेगी. कुछ प्रिंटर में यह सुविधा पहले से मौजूद है.
- ज़रूरी नहीं. एंटरप्राइज़ प्रिंटर, लोकल डिस्कवरी को पूरी तरह से बंद कर सकते हैं. ऐसी स्थिति में, डिवाइस को सर्वर पर इन स्थानीय सेटिंग को अपडेट करना होगा. नई स्थानीय सेटिंग को खाली (सेटिंग) और "local_explorey" "false" का मतलब है कि इसे GCP सेवा से फिर से चालू किया जा सकता है.
6.1.2 डिफ़ॉल्ट रजिस्ट्रेशन डायग्राम
6.2. XSSI और XSRF के हमले और रोकथाम
इस सेक्शन में, डिवाइस पर XSSI और XSRF के हमलों की संभावना के बारे में बताया जाएगा. साथ ही, यह भी बताया जाएगा कि उनसे टोकन की सुरक्षा कैसे की जा सकती है. इसमें टोकन जनरेट करने की तकनीकें भी शामिल हैं.ज़्यादा जानकारी यहां देखें: http://googleonlinesecurity.blogspot.com/2011/05/website-security-for-webmasters.html
आम तौर पर, साइट पर कुकी की पुष्टि करने के तरीके इस्तेमाल करके, XSSI और XSRF पर हमला किया जा सकता है. हालांकि, Google अपनी क्लाउड प्रिंट सेवा के साथ कुकी का इस्तेमाल नहीं करता है, लेकिन इस तरह के सायबर हमले अब भी हो सकते हैं. स्थानीय नेटवर्क का ऐक्सेस, डिज़ाइन के मुताबिक, साफ़ तौर पर अनुरोधों पर भरोसा करता है.
6.2.1. XSSI
नुकसान पहुंचाने वाली वेबसाइट के लिए यह संभव है कि वह किसी आईपी पते और पोर्ट नंबर का अंदाज़ा लगाने के लिए किसी खास डिवाइस का इस्तेमाल करे. इसके अलावा, किसी &&t;script> टैग का इस्तेमाल करके Privet API को कॉल करने की कोशिश करें:<script type="text/javascript" src="http://192.168.1.42:8080/privet/info"></script>सुरक्षा के बिना, नुकसान पहुंचाने वाली वेबसाइटें एपीआई कॉल और उन नतीजों को ऐक्सेस कर सकती हैं.
इस तरह के हमले से बचने के लिए, सभी 'Privet API कॉल' अनुरोध में "X-Privet-Token" हेडर होना ज़रूरी है. "src=<api>" स्क्रिप्ट टैग हेडर जोड़ने में सक्षम नहीं हैं, जो इस प्रकार के हमलों से प्रभावी ढंग से सुरक्षा करते हैं.
6.2.2. एक्सएसआरएफ़
http://en.wikipedia.org/wiki/Cross-site_request_forgoryनुकसान पहुंचाने वाली वेबसाइट के लिए ऐसा हो सकता है कि वह किसी खास डिवाइस के आईपी पते और पोर्ट नंबर का अंदाज़ा लगा ले. इसके लिए, <iframe>, फ़ॉर्म या किसी दूसरे क्रॉस-वेबसाइट लोड करने के तरीके का इस्तेमाल करें. हमलावर, अनुरोध के नतीजे ऐक्सेस नहीं कर पाएंगे. हालांकि, अगर अनुरोध पर कोई कार्रवाई की जाती है, तो वे ट्रिगर कर सकते हैं.
इस हमले से बचने के लिए, हमें नीचे दी गई सुरक्षा की ज़रूरत है:
- /privet/info एपीआई को XSRF पर खोलें
- /privet/info एपीआई को डिवाइस पर कोई कार्रवाई नहीं करनी चाहिए
- x-privet-token पाने के लिए /privet/info API का इस्तेमाल करें
- अन्य सभी एपीआई को एक मान्य x-privet-token, और "X-Privet-Token" हेडर की जांच करनी होगी.
- x-Privet-token को सिर्फ़ 24 घंटे के लिए मान्य होना चाहिए.
भले ही कोई हमलावर /privet/info एपीआई को एक्ज़ीक्यूट न कर पाए, तो वह रिस्पॉन्स से x-privet-token को नहीं पढ़ सकेगा. इसलिए, वह किसी दूसरे एपीआई को कॉल नहीं कर पाएगा.
हमारा सुझाव है कि आप आगे दिए गए एल्गोरिदम का इस्तेमाल करके, XSRF टोकन जनरेट करें:
XSRF_token = base64( SHA1(device_secret + DELIMITER + issue_timecounter) + DELIMITER + issue_timecounter )
XSRF टोकन जनरेट करने वाले एलिमेंट:
- DELIMITER एक विशेष वर्ण है, आम तौर पर ‘:’
- समस्या_काउंटर, कुछ इवेंट (टाइमस्टैंप के लिए epoch) या डिवाइस के बूट होने के समय (सीपीयू काउंटर के लिए) के बाद से सेकंड की संख्या है. डिवाइस के चालू और चालू होने पर, issue_timecount लगातार बढ़ रहा है (नीचे टोकन की पुष्टि देखें).
- SHA1 - SHA1 एल्गोरिदम का इस्तेमाल करके, हैश फ़ंक्शन
- base64 - Base64 कोड में बदलने का तरीका
- device_सीकर - खास तौर पर डिवाइस के लिए सीक्रेट. डिवाइस सीक्रेट को हर रीस्टार्ट पर अपडेट किया जाना चाहिए.
डिवाइस सीक्रेट जनरेट करने के सुझाए गए तरीके:
- हर बार रीस्टार्ट होने पर एक नया UUID जनरेट करें
- हर बार रीस्टार्ट होने पर, एक 64 बिट नंबर जनरेट करें
डिवाइस को, जारी किए गए सभी XSRF टोकन सेव करने की ज़रूरत नहीं है. जब डिवाइस को मान्य होने के लिए किसी XSRF टोकन की पुष्टि करने की ज़रूरत हो, तो इसे टोकन को Base64-डिकोड करना चाहिए. दूसरे हिस्से से समस्या_काउंटर (साफ़ करने वाला टेक्स्ट) पाएं और device_सीक्रेट + + issue_timecount का SHA1 हैश जनरेट करने की कोशिश करें, जहां issue_timecount टोकन से है. अगर जनरेट किया गया नया SHA1, टोकन में दिए गए SHA1 से मेल खाता है, तो डिवाइस को अब यह देखना होगा कि समस्या_काउंटर मौजूदा समय वाले काउंटर की मान्य अवधि (24 घंटे) में है या नहीं. ऐसा करने के लिए, डिवाइस मौजूदा समय वाले काउंटर को (उदाहरण के लिए, सीपीयू का काउंटर) इस्तेमाल करता है और इससे issue_time मैं को घटा देता है. नतीजे में, टोकन से जुड़ी सेकंड की संख्या दिखनी चाहिए.
अहम जानकारी: यह XSRF सुरक्षा लागू करने का सुझाया गया तरीका है. Privet की खास बातें बताने वाले क्लाइंट, XSRF टोकन को समझने की कोशिश नहीं करेंगे. इसके बजाय, उन्हें ब्लैकबॉक्स माना जाएगा. इमेज 6.2.3 में, किसी खास अनुरोध में, X-Privet-Token और पुष्टि करने की सुविधा को लागू करने का सुझाया गया तरीका बताया गया है.