इस सेक्शन में, Fleet Engine के साथ इंटिग्रेशन करने के साथ-साथ पुष्टि करने और अनुमति देने के सिद्धांतों के बारे में बताया गया है.
आपके पास Google Cloud Console के ज़रिए, लास्ट माइल फ़्लीट सलूशन की सुविधाओं को कॉन्फ़िगर करने का विकल्प है. Fleet Engine SDK टूल को ऐसे JSON वेब टोकन (JWT) का इस्तेमाल करना ज़रूरी होता है जिन पर सही सेवा खाते से हस्ताक्षर किए गए हों.
खास जानकारी
Fleet Engine की पुष्टि और अनुमति देने वाले ग्राहक बैकएंड को, ऐप्लिकेशन के डिफ़ॉल्ट क्रेडेंशियल का इस्तेमाल करना चाहिए.
Fleet Engine को ऐसे कॉल भी मिलते हैं जो स्मार्टफ़ोन और ब्राउज़र जैसे लो-ट्रस्ट एनवायरमेंट से आते हैं. सेवा खाते की सीक्रेट कुंजियों की सुरक्षा के लिए जो भरोसेमंद प्लैटफ़ॉर्म पर काम करते हैं, उनसे उम्मीद की जाती है कि बैकएंड से, Fleet Engine के लिए अतिरिक्त दावों के साथ साइन किए गए JSON वेब टोकन (JWT) जनरेट किए जाएं. इनसे बाद में, मोबाइल फ़ोन जैसे गैर-भरोसेमंद प्लैटफ़ॉर्म को भेजे जा सकते हैं.
पुष्टि करने के लिए डिज़ाइन के सिद्धांत
Fleet Engine की पुष्टि करने की प्रोसेस में, डिज़ाइन से जुड़े इन सिद्धांतों को ध्यान में रखा गया है.
IAM रोल, किसी मुख्य खाते के लिए अनुमति पा चुके संसाधनों के लिए अनुमतियों का सेट तय करते हैं. उदाहरण के लिए, एडमिन की भूमिकाओं को ऐप्लिकेशन के डिफ़ॉल्ट क्रेडेंशियल के साथ सभी काम करने की अनुमति होती है, जबकि गैर-भरोसेमंद ड्राइवर* भूमिका को सिर्फ़ वाहन की जगह की जानकारी अपडेट करने की अनुमति होती है. साथ ही, यह भूमिका सिर्फ़ पुष्टि करने और अनुमति देने के लिए, JWT का इस्तेमाल करने तक सीमित होती है.
गैर-भरोसेमंद एनवायरमेंट के लिए, JWT दावा उन इकाइयों को ज़्यादा सीमित कर देता है जिन पर कॉलर ऑपरेट कर सकता है. ये चुनिंदा टास्क या डिलीवरी वाहन हो सकते हैं.
कम भरोसेमंद एनवायरमेंट में चल रहे आपके कोड को सबसे पहले, भरोसेमंद एनवायरमेंट में चल रहे आपके कोड पर कॉल करना होगा, ताकि जेडब्लयूटी जारी किया जा सके.
Fleet Engine, संसाधन के लिए एपीआई कॉल पर ये सुरक्षा जांच करता है:
संसाधन पर कार्रवाई करने के लिए, कॉल करने वाले मुख्य व्यक्ति के पास भूमिका असाइन करने के ज़रिए ज़रूरी अनुमतियां होती हैं.
गैर-एडमिन भूमिकाओं के लिए, अनुरोध में सबमिट किए गए JWT के दावे, संसाधन के लिए ज़रूरी अनुमति देते हैं.
पुष्टि करने का फ़्लो
नीचे दिए गए क्रम के डायग्राम में, पुष्टि करने की प्रोसेस की जानकारी दिखाई गई है.
फ़्लीट एडमिन, सेवा खाते बनाता है.
फ़्लीट एडमिन, सेवा खातों के लिए खास IAM भूमिकाएं असाइन करता है.
फ़्लीट एडमिन, सेवा खातों और ऐप्लिकेशन के डिफ़ॉल्ट क्रेडेंशियल के साथ अपने बैकएंड को कॉन्फ़िगर करता है.
क्लाइंट ऐप्लिकेशन, ग्राहक बैकएंड से JWT का अनुरोध करता है. अनुरोध करने वाला ड्राइवर ऐप्लिकेशन, उपभोक्ता ऐप्लिकेशन या निगरानी करने वाला ऐप्लिकेशन हो सकता है.
कस्टमर बैकएंड, संबंधित सेवा खाते के लिए JWT साइन करता और जारी करता है. क्लाइंट ऐप्लिकेशन को JWT मिलता है.
क्लाइंट ऐप्लिकेशन, डेटा पढ़ने या उसमें बदलाव करने के लिए, Fleet Engine से कनेक्ट करने के लिए JWT का इस्तेमाल करता है. यह डेटा, सेटअप के दौरान असाइन की गई IAM भूमिकाओं पर निर्भर करता है.
Cloud प्रोजेक्ट का सेटअप
अपना क्लाउड प्रोजेक्ट सेट अप करने के लिए, पहले अपना प्रोजेक्ट बनाएं. इसके बाद, सेवा खाते बनाएं.
Google Cloud प्रोजेक्ट बनाने के लिए:
- Google Cloud Console का इस्तेमाल करके, Google Cloud प्रोजेक्ट बनाएं.
- एपीआई और सेवा डैशबोर्ड का इस्तेमाल करके, Local Rides and डिलीवरी API को चालू करें.
सेवा खाते और IAM रोल
सेवा खाता एक खास तरह का खाता होता है, जिसका इस्तेमाल कोई व्यक्ति करने के बजाय कोई ऐप्लिकेशन करता है. आम तौर पर, सेवा खाते का इस्तेमाल JWT को मिंट करने के लिए किया जाता है, जो भूमिका के आधार पर अनुमतियों के अलग-अलग सेट देते हैं. गलत इस्तेमाल की संभावना को कम करने के लिए, कई सेवा खाते बनाए जा सकते हैं. हर खाते में, कम से कम ज़रूरी भूमिकाएं होनी चाहिए ().
लास्ट माइल फ़्लीट सलूशन इन भूमिकाओं का इस्तेमाल करता है:
| भूमिका | ब्यौरा |
|---|---|
फ़्लीट इंजन डिलीवरी करने वाले भरोसेमंद ड्राइवर का उपयोगकर्ता
roles/fleetengine.deliveryTrustedDriver |
डिलीवरी वाहन और टास्क बनाने और अपडेट करने की अनुमति देता है. इसमें डिलीवरी वाहन की जगह और टास्क का स्टेटस या नतीजा अपडेट करना भी शामिल है. इस भूमिका वाले सेवा खाते से बनाए गए टोकन आम तौर पर, डिलीवरी ड्राइवर के मोबाइल डिवाइसों या आपके बैकएंड सर्वर से इस्तेमाल किए जाते हैं. |
फ़्लीट इंजन डिलीवरी करने वाला गैर-भरोसेमंद ड्राइवर उपयोगकर्ता
roles/fleetengine.deliveryUntrustedDriver |
डिलीवरी वाहन की जगह की जानकारी अपडेट करने की अनुमति देता है. इस भूमिका वाले सेवा खाते से बनाए गए टोकन, आम तौर पर आपके डिलीवरी ड्राइवर के मोबाइल डिवाइसों से इस्तेमाल किए जाते हैं. |
फ़्लीट इंजन डिलीवरी उपभोक्ता उपयोगकर्ता
roles/fleetengine.deliveryConsumer |
ट्रैकिंग आईडी का इस्तेमाल करके टास्क खोजने और टास्क की जानकारी पढ़ने की अनुमति देता है, लेकिन उसे अपडेट नहीं करता. इस भूमिका वाले सेवा खाते से बनाए गए टोकन, आम तौर पर डिलीवरी उपभोक्ता के वेब ब्राउज़र से इस्तेमाल किए जाते हैं. |
फ़्लीट इंजन डिलीवरी एडमिन<>
roles/fleetengine.deliveryAdmin |
डिलीवरी संसाधनों के लिए पढ़ने और लिखने की अनुमति देता है. इस भूमिका वाले प्रिंसिपल को JWT का इस्तेमाल करने की ज़रूरत नहीं है. इसके बजाय, उन्हें ऐप्लिकेशन के डिफ़ॉल्ट क्रेडेंशियल का इस्तेमाल करना चाहिए. कस्टम JWT दावों को अनदेखा कर दिया जाता है. यह भूमिका भरोसेमंद एनवायरमेंट (कस्टमर बैकएंड) तक सीमित होनी चाहिए. |
roles/fleetengine.deliverySuperUser |
सभी डिलीवरी वाहनों और टास्क के एपीआई को अनुमति देता है. इस भूमिका वाले सेवा खाते से बनाए गए टोकन, आम तौर पर आपके बैकएंड सर्वर से इस्तेमाल किए जाते हैं. |
फ़्लीट इंजन डिलीवरी फ़्लीट रीडर
roles/fleetengine.deliveryFleetReader |
डिलीवरी वाहनों और टास्क को पढ़ने के साथ-साथ ट्रैकिंग आईडी का इस्तेमाल करके टास्क खोजने की अनुमति देता है. इस भूमिका वाले सेवा खाते से बनाए गए टोकन, आम तौर पर डिलीवरी फ़्लीट ऑपरेटर के वेब ब्राउज़र से इस्तेमाल किए जाते हैं. |
जो संगठन अपने डिलीवरी ड्राइवर को कॉर्पोरेट आईटी से मैनेज किए जाने वाले डिवाइस देते हैं वे फ़्लीट इंजन भरोसेमंद ड्राइवर उपयोगकर्ता की भूमिका से मिलने वाली सुविधाओं का फ़ायदा ले सकते हैं. साथ ही, वे मोबाइल ऐप्लिकेशन में कुछ या सभी फ़्लीट इंजन इंटरैक्शन को इंटिग्रेट कर सकते हैं.
Bring My Device से जुड़ी नीतियों के साथ काम करने वाले संगठनों को, फ़्लीट इंजन की गैर-भरोसेमंद ड्राइवर उपयोगकर्ता भूमिका की सुरक्षा के लिए ऑप्ट-इन करना चाहिए. साथ ही, Fleet Engine को वाहन की जगह की जानकारी से जुड़े अपडेट भेजने के लिए, सिर्फ़ मोबाइल ऐप्लिकेशन पर भरोसा करना चाहिए. अन्य सभी इंटरैक्शन, ग्राहक बैकएंड सर्वर से होने चाहिए.
ड्राइवर और उपभोक्ता के SDK टूल, इन स्टैंडर्ड भूमिकाओं के हिसाब से बनाए जाते हैं. हालांकि, कस्टम रोल बनाए जा सकते हैं, जो अनुमतियों के मनमुताबिक सेट को एक साथ बंडल करने की अनुमति देते हैं. ज़रूरी अनुमति उपलब्ध न होने पर, ड्राइवर और उपभोक्ता SDK टूल गड़बड़ी के मैसेज दिखाएंगे. इसलिए, हम सुझाव देते हैं कि आप कस्टम भूमिकाओं के बजाय, ऊपर बताई गई भूमिकाओं के स्टैंडर्ड सेट का इस्तेमाल करें.
सेवा खाता बनाना
Google Cloud Console में IAM & Admin > Service Accounts टैब का इस्तेमाल करके, सेवा खाता बनाया जा सकता है. भूमिका ड्रॉप-डाउन सूची से, फ़्लीट इंजन चुनें और सेवा खाते को कोई एक भूमिका असाइन करें. हर भूमिका से जुड़े खाते के बारे में बताना अच्छा तरीका है.
उदाहरण के लिए, सेवा खाते को ऐसा नाम दें जो समझ में आए.
सुविधा के लिए, अगर आपको गैर-भरोसेमंद क्लाइंट के लिए JWTs मिंट करने की ज़रूरत है, तो सेवा खाता टोकन क्रिएटर भूमिका में उपयोगकर्ताओं को जोड़ने से, वे gcloud कमांड लाइन टूल की मदद से टोकन मिंट कर सकते हैं.
gcloud projects add-iam-policy-binding project-id \
--member=user:my-user@example.com \
--role=roles/iam.serviceAccountTokenCreator
जहां my-user@example.com ईमेल पता है, जिसका इस्तेमाल gcloud (gcloud auth list
--format='value(account)') से पुष्टि करने के लिए किया जाता है.
फ़्लीट इंजन ऑथराइज़ेशन लाइब्रेरी
Fleet Engine, गैर-भरोसेमंद जगहों पर Fleet Engine API के ऐक्सेस को प्रतिबंधित करने के लिए, JWT का इस्तेमाल करता है. Fleet Engine Auth Library, GitHub पर उपलब्ध है. यह Fleet Engine JWT बनाने को आसान बनाती है और उन पर सुरक्षित तरीके से साइन करती है.
इस लाइब्रेरी से ये फ़ायदे मिलते हैं:
- फ़्लीट इंजन टोकन बनाने की प्रोसेस को आसान बनाता है.
- क्रेडेंशियल फ़ाइलों का इस्तेमाल करने के अलावा, टोकन पर हस्ताक्षर करने के दूसरे तरीके उपलब्ध कराता है (जैसे, किसी सेवा खाते के नाम पर काम करना.)
अनुमति देने के लिए JSON वेब टोकन (JWT) बनाया जा रहा है
फ़्लीट इंजन ऑथराइज़ेशन लाइब्रेरी का इस्तेमाल न करने पर, JWT को सीधे आपके कोड बेस में तैयार किया जाना चाहिए. इसके लिए, आपको JWT के बारे में अच्छी तरह समझना होगा. साथ ही, आपको यह भी समझना होगा कि ये Fleet Engine से कैसे जुड़े हैं. इसलिए, हम Fleet Engine ऑथराइज़ेशन लाइब्रेरी का इस्तेमाल करने का सुझाव देते हैं.
Fleet Engine में, JWTs कुछ समय तक पुष्टि की सुविधा देता है. साथ ही, यह पक्का करता है कि डिवाइस सिर्फ़ ऐसे वाहनों या टास्क में बदलाव कर सकें जिनके लिए उन्हें अनुमति मिली हुई है. JWT में एक हेडर और एक दावा सेक्शन होता है. हेडर सेक्शन में जानकारी शामिल होती है. जैसे, इस्तेमाल करने के लिए निजी पासकोड (सेवा खातों से मिलने वाली निजी कुंजी) और एन्क्रिप्ट (सुरक्षित) करने का एल्गोरिदम. दावे वाले सेक्शन में, टोकन बनाने का समय, टोकन के बनाए जाने का समय, टोकन की ओर से ऐक्सेस का दावा करने वाली सेवाओं, और ऐक्सेस को कम करने के लिए अनुमति से जुड़ी अन्य जानकारी शामिल होती है. उदाहरण के लिए, डिलीवरी वाहन का आईडी.JWT हेडर सेक्शन में ये फ़ील्ड होते हैं:
| फ़ील्ड | ब्यौरा |
|---|---|
| alg | इस्तेमाल किया जाने वाला एल्गोरिदम. `RS256`. |
| typ | टोकन किस तरह का है. `JWT`. |
| बच्चा | आपके सेवा खाते का निजी कुंजी आईडी. यह वैल्यू, आपके सेवा खाते की JSON फ़ाइल के `private_key_id` फ़ील्ड में देखी जा सकती है. पक्का करें कि उस सेवा खाते की कुंजी का इस्तेमाल किया जा रहा हो जिसके पास सही लेवल की अनुमतियां हैं. |
JWT के दावे वाले सेक्शन में ये फ़ील्ड होते हैं:
| फ़ील्ड | ब्यौरा |
|---|---|
| है | आपके सेवा खाते का ईमेल पता. |
| बदले में खेलने वाला खिलाड़ी | आपके सेवा खाते का ईमेल पता. |
| ऑड | आपके सेवा खाते का Service_NAME, इस मामले में https://fleetengine.googleapis.com/ |
| Iat | टोकन बनाए जाने के समय का टाइमस्टैंप, जिसे 1 जनवरी, 1970 को 00:00:00 यूटीसी के बाद, बीत चुके सेकंड में बताया गया है. स्क्यू के लिए 10 मिनट दें. अगर टाइमस्टैंप बहुत पहले का या आने वाले समय का है, तो सर्वर कोई गड़बड़ी रिपोर्ट कर सकता है. |
| exp | टोकन की समयसीमा खत्म होने के बाद का टाइमस्टैंप, जिसे 1 जनवरी, 1970 को 00:00:00 यूटीसी के बाद, बीत चुके सेकंड में बताया गया है. अगर टाइमस्टैंप के लिए, आने वाले समय के एक घंटे से ज़्यादा का समय है, तो अनुरोध पूरा नहीं किया जा सकता. |
| अनुमति देना | इस्तेमाल के उदाहरण के हिसाब से, इसमें `deliveryvehicleid`, `trackingid`, `taskid` या `taskids` हैं. |
JWT टोकन मिंट करने का मतलब है कि उस पर हस्ताक्षर करना. JWT बनाने और साइन करने के निर्देश और कोड सैंपल के लिए, OAuth के बिना सेवा खाते की अनुमति देना देखें. इसके बाद, gRPC कॉल में मिंट किया गया टोकन अटैच किया जा सकता है. इसके अलावा, Fleet Engine को ऐक्सेस करने के लिए इस्तेमाल किए जाने वाले अन्य तरीकों से भी ऐसा किया जा सकता है.
JWT दावे
लास्ट माइल फ़्लीट सलूशन, निजी दावों का इस्तेमाल करता है. निजी दावों का इस्तेमाल करने से यह पक्का होता है कि सिर्फ़ वे क्लाइंट ही अपना डेटा ऐक्सेस कर सकते हैं जिनको इसकी अनुमति है. उदाहरण के लिए, जब आपका बैकएंड, डिलीवरी ड्राइवर के मोबाइल डिवाइस के लिए JSON वेब टोकन जारी करता है, तो उस टोकन में deliveryvehicleid दावा होना चाहिए. साथ ही, उस टोकन में ड्राइवर के डिलीवरी वाले वाहन के आईडी की वैल्यू
शामिल होनी चाहिए. इसके बाद, ड्राइवर की भूमिका के आधार पर, टोकन से सिर्फ़ खास तौर पर डिलीवर किए जाने वाले वाहन के आईडी को ऐक्सेस किया जा सकता है, किसी अन्य आर्बिट्रेरी वाहन आईडी को नहीं.
लास्ट माइल फ़्लीट सलूशन, इन निजी दावों का इस्तेमाल करता है:
deliveryvehicleid- हर डिलीवरी-वाहन एपीआई को कॉल करते समय इस्तेमाल करें.taskid- हर टास्क वाले एपीआई को कॉल करते समय इस्तेमाल करें.taskids-BatchCreateTasksAPIको कॉल करते समय इस्तेमाल करें. यह दावा, अरे के तौर पर होना चाहिए. साथ ही, कलेक्शन में अनुरोध पूरा करने के लिए सभी ज़रूरी टास्क आईडी होने चाहिए.delivervehicleid,trackingidयाtaskidदावे शामिल न करें.trackingid- इसका इस्तेमाल,GetTaskTrackingInfoAPIपर कॉल करते समय करें. दावा, अनुरोध में मौजूद ट्रैकिंग आईडी से मेल खाना चाहिए.delivervehicleid,taskidयाtaskidsदावे शामिल न करें.
अपने बैकएंड सर्वर से एपीआई को कॉल करते समय, टोकन में सही दावा होना चाहिए. हालांकि, deliveryvehicleid, taskid, और trackingid दावों के लिए, स्टार के निशान ("*") की खास वैल्यू का इस्तेमाल किया जा सकता है. taskids दावे में भी तारे के निशान
("*") का इस्तेमाल किया जा सकता है, लेकिन अरे में यही एलिमेंट होना चाहिए.
अगर आपको OAuth 2.0 ऐक्सेस टोकन के बजाय, सीधे टोकन बियरर के तौर पर JSON बनाना है और उस पर हस्ताक्षर करना है, तो Identity डेवलपर के दस्तावेज़ में, OAuth के बिना सेवा खाते की अनुमति देना के लिए दिए गए निर्देश पढ़ें.
किसी gRPC कॉल में टोकन को अटैच करने का तरीका, कॉल करने के लिए इस्तेमाल की गई भाषा और फ़्रेमवर्क पर निर्भर करता है. किसी एचटीटीपी कॉल में टोकन तय करने की प्रोसेस में, एक बियरर टोकन के साथ ऑथराइज़ेशन हेडर शामिल करना होता है. इस टोकन की वैल्यू टोकन होती है. यह जानकारी, अलग-अलग शिपमेंट ट्रैकिंग या फ़्लीट परफ़ॉर्मेंस के इस्तेमाल के उदाहरणों के लिए, अनुमति वाले नोट में दी गई है.
नीचे दिया गया उदाहरण आपके बैकएंड सर्वर से, हर टास्क के लिए एक टोकन दिखाता है:
{
"alg": "RS256",
"typ": "JWT",
"kid": "private_key_id_of_provider_service_account"
}
.
{
"iss": "provider@yourgcpproject.iam.gserviceaccount.com",
"sub": "provider@yourgcpproject.iam.gserviceaccount.com",
"aud": "https://fleetengine.googleapis.com/",
"iat": 1511900000,
"exp": 1511903600,
"authorization": {
"taskid": "*"
}
}
नीचे दिया गया उदाहरण आपके बैकएंड सर्वर से, टास्क बनाने की कार्रवाई के बैच के लिए टोकन दिखाता है:
{
"alg": "RS256",
"typ": "JWT",
"kid": "private_key_id_of_provider_service_account"
}
.
{
"iss": "provider@yourgcpproject.iam.gserviceaccount.com",
"sub": "provider@yourgcpproject.iam.gserviceaccount.com",
"aud": "https://fleetengine.googleapis.com/",
"iat": 1511900000,
"exp": 1511903600,
"authorization": {
"taskids": ["*"]
}
}
इस उदाहरण में, आपके बैकएंड सर्वर से हर वाहन की डिलीवरी के लिए टोकन दिखाया गया है:
{
"alg": "RS256",
"typ": "JWT",
"kid": "private_key_id_of_provider_service_account"
}
.
{
"iss": "provider@yourgcpproject.iam.gserviceaccount.com",
"sub": "provider@yourgcpproject.iam.gserviceaccount.com",
"aud": "https://fleetengine.googleapis.com/",
"iat": 1511900000,
"exp": 1511903600,
"authorization": {
"deliveryvehicleid": "*"
}
}
यहां दिए गए उदाहरण में, असली उपयोगकर्ता के ग्राहकों के लिए टोकन दिखाया गया है:
{
"alg": "RS256",
"typ": "JWT",
"kid": "private_key_id_of_delivery_consumer_service_account"
}
.
{
"iss": "consumer@yourgcpproject.iam.gserviceaccount.com",
"sub": "consumer@yourgcpproject.iam.gserviceaccount.com",
"aud": "https://fleetengine.googleapis.com/",
"iat": 1511900000,
"exp": 1511903600,
"authorization": {
"trackingid": "shipment_12345"
}
}
नीचे दिया गया उदाहरण आपके ड्राइवर ऐप्लिकेशन के लिए टोकन दिखाता है:
{
"alg": "RS256",
"typ": "JWT",
"kid": "private_key_id_of_delivery_driver_service_account"
}
.
{
"iss": "driver@yourgcpproject.iam.gserviceaccount.com",
"sub": "driver@yourgcpproject.iam.gserviceaccount.com",
"aud": "https://fleetengine.googleapis.com/",
"iat": 1511900000,
"exp": 1511903600,
"authorization": {
"deliveryvehicleid": "driver_12345"
}
}
- हेडर में मौजूद
kidफ़ील्ड के लिए, अपने सेवा खाते का निजी कुंजी आईडी तय करें. आपको यह वैल्यू अपने सेवा खाते की JSON फ़ाइल केprivate_key_idफ़ील्ड में दिखेगी. issऔरsubफ़ील्ड के लिए, अपने सेवा खाते का ईमेल पता बताएं. आपको यह वैल्यू अपने सेवा खाते की JSON फ़ाइल केclient_emailफ़ील्ड में दिखेगी.audफ़ील्ड के लिए, https://SERVICE_NAME/ बताएं.iatफ़ील्ड के लिए, टोकन बनाए जाने के समय का टाइमस्टैंप बताएं. यह टाइमस्टैंप 1 जनवरी, 1970 को 00:00:00 यूटीसी के बाद 00:00:00 सेकंड के बाद का है. स्क्वी के लिए 10 मिनट दें. अगर टाइमस्टैंप बहुत पहले का या आने वाले समय का है, तो सर्वर कोई गड़बड़ी रिपोर्ट कर सकता है.expफ़ील्ड के लिए, 1 जनवरी, 1970 को 00:00:00 यूटीसी से 00:00:00 यूटीसी के बाद, टोकन की समयसीमा खत्म होने के टाइमस्टैंप की जानकारी दें. सुझाई गई वैल्यूiat+ 3600 है.
किसी मोबाइल डिवाइस या असली उपयोगकर्ता को भेजे जाने वाले टोकन पर हस्ताक्षर करते समय, पक्का करें कि डिलीवरी ड्राइवर या उपभोक्ता की भूमिका के लिए क्रेडेंशियल फ़ाइल का इस्तेमाल किया गया हो. ऐसा न होने पर, मोबाइल डिवाइस या असली उपयोगकर्ता उस जानकारी में बदलाव कर सकते हैं या देख पाएंगे जिसका ऐक्सेस उनके पास नहीं होना चाहिए.