Google Drive में मौजूद हर फ़ाइल, फ़ोल्डर, और शेयर की गई ड्राइव से permissions संसाधन जुड़े होते हैं. हर संसाधन, किसी खास type (user, group, domain, anyone) और role (owner, organizer, fileOrganizer, writer, commenter, reader) के लिए अनुमति की पहचान करता है. उदाहरण के लिए, किसी फ़ाइल के लिए ऐसी अनुमति हो सकती है जो किसी खास उपयोगकर्ता (type=user) को सिर्फ़ पढ़ने का ऐक्सेस (role=reader) देती है. वहीं, दूसरी अनुमति किसी खास ग्रुप (type=group) के सदस्यों को फ़ाइल में टिप्पणियां जोड़ने की सुविधा (role=commenter) देती है.
भूमिकाओं और उनसे जुड़ी अनुमतियों की पूरी सूची देखने के लिए, भूमिकाएं और अनुमतियां लेख पढ़ें.
अनुमतियां कैसे लागू होती हैं
किसी फ़ोल्डर के लिए अनुमतियों की सूचियां, नीचे की ओर बढ़ती हैं. सभी चाइल्ड फ़ाइलों और फ़ोल्डर को पैरंट फ़ोल्डर से अनुमतियां मिलती हैं. जब भी अनुमतियों या हैरारकी में बदलाव किया जाता है, तो यह बदलाव सभी नेस्ट किए गए फ़ोल्डर में अपने-आप लागू हो जाता है. उदाहरण के लिए, अगर कोई फ़ाइल किसी फ़ोल्डर में मौजूद है और उस फ़ोल्डर को किसी दूसरे फ़ोल्डर में ट्रांसफ़र किया जाता है, तो नए फ़ोल्डर की अनुमतियां उस फ़ाइल पर लागू हो जाती हैं. अगर नए फ़ोल्डर में, फ़ाइल के उपयोगकर्ता को कोई नई भूमिका दी जाती है, जैसे कि "लेखक", तो यह उसकी पुरानी भूमिका की जगह ले लेती है.
इसके उलट, अगर किसी फ़ाइल को किसी फ़ोल्डर से role=writer की भूमिका मिलती है और उसे किसी ऐसे फ़ोल्डर में ले जाया जाता है जो "पढ़ने वाले" की भूमिका देता है, तो अब फ़ाइल को role=reader की भूमिका मिलती है.
किसी भी आइटम के लिए, पहले से मिले ऐक्सेस की अनुमतियां हटाई या कम नहीं की जा सकतीं. इसके बजाय, इन अनुमतियों को उस पैरंट फ़ोल्डर में अडजस्ट किया जाना चाहिए जहां से ये मिली हैं. इसके अलावा, फ़ोल्डर के क्रम में मौजूद किसी फ़ोल्डर में सीमित ऐक्सेस की सेटिंग चालू की जानी चाहिए.
किसी आइटम के लिए, सामान्य तरीके से मिली अनुमतियों को बढ़ाया जा सकता है. अगर किसी बच्चे के लिए अनुमति बढ़ा दी जाती है, तो माता-पिता के लिए अनुमति बदलने से बच्चे की अनुमति पर कोई असर नहीं पड़ता. ऐसा तब तक होता है, जब तक माता-पिता के लिए नई अनुमति, बच्चे के लिए अनुमति से ज़्यादा न हो.
एक ही फ़ाइल, फ़ोल्डर या शेयर की गई ड्राइव के लिए, एक साथ अनुमतियों में बदलाव करने की सुविधा उपलब्ध नहीं है. यह सीमा, सभी म्यूटेटिंग कार्रवाइयों (जैसे कि अपडेट या मिटाना) पर लागू होती है. इससे कोई फ़र्क़ नहीं पड़ता कि एक ही व्यक्ति या अलग-अलग लोगों के लिए अनुमतियों में बदलाव किया जा रहा है. साथ ही, इससे भी कोई फ़र्क़ नहीं पड़ता कि अनुरोध किसी एक ऐप्लिकेशन से किया जा रहा है या कई उपयोगकर्ताओं से.
Drive, किसी आइटम के लिए अनुमतियों का आकलन करता है और उन्हें एक ही एसीएल के तौर पर अपडेट करता है. एक साथ कई कार्रवाइयां करने से, रेस कंडीशन पैदा होती हैं. इनमें "आखिरी बार किए गए बदलाव लागू होते हैं."
इससे अनुमति में किए गए बदलाव चुपचाप बदल सकते हैं या sharingRateLimitExceeded
गड़बड़ियां ट्रिगर हो सकती हैं. विरोध से बचने के लिए, एक ही आइटम पर अनुमतियों में बदलाव एक के बाद एक करें या बैच अनुरोधों का इस्तेमाल करें.
फ़ाइल के लिंक और ऐक्सेस कंट्रोल
किसी फ़ाइल या फ़ोल्डर को किसी उपयोगकर्ता या ग्रुप के साथ शेयर करने पर, उसे ऐक्सेस करने का यूआरएल नहीं बदलता. साथ ही, हर उपयोगकर्ता के लिए यूनीक लिंक जनरेट नहीं होता.
इसके बजाय, आइटम का एक ही लिंक होता है, जो उसके fileId के आधार पर तय होता है.
Drive, आइटम के ACL का आकलन करके ऐक्सेस को कंट्रोल करता है. जब कोई उपयोगकर्ता किसी लिंक को खोलने की कोशिश करता है, तो Drive, एसीएल के हिसाब से उसकी पुष्टि की गई पहचान की पुष्टि करता है. अगर किसी अनुमति को रद्द कर दिया जाता है या उसकी समयसीमा खत्म हो जाती है, तो उपयोगकर्ता को एसीएल से हटा दिया जाता है. अगर उपयोगकर्ता लिंक पर फिर से जाने की कोशिश करता है, तो Drive उसे ऐक्सेस करने की अनुमति नहीं देता.
फ़ाइल की क्षमताओं के बारे में जानकारी
permissions संसाधन से यह तय नहीं होता कि मौजूदा उपयोगकर्ता किसी फ़ाइल या फ़ोल्डर पर कार्रवाइयां कर सकता है या नहीं.
इसके बजाय, files संसाधन में बूलियन capabilities फ़ील्ड का कलेक्शन होता है. इनका इस्तेमाल यह बताने के लिए किया जाता है कि किसी फ़ाइल या फ़ोल्डर पर कोई कार्रवाई की जा सकती है या नहीं.
Google Drive API, इन फ़ील्ड को मौजूदा उपयोगकर्ता के permissions
संसाधन के आधार पर सेट करता है. यह संसाधन, फ़ाइल या फ़ोल्डर से जुड़ा होता है.
उदाहरण के लिए, जब ऐलेक्स आपके ऐप्लिकेशन में लॉग इन करता है और कोई फ़ाइल शेयर करने की कोशिश करता है, तो फ़ाइल पर ऐलेक्स की भूमिका की अनुमतियों की जांच की जाती है. अगर भूमिका के हिसाब से, किसी व्यक्ति को फ़ाइल शेयर करने की अनुमति है, तो फ़ाइल से जुड़ी capabilities, जैसे कि canShare, भूमिका के हिसाब से सेट की जाती हैं. अगर ऐलेक्स को फ़ाइल शेयर करनी है, तो आपका ऐप्लिकेशन capabilities की जांच करता है. इससे यह पक्का किया जाता है कि canShare को true पर सेट किया गया है.
फ़ाइल से जुड़ी सुविधाएं पाना
जब आपका ऐप्लिकेशन कोई फ़ाइल खोलता है, तो उसे फ़ाइल की क्षमताओं की जांच करनी चाहिए. साथ ही, मौजूदा उपयोगकर्ता की अनुमतियों को दिखाने के लिए यूज़र इंटरफ़ेस (यूआई) रेंडर करना चाहिए. उदाहरण के लिए, अगर उपयोगकर्ता के पास फ़ाइल पर canComment की सुविधा नहीं है, तो यूज़र इंटरफ़ेस (यूआई) में टिप्पणी करने की सुविधा बंद होनी चाहिए.
सुविधाओं की जांच करने के लिए, files रिसॉर्स पर get तरीके को कॉल करें. इसके लिए, fileId पाथ पैरामीटर और fields पैरामीटर को capabilities फ़ील्ड पर सेट करें. fields पैरामीटर का इस्तेमाल करके फ़ील्ड वापस पाने के बारे में ज़्यादा जानने के लिए, चुनिंदा फ़ील्ड वापस पाना लेख पढ़ें.
यहां दिए गए कोड के सैंपल में, उपयोगकर्ता की अनुमतियों की पुष्टि करने का तरीका बताया गया है. जवाब में, उन सुविधाओं की सूची मिलती है जिनका इस्तेमाल उपयोगकर्ता फ़ाइल पर कर सकता है. हर सुविधा, किसी ऐसी कार्रवाई से जुड़ी होती है जिसे उपयोगकर्ता कर सकता है. कुछ फ़ील्ड में सिर्फ़ शेयर की गई ड्राइव में मौजूद आइटम के लिए डेटा भरा जाता है.
अनुरोध
GET https://www.googleapis.com/drive/v3/files/FILE_ID?fields=capabilitiesजवाब
{ "capabilities": { "canAcceptOwnership": false, "canAddChildren": false, "canAddMyDriveParent": false, "canChangeCopyRequiresWriterPermission": true, "canChangeItemDownloadRestriction": true, "canChangeSecurityUpdateEnabled": false, "canComment": true, ... } }
Drive के संसाधन शेयर करने के उदाहरण
शेयर करने के पांच अलग-अलग तरीके होते हैं:
'मेरी ड्राइव' में मौजूद किसी फ़ाइल को शेयर करने के लिए, उपयोगकर्ता के पास
role=writerयाrole=ownerका ऐक्सेस होना चाहिए.अगर फ़ाइल के लिए,
writersCanShareबूलियन वैल्यू कोfalseपर सेट किया गया है, तो उपयोगकर्ता के पासrole=ownerहोना चाहिए.अगर
role=writerवाले उपयोगकर्ता के पास कुछ समय के लिए ऐक्सेस है और यह खत्म होने की तारीख और समय से नियंत्रित होता है, तो वह फ़ाइल शेयर नहीं कर सकता. ज़्यादा जानकारी के लिए, आइटम के ऐक्सेस को सीमित करने के लिए, उसके खत्म होने की तारीख सेट करना लेख पढ़ें.
'मेरी ड्राइव' में मौजूद किसी फ़ोल्डर को शेयर करने के लिए, उपयोगकर्ता के पास
role=writerयाrole=ownerका ऐक्सेस होना चाहिए.अगर फ़ाइल के लिए
writersCanShareबूलियन वैल्यू कोfalseपर सेट किया गया है, तो उपयोगकर्ता के पास ज़्यादा अनुमति वालीrole=ownerहोनी चाहिए.अस्थायी ऐक्सेस (ऐक्सेस खत्म होने की तारीख और समय से नियंत्रित) सिर्फ़
role=readerवाले फ़ोल्डर के लिए दिया जा सकता है. ज़्यादा जानकारी के लिए, आइटम के ऐक्सेस को सीमित करने के लिए, समयसीमा खत्म होने की तारीख सेट करना लेख पढ़ें.
शेयर की गई ड्राइव में कोई फ़ाइल शेयर करने के लिए, उपयोगकर्ता के पास
role=writer,role=fileOrganizerयाrole=organizerका ऐक्सेस होना चाहिए.writersCanShareसेटिंग, शेयर की गई ड्राइव में मौजूद आइटम पर लागू नहीं होती. इसे इस तरह से माना जाता है कि यह हमेशाtrueपर सेट होता है.
शेयर की गई ड्राइव में किसी फ़ोल्डर को शेयर करने के लिए, उपयोगकर्ता के पास
role=organizerहोना चाहिए.- अगर किसी शेयर की गई ड्राइव पर
sharingFoldersRequiresOrganizerPermissionपाबंदीfalseपर सेट है, तोrole=fileOrganizerकी अनुमति वाले उपयोगकर्ता उस शेयर की गई ड्राइव में फ़ोल्डर शेयर कर सकते हैं.
- अगर किसी शेयर की गई ड्राइव पर
शेयर की गई ड्राइव की सदस्यता मैनेज करने के लिए, उपयोगकर्ता के पास
role=organizerहोना चाहिए. सिर्फ़ उपयोगकर्ता और ग्रुप, शेयर की गई ड्राइव के सदस्य हो सकते हैं.
फ़ील्ड पैरामीटर का इस्तेमाल करना
अगर आपको जवाब में दिखाए जाने वाले फ़ील्ड तय करने हैं, तो permissions रिसॉर्स के किसी भी तरीके के साथ fields सिस्टम पैरामीटर सेट किया जा सकता है. fields पैरामीटर को शामिल न करने पर, सर्वर उस तरीके के लिए फ़ील्ड का डिफ़ॉल्ट सेट दिखाता है.
उदाहरण के लिए, list तरीके से, हर फ़ाइल के लिए सिर्फ़ id, type, kind, और role फ़ील्ड दिखते हैं. अलग-अलग फ़ील्ड वापस पाने के लिए, चुनिंदा फ़ील्ड वापस पाना लेख पढ़ें.
अनुमति बनाना
अनुमति बनाते समय, इन दो फ़ील्ड में जानकारी डालना ज़रूरी है:
type:typeसे अनुमति के स्कोप (user,group,domainयाanyone) की पहचान होती है.type=userवाली अनुमति किसी खास उपयोगकर्ता पर लागू होती है, जबकिtype=domainवाली अनुमति किसी खास डोमेन के सभी लोगों पर लागू होती है.role:roleफ़ील्ड से उन कार्रवाइयों के बारे में पता चलता है जिन्हेंtypeकर सकता है. उदाहरण के लिए,type=userऔरrole=readerवाली अनुमति से, किसी उपयोगकर्ता को फ़ाइल या फ़ोल्डर का सिर्फ़ पढ़ने का ऐक्सेस मिलता है. इसके अलावा,type=domainऔरrole=commenterवाली अनुमति से, डोमेन में मौजूद सभी लोग किसी फ़ाइल में टिप्पणियां जोड़ सकते हैं. भूमिकाओं और हर भूमिका के लिए अनुमति वाली कार्रवाइयों की पूरी सूची देखने के लिए, भूमिकाएं और अनुमतियां लेख पढ़ें.
type=user या type=group वाली अनुमति बनाते समय, आपको emailAddress भी देना होगा, ताकि किसी उपयोगकर्ता या ग्रुप को अनुमति से जोड़ा जा सके.
जब type=domain वाली अनुमति बनाई जाती है, तब आपको domain भी देना होगा, ताकि किसी खास डोमेन को अनुमति से जोड़ा जा सके.
अनुमति बनाने के लिए:
permissionsरिसॉर्स परcreateतरीके का इस्तेमाल करें. इसके लिए, उससे जुड़ी फ़ाइल या फ़ोल्डर के लिएfileIdपाथ पैरामीटर का इस्तेमाल करें.- अनुरोध के मुख्य हिस्से में,
typeऔरroleके बारे में बताएं. - अगर
type=userयाtype=groupमें से कोई एक वैल्यू दी गई है, तोemailAddressकी वैल्यू दें. अगरtype=domain, तोdomainदें.
यहां दिए गए कोड के सैंपल में, अनुमति बनाने का तरीका बताया गया है. जवाब में, असाइन किए गए permissionId के साथ-साथ permissions संसाधन का एक इंस्टेंस दिखता है.
अनुरोध
POST https://www.googleapis.com/drive/v3/files/FILE_ID/permissions{ "role": "commenter", "type": "user", "emailAddress": "alex@altostrat.com" }
जवाब
{
"kind": "drive#permission",
"id": "PERMISSION_ID",
"type": "user",
"role": "commenter"
}टारगेट ऑडियंस के साथ शेयर करना
टारगेट ऑडियंस, लोगों के ऐसे ग्रुप होते हैं जिनके साथ उपयोगकर्ता अपने आइटम शेयर कर सकते हैं. जैसे, डिपार्टमेंट या टीमें. उपयोगकर्ताओं को पूरे संगठन के बजाय, किसी खास या सीमित ऑडियंस के साथ आइटम शेयर करने के लिए बढ़ावा दिया जा सकता है. टारगेट ऑडियंस की मदद से, अपने डेटा की सुरक्षा और निजता को बेहतर बनाया जा सकता है. साथ ही, उपयोगकर्ताओं के लिए डेटा को सही तरीके से शेयर करना आसान बनाया जा सकता है. ज़्यादा जानकारी के लिए, टारगेट ऑडियंस के बारे में जानकारी देखें.
टारगेट ऑडियंस का इस्तेमाल करने के लिए:
Google Admin console में, मेन्यू > डायरेक्ट्री > टारगेट ऑडियंस पर जाएं.
यह टास्क पूरा करने के लिए, आपको सुपर एडमिन के तौर पर साइन इन करना होगा.
टारगेट ऑडियंस की सूची में, टारगेट ऑडियंस के नाम पर क्लिक करें. टारगेट ऑडियंस बनाने के लिए, टारगेट ऑडियंस बनाना लेख पढ़ें
टारगेट ऑडियंस के यूआरएल से यूनीक आईडी कॉपी करें:
https://admin.google.com/ac/targetaudiences/ID.type=domainकी मदद से अनुमति बनाएं औरdomainफ़ील्ड कोID.audience.googledomains.comपर सेट करें.
यह देखने के लिए कि उपयोगकर्ता, टारगेट ऑडियंस के साथ कैसे इंटरैक्ट करते हैं, लिंक शेयर करने के लिए उपयोगकर्ता अनुभव देखें.
अनुमति पाना
अनुमति पाने के लिए, permissions रिसॉर्स पर get तरीके का इस्तेमाल करें. इसके लिए, fileId और permissionId पाथ पैरामीटर का इस्तेमाल करें. अगर आपको अनुमति का आईडी नहीं पता है, तो list तरीके का इस्तेमाल करके, सभी अनुमतियों की सूची बनाएं.
यहां दिए गए कोड सैंपल में, आईडी के हिसाब से अनुमति पाने का तरीका बताया गया है. जवाब में, permissions संसाधन का एक इंस्टेंस मिलता है.
अनुरोध
GET https://www.googleapis.com/drive/v3/files/FILE_ID/permissions/PERMISSION_ID
जवाब
{
"kind": "drive#permission",
"id": "PERMISSION_ID",
"type": "user",
"role": "commenter"
}अनुमतियों की सूची
किसी फ़ाइल, फ़ोल्डर या शेयर की गई ड्राइव के लिए अनुमतियों की सूची बनाने के लिए, fileId पाथ पैरामीटर के साथ permissions रिसॉर्स पर list तरीके का इस्तेमाल करें.
अनुमतियों के पेज नंबर बदलने या उन्हें फ़िल्टर करने के लिए, यहां दिए गए क्वेरी पैरामीटर पास करें:
pageSize: हर पेज के लिए, अनुमति वापस लेने की ज़्यादा से ज़्यादा संख्या. अगर शेयर की गई ड्राइव में मौजूद फ़ाइलों के लिए यह विकल्प सेट नहीं किया गया है, तो ज़्यादा से ज़्यादा 100 नतीजे दिखाए जाते हैं. अगर शेयर की गई ड्राइव में मौजूद फ़ाइलों के लिए यह विकल्प सेट नहीं किया गया है, तो पूरी सूची दिखाई जाती है.pageToken: यह एक पेज टोकन है, जो सूची बनाने के लिए किए गए पिछले कॉल से मिला है. अगला पेज पाने के लिए, यह टोकन दें.supportsAllDrives: अनुरोध करने वाला ऐप्लिकेशन, 'मेरी ड्राइव' और शेयर की गई ड्राइव, दोनों के साथ काम करता है या नहीं.useDomainAdminAccess: डोमेन एडमिन के तौर पर अनुरोध करने के लिए, इसेtrueपर सेट करें. अगरfileIdपैरामीटर, शेयर की गई ड्राइव से जुड़ा है और अनुरोध करने वाला व्यक्ति उस डोमेन का एडमिन है जिससे शेयर की गई ड्राइव जुड़ी है, तो उसे ऐक्सेस दिया जाता है. ज़्यादा जानकारी के लिए, डोमेन एडमिन के तौर पर शेयर की गई ड्राइव मैनेज करना लेख पढ़ें.includePermissionsForView: जवाब में शामिल करने के लिए, अतिरिक्त व्यू की अनुमतियां. सिर्फ़publishedका इस्तेमाल किया जा सकता है.
यहां दिए गए कोड सैंपल में, अनुमतियों की सूची बनाने का तरीका बताया गया है. जवाब में, किसी फ़ाइल, फ़ोल्डर या शेयर की गई ड्राइव के लिए अनुमतियों की सूची मिलती है.
अनुरोध
GET https://www.googleapis.com/drive/v3/files/FILE_ID/permissionsजवाब
{
"kind": "drive#permissionList",
"permissions": [
{
"kind": "drive#permission",
"id": "PERMISSION_ID",
"type": "user",
"role": "commenter"
}
]
}अनुमति अपडेट करना
किसी फ़ाइल या फ़ोल्डर की अनुमतियां अपडेट करने के लिए, असाइन की गई भूमिका बदली जा सकती है. भूमिका के सोर्स का पता लगाने के बारे में ज़्यादा जानने के लिए, भूमिका के सोर्स का पता लगाना लेख पढ़ें.
permissionsसंसाधन परupdateतरीके को कॉल करें. इसके लिए,fileIdपाथ पैरामीटर को उससे जुड़ी फ़ाइल, फ़ोल्डर या शेयर की गई ड्राइव पर सेट करें. साथ ही,permissionIdपाथ पैरामीटर को बदलने की अनुमति पर सेट करें.permissionIdको ढूंढने के लिए,fileIdपाथ पैरामीटर के साथpermissionsरिसॉर्स परlistतरीके का इस्तेमाल करें.अनुरोध में, नए
roleकी पहचान करें.
किसी उपयोगकर्ता या ग्रुप के पास पहले से ही शेयर की गई ड्राइव का ऐक्सेस होने पर भी, उसे शेयर की गई ड्राइव में मौजूद किसी फ़ाइल या फ़ोल्डर का ऐक्सेस दिया जा सकता है. उदाहरण के लिए, ऐलेक्स के पास शेयर की गई ड्राइव की सदस्यता के तौर पर role=commenter है. हालांकि, आपका ऐप्लिकेशन, शेयर की गई ड्राइव में मौजूद किसी फ़ाइल के लिए Alex
role=writer को अनुमति दे सकता है. इस मामले में, नई भूमिका में सदस्यता के ज़रिए मिली भूमिका की तुलना में ज़्यादा अनुमतियां हैं. इसलिए, फ़ाइल या फ़ोल्डर के लिए नई भूमिका, लागू होने वाली भूमिका बन जाती है.
पैच सिमैंटिक के ज़रिए अपडेट लागू किए जा सकते हैं. इसका मतलब है कि किसी संसाधन में कुछ बदलाव किए जा सकते हैं. आपको उन फ़ील्ड को साफ़ तौर पर सेट करना होगा जिनमें आपको अपने अनुरोध में बदलाव करना है. अनुरोध में शामिल नहीं किए गए फ़ील्ड की मौजूदा वैल्यू बनी रहती हैं. ज़्यादा जानकारी के लिए, आंशिक संसाधनों के साथ काम करना लेख पढ़ें.
भूमिकाएं बदलने के साथ-साथ, किसी आइटम के दिखने की सेटिंग में भी बदलाव किया जा सकता है. ऐसा तब किया जा सकता है, जब अनुमति type या domain या anyone हो. शेयर की गई किसी फ़ाइल को खोजे जाने या 'सबके लिए मौजूद नहीं' के तौर पर सेट करने के लिए, अपने पैच अनुरोध में allowFileDiscovery बूलियन फ़ील्ड शामिल करें. इस विकल्प को true पर सेट करने से, आइटम को टारगेट की गई ऑडियंस के लिए खोज के नतीजों में दिखने की अनुमति मिलती है. भले ही, उन्हें सीधे तौर पर लिंक न दिया गया हो. इस सेटिंग को बदलने के लिए, आपको अनुमति को मिटाने और फिर से बनाने की ज़रूरत नहीं है.
यहां दिए गए कोड के सैंपल में, किसी फ़ाइल या फ़ोल्डर की अनुमतियों को commenter से writer में बदलने का तरीका बताया गया है. जवाब में, permissions संसाधन का एक इंस्टेंस मिलता है.
अनुरोध
PATCH https://www.googleapis.com/drive/v3/files/FILE_ID/permissions/PERMISSION_ID
{
"role": "writer"
}जवाब
{
"kind": "drive#permission",
"id": "PERMISSION_ID",
"type": "user",
"role": "writer"
}भूमिका के सोर्स का पता लगाना
किसी फ़ाइल या फ़ोल्डर के लिए भूमिका बदलने के लिए, आपको भूमिका के सोर्स के बारे में पता होना चाहिए. शेयर की गई ड्राइव के लिए, किसी भूमिका का सोर्स, शेयर की गई ड्राइव की सदस्यता, फ़ोल्डर की भूमिका या फ़ाइल की भूमिका के आधार पर तय किया जा सकता है.
शेयर की गई ड्राइव या उस ड्राइव में मौजूद आइटम के लिए भूमिका का सोर्स तय करने के लिए, permissions संसाधन पर get तरीके को कॉल करें. इसके लिए, fileId और permissionId पाथ पैरामीटर का इस्तेमाल करें. साथ ही, fields पैरामीटर को permissionDetails फ़ील्ड पर सेट करें.
permissionId को ढूंढने के लिए, fileId पाथ पैरामीटर के साथ permissions संसाधन पर list तरीके का इस्तेमाल करें. list अनुरोध पर permissionDetails फ़ील्ड को फ़ेच करने के लिए, fields पैरामीटर को permissions/permissionDetails पर सेट करें.
इस फ़ील्ड में, उपयोगकर्ता, ग्रुप या डोमेन के लिए फ़ाइल की सभी इनहेरिट की गई और सीधे तौर पर दी गई अनुमतियां शामिल होती हैं.
यहां दिए गए कोड सैंपल में, भूमिका के सोर्स का पता लगाने का तरीका बताया गया है. जवाब में, permissions संसाधन का permissionDetails दिखता है. inheritedFrom फ़ील्ड, उस आइटम का आईडी दिखाता है जिससे अनुमति मिली है.
अनुरोध
GET https://www.googleapis.com/drive/v3/files/FILE_ID/permissions/PERMISSION_ID?fields=permissionDetails&supportsAllDrives=true
जवाब
{
"permissionDetails": [
{
"permissionType": "member",
"role": "commenter",
"inheritedFrom": "INHERITED_FROM_ID",
"inherited": true
},
{
"permissionType": "file",
"role": "writer",
"inherited": false
}
]
}एक साथ कई अनुरोध करके, एक से ज़्यादा अनुमतियां अपडेट करना
हमारा सुझाव है कि एक साथ कई अनुमतियों में बदलाव करने के लिए, बैच अनुरोधों का इस्तेमाल करें.
यहां क्लाइंट लाइब्रेरी की मदद से, अनुमति में एक साथ कई बदलाव करने का उदाहरण दिया गया है.
Java
Python
Node.js
PHP
.NET
अनुमति मिटाना
किसी फ़ाइल या फ़ोल्डर का ऐक्सेस रद्द करने के लिए, permissions रिसॉर्स पर delete तरीके को कॉल करें. साथ ही, अनुमति मिटाने के लिए fileId और permissionId पाथ पैरामीटर सेट करें.
इनहेरिट की गई अनुमतियां वापस नहीं ली जा सकतीं. इसके बजाय, पैरंट फ़ोल्डर के लिए अनुमति अपडेट करें या मिटाएं. किसी फ़ोल्डर से अनुमति हटाने पर, उसके चाइल्ड आइटम का ऐक्सेस भी रद्द हो जाता है.
पैरंट की तुलना में अनुमतियां कम करने के लिए, सीमित ऐक्सेस की सेटिंग का इस्तेमाल करना ज़रूरी है.
ध्यान दें कि किसी उपयोगकर्ता का ऐक्सेस पैरंट आइटम से हटाने पर, सिर्फ़ पैरंट से मिली अनुमतियां रद्द होती हैं. अगर किसी उपयोगकर्ता को सीधे तौर पर किसी चाइल्ड फ़ाइल या फ़ोल्डर पर अनुमतियां दी गई थीं, तो उसका ऐक्सेस बना रहता है. यह पक्का करने के लिए कि सभी चाइल्ड आइटम, पैरंट आइटम की अनुमतियों से मेल खाते हों, आपको उन चाइल्ड आइटम पर उपयोगकर्ता को सीधे तौर पर दी गई अनुमतियों की पहचान करके उन्हें हटाना होगा.
यहां दिए गए कोड सैंपल में, permissionId को मिटाकर ऐक्सेस रद्द करने का तरीका बताया गया है. अगर अनुरोध पूरा हो जाता है, तो जवाब के मुख्य हिस्से में एक खाली JSON ऑब्जेक्ट होता है. अनुमति हटा दी गई है, इसकी पुष्टि करने के लिए fileId पाथ पैरामीटर के साथ permissions संसाधन पर list तरीके का इस्तेमाल करें.
अनुरोध
DELETE https://www.googleapis.com/drive/v3/files/FILE_ID/permissions/PERMISSION_ID
आइटम के ऐक्सेस को सीमित करने के लिए, ऐक्सेस खत्म होने की तारीख सेट करना
जब किसी संवेदनशील प्रोजेक्ट पर लोगों के साथ काम किया जा रहा हो, तो हो सकता है कि आप कुछ समय बाद, Drive में मौजूद कुछ आइटम को ऐक्सेस करने पर पाबंदी लगाना चाहें. फ़ाइलों और फ़ोल्डर के लिए, समयसीमा खत्म होने की तारीख सेट की जा सकती है. इससे उस आइटम को ऐक्सेस करने की सुविधा सीमित की जा सकती है या हटाई जा सकती है.
ऐक्सेस खत्म होने की तारीख सेट करने के लिए:
permissionsसंसाधन परcreateतरीके का इस्तेमाल करें. साथ ही,expirationTimeफ़ील्ड और अन्य ज़रूरी फ़ील्ड सेट करें. ज़्यादा जानकारी के लिए, अनुमति बनाना लेख पढ़ें.permissionsरिसॉर्स परupdateतरीके का इस्तेमाल करें. साथ ही,expirationTimeफ़ील्ड और अन्य ज़रूरी फ़ील्ड सेट करें. ज़्यादा जानकारी के लिए, अनुमति अपडेट करना लेख पढ़ें.
expirationTime फ़ील्ड से पता चलता है कि अनुमति कब खत्म होगी. इसके लिए, RFC 3339
date-time का इस्तेमाल किया जाता है. ऑफ़र के खत्म होने की तारीख और समय पर ये पाबंदियां लागू होती हैं:
- इन्हें सिर्फ़ उपयोगकर्ता और ग्रुप की अनुमतियों के लिए सेट किया जा सकता है.
- समय, आने वाले समय का होना चाहिए.
- यह समय, आने वाले समय के एक साल से ज़्यादा का नहीं हो सकता.
- सिर्फ़
readerभूमिका वाले उपयोगकर्ता के लिए, फ़ोल्डर का ऐक्सेस खत्म होने की तारीख सेट की जा सकती है.
एक्सपायर होने की तारीखों के बारे में ज़्यादा जानने के लिए, ये लेख पढ़ें:
- फ़ाइल के लिंक और ऐक्सेस कंट्रोल
- फ़ाइल के ऐक्सेस के लिए समयसीमा खत्म होने की तारीख सेट करना
- ऐक्सेस खत्म होने की तारीख जोड़ना
मिलते-जुलते विषय
- ऐक्सेस के लंबित अनुरोध मैनेज करना
- सीमित और ज़्यादा ऐक्सेस वाले फ़ोल्डर मैनेज करना
- फ़ाइल का मालिकाना हक ट्रांसफ़र करना
- फ़ाइल के कॉन्टेंट को सुरक्षित रखना
- संसाधन कुंजियों का इस्तेमाल करके, लिंक शेयर करके Drive की गई फ़ाइलों को ऐक्सेस करना
- भूमिकाएं और अनुमतियां