आप Office दस्तावेज़ खोलते हैं, तो प्रमाणीकरण अनुरोध

लक्षण

किसी वेब सर्वर से किसी Microsoft Office दस्तावेज़ खोलते हैं, तो आपको प्रमाणीकरण के लिए कहा जा सकता है। Microsoft ज्ञानकोष आलेख 838028में विशिष्ट तकनीकी कारणों से बताई गई है।  हालांकि, जो अंतर्निहित समस्या कैसे समस्या के साथ contend पर कोई विशिष्ट पहुँचों प्रस्ताव बिना को कवर कर ले। उस आलेख में Office 2003 व्यवहार का वर्णन करने के लिए लिखा गया था, लेकिन इसी अंतर्निहित व्यवहार अधिक वर्तमान Microsoft Office के संस्करणों के लिए भी मौजूद है।

यह दस्तावेज़ समस्या और समस्या के साथ dealing करने के लिए विभिन्न पहुँचों का ओवरव्यू उपलब्ध कराता है। वर्तमान में कोई panacea है। इसलिए, सबसे उपयुक्त विकल्प किस कार्यक्षमता लक्षित श्रोताओं के लिए आवश्यक है और कौन-सी कॉन्फ़िगरेशन workable हैं पर निर्भर करता है। अधिकांश मामलों में, एक कॉम्प्रोमाइस प्रकिया की आवश्यकता होगी।

कारण

जब आप Internet Explorer को एक Office दस्तावेज़ खोलता है, तो उपयुक्त Office अनुप्रयोग दस्तावेज़ का पथ के साथ प्रारंभ होती है। Office अनुप्रयोग फिर सर्वर से सीधे दस्तावेज़ तक पहुँचने के लिए कोशिश करता है। यह अन्य ब्राउज़र और अन्य फ़ाइल प्रकार से भिन्न है। अधिकांश ब्राउज़र्स फ़ाइल डाउनलोड करें और स्थानीय कैश से फ़ाइल को खोलने के लिए अनुप्रयोग को कॉल करें। यदि खोला फ़ाइल परिवर्तित और सहेजा गया है यह, तब होती है जब करते हैं, तथापि, परिवर्तन केवल स्थानीय प्रति और सर्वर प्रति में नहीं किए जाते हैं।

Richest अनुभव को स्थापित करने के लिए संभव हो, Office अनुप्रयोग है जो पहली बात क्या वेब ऑथरिंग प्रोटोकॉल उपलब्ध नहीं है और वह सर्वर प्रकार निर्धारित करने के लिए सर्वर के साथ संवाद है। अनुप्रयोग इस सर्वर के लिए सीधे कोई विकल्प अनुरोध कर करता है।

सर्वर तक पहुँचने को नई प्रक्रिया के रूप में Office अनुप्रयोग प्रमाणन renegotiate करने के लिए आवश्यक है। यह विधि जिसमें नया प्रक्रिया ब्राउज़र द्वारा स्थापित किया गया था जो किसी मौजूदा प्रमाणन का उपयोग करता है एक पद्धति से अधिक सुरक्षित है।

समाधान

अधिकांश इंट्रानेट परिस्थितियों में, यह समस्या सबसे आसानी से एकीकृत Windows प्रमाणीकरण का उपयोग करने के लिए सर्वर को कॉन्फ़िगर करने और उसके बाद क्लाइंट स्वत: लॉगऑन को सक्षम करने के लिए कॉन्फ़िगर करने के द्वारा संबोधित किया है। उपयोगकर्ता नाम और पासवर्ड का वर्तमान में लॉग-ऑन Windows उपयोगकर्ता है तब स्वचालित रूप से भेजी सर्वर करने के लिए जब उपयोगकर्ता संकेत दिए बिना प्रमाणन अनुरोध किया है।

स्वत: लॉगऑन की अनुमति दें करने के लिए Internet Explorer को सक्षम करने के लिए विकल्प जहाँ है साइट ज़ोन के लिए सक्षम होना चाहिए। स्थानीय इंट्रानेट ज़ोन पर वर्तमान उपयोगकर्ता नाम और पासवर्ड के साथ स्वत: लॉगऑन के एक डिफ़ॉल्ट कॉन्फ़िगरेशन है। स्थानीय इंट्रानेट ज़ोन सभी नेटवर्क कनेक्शंस जिनमें कोई यूनिवर्सल नेमिंग कन्वेंशन (UNC) पथ और जो प्रॉक्सी सर्वर को बायपास या वे या तो प्रतिबंधित साइट या विश्वसनीय साइट्स ज़ोन के लिए असाइन किए गए हैं न ही जिनकी नामों (जैसे http://local), अवधियों शामिल न करें जो वेब साइट्स का उपयोग कर स्थापित किए गए के रूप में परिभाषित की जाती है। केवल इंट्रानेट ज़ोन में विश्वसनीय ज़ोन स्वत: लॉगऑन के एक डिफ़ॉल्ट कॉन्फ़िगरेशन है।

Windows Vista या Windows के किसी बाद वाले संस्करण पर 2007 Microsoft Office का उपयोग कर Microsoft Office दस्तावेज़ खोलते हैं, तो अनुप्रयोग एक वेब-आधारित वितरित रचना और संस्करण (WebDAV) कनेक्शन करने के लिए वेब क्लाइंट सेवा के माध्यम से वेब सर्वर पर स्थापित करने का प्रयास करता है। Windows Vista के साथ प्रारंभ कर रहा है, वेब क्लाइंट सेवा WinHTTP नेटवर्क प्रोटोकॉल का उपयोग करता है और ज़ोन प्रबंधक का उपयोग नहीं करता है। केवल निम्न मापदंडों की एक पूरी हो रही है, तो उपयोगकर्ता लॉग-ऑन क्रेडेंशियल स्वचालित रूप से दे दिए जाते हैं:

  • साइट (इसमें कोई "बिंदु" में URL है) NetBIOS नाम है।
  • किसी प्रॉक्सी का पता लगाया है, और साइट URL प्रॉक्सी बायपास मापदंड से मेल खाता है।
  • साइट को पूरी तरह क्वालीफ़ाइड डोमेन नाम (FQDN) है, से बड़ा या बराबर करने के लिए 6.0.6000.20729 webclnt.dll संस्करण है, और साइट URL वेब क्लाइंट सेवा पैरामीटर रजिस्ट्री मानAuthForwardServerListनिर्दिष्ट मापदंड से मेल खाता है। (ज्ञानकोश आलेख 943280 अधिक जानकारी के लिए देखें.)

साइट द्वारा आवश्यक हैं वे आपका Windows लॉगऑन क्रेडेंशियल से मेल, तो एकीकृत Windows प्रमाणीकरण स्वचालित रूप से Windows उपयोगकर्ता नाम और पासवर्ड का उपयोग कर लॉग ऑन करने के लिए कॉन्फ़िगर करने के लिए क्लाइंट की अनुमति चाहिए। कृपया किसी इंटरनेट-फ़ेसिंग कनेक्शन पर एकीकृत Windows प्रमाणीकरण का उपयोग अनुशंसित समर्थित या नहीं कि अवगत हो।

ध्यान रखें कि यदि वर्तमान में लॉग-ऑन उपयोगकर्ता के क्रेडेंशियल्स हैं क्या (जैसे जब सर्वर और कार्यस्थान विश्वसनीय डोमेन में नहीं हैं) दस्तावेज़ तक पहुँचने के लिए आवश्यक नहीं है, उस उपयोगकर्ता क्रेडेंशियल दर्ज करने के लिए कहा है। यदि आप किसी साइट तक पहुँचने के लिए क्रेडेंशियल प्रदान करना चाहिए, तो आप आम तौर पर किसी दस्तावेज़ को खोलने के लिए क्रेडेंशियल प्रदान करना चाहिए कि सामान्य दिशानिर्देश है।

एकीकृत Windows प्रमाणीकरण व्यवहार्य नहीं है, जब क्रेडेंशियल संकेतों की पुनरावृत्ति समस्या पैदा करने वाले बन सकते हैं। निम्न विधियों में से किसी कुछ विकल्प और उनके नुकसान हैं:

विधि 1: की पूर्ण कार्यशीलता के साथ लेकिन एक परिकलित जोखिम के साथ एक विकल्प

इंटरनेट सुरक्षा और एक्सेलेरेशन (ISA) सर्वर या फ़ोरफ़्रंट ख़तरा प्रबंधन गेटवे जैसे निर्बाध कुकीज़ के साथ प्रपत्र आधारित प्रमाणीकरण का उपयोग कर कोई फ़ायरवॉल/प्रॉक्सी सर्वर को कार्यान्वित करने के लिए उपयोग प्रपत्र आधारित प्रमाणीकरण (FBA) से निर्बाध कुकीज़ – प्रत्यक्ष-संपादन कार्यक्षमता बनाए रखने और भी Office अनुप्रयोग द्वारा नहीं कहा जा करने का एकमात्र तरीका है। हालांकि, निर्बाध कुकीज़ discriminating नहीं हैं और अवांछित अनुप्रयोग भी साझा प्रमाणन का लाभ लेने के लिए अनुमति दे सकते हैं, क्योंकि सावधानी सलाह दी जाती है। इस एक् सपोज़र टाइम-आउट सेटिंग्स का कोई उपयुक्त कॉन्फ़िगरेशन से कम हो सकते हैं, लेकिन किसी तत्व का जोखिम प्रस्तुत है।

ISA 2006, में निर्बाध कुकीज़, के साथ HTML प्रपत्र आधारित प्रमाणीकरण का उपयोग करके ब्राउज़र (जैसे Office अनुप्रयोगों) से बाहर अनुप्रयोग कुकीज़ का उपयोग कर सकते हैं। हालाँकि, कुकीज़ "निर्बाध." है वे जब आप ब्राउज़र या Office अनुप्रयोग बंद करें, और उपयोगकर्ता एक इंटरनेट café या अन्य सार्वजनिक स्थान में कार्य कर रहा था, तो वे प्रवेश किया जा सकता, इसलिए नहीं हटाए जाते। हालाँकि, समयबाह्य कुकी अभी भी, टाइमआउट कॉन्फ़िगरेशन को ISA सर्वर सेटिंग्स में पर आधारित लागू होते हैं।

"केवल निजी कंप्यूटरों पर निर्बाध कुकीज़ का उपयोग करने के लिए" विकल्प है जो इस सुरक्षाछिद्र घटाता है, लेकिन उपयोगकर्ता "निजी कंप्यूटर" निर्बाध कुकी सुविधा को सक्षम करने के लिए FBA प्रपत्र में का चयन करना होगा। (उपयोगकर्ता "निजी कंप्यूटर" केवल चयन करना चाहिए जब वे उपयोग जो वे के स्वामी या पर विश्वास करें.)

नोट साइट विश्वसनीय ज़ोन में Internet Explorer में "सुरक्षित मोड" सेटिंग के कारण है, तो प्रारंभ Internet Explorer 7 के साथ Windows Vista में डिफ़ॉल्ट रूप से, निर्बाध कुकीज़ साझा होते हैं। एक स्पष्टीकरण और एक वैकल्पिक हल के लिए, कृपया Microsoft ज्ञानकोष आलेख 932118देखें।

विधि 2: के प्रभाव को कम कर सकते हैं जो क्लाइंट पहुँचों

अनुप्रयोग को खुला छोड़ – उन के लिए जो कार्यक्षमता प्रत्यक्ष-संपादन बनाए रखने के लिए चाहते हैं, लेकिन जिनके लिए निर्बाध कुकीज़ के साथ FBA कोई विकल्प नहीं है उपयोगकर्ताओं को एकाधिक संकेतों के प्रभाव प्रथम प्रवेश किया है करने के बाद अनुप्रयोग खुला छोड़ने के द्वारा कम कर सकते हैं। अनुप्रयोग के बजाय केवल दस्तावेज़ बंद कर, उसी अनुप्रयोग का उपयोग करता है जो किसी अन्य दस्तावेज़ उपयोगकर्ता क्रेडेंशियल्स के लिए संकेत किया जा रहा निष्पादन प्रक्रिया पहले से ही प्रमाणीकृत किया गया है, क्योंकि बिना खोला जा सकता है। अन्य अनुप्रयोग की आवश्यकता होती है जो भिन्न प्रकार के दस्तावेज़ अभी भी एक प्रॉम्प्ट साइट में प्रवेश करने की आवश्यकता है जो प्रत्येक नए अनुप्रयोग के लिए की आवश्यकता होती है।

"पासवर्ड याद रखें" का चयन करें – क्रेडेंशियल के लिए अनुरोध उपयोगकर्ता पासवर्ड को याद करने के लिए विकल्प का चयन करता है, तो कम intrusive हो सकता है। केवल क्लाइंट कंप्यूटर में एक निजी विश्वसनीय वातावरण है, और इसे किसी सार्वजनिक कंप्यूटर पर उपयोग नहीं किया जाना चाहिए किया जाना चाहिए। (कई कंपनियों नीति सहेजने के पासवर्ड को प्रतिबंधित करता कोई सेट.)  पासवर्ड सहेजने अनुरोध दूर नहीं होगी, लेकिन केवल कोई एकल क्लिक/कीस्ट्रोक प्रतिसाद करने के लिए आवश्यक है ताकि इसे जानकारी के साथ प्रि-पापुलेट होगा। इस प्रकिया का उपयोग किया जाता है, तो इस साइट को विश्वसनीय साइट्स ज़ोन में जोड़ा जाना चाहिए।

परिणाम Preconfigure विकल्प जानकारी थी पहले प्राप्त की और Office प्रोटोकॉल खोज कैश में कैश की गई हैं, तो नॉलेज बेस आलेख 838028में बताया गया, के रूप में विकल्प कॉल निष्पादित नहीं हुआ है।

महत्वपूर्ण मान या रजिस्ट्री कुंजी को सीधे संपादित करने – अनुशंसित नहीं है। की प्रतिलिपि बनाएँ और उसे एक परीक्षण कंप्यूटर पर पॉपुलेटेड किया गया था के बाद जानकारी को वितरित करने के लिए पूर्व में बसाने की जानकारी का सबसे आसान तरीका है। सहेजी गई जानकारी अस्थायी है क्योंकि Office कैश समय-समय पर साफ़ करता है। यद्यपि यह समय सीमा तक विस्तृत कर सकते हैं, लेकिन डिफ़ॉल्ट रूप से, यह लगभग दो सप्ताह के बाद समाप्त हो। किसी अद्यतन को इस समय के विस्तार के लिए 10 साल के लिए देता है जो Office 2003 सर्विस पैक 3 (और 2007 Microsoft Office में भी उपलब्ध) में शामिल किया गया था। (ज्ञानकोश आलेख 916658देखें.) वेब ऑथरिंग प्रोटोकॉल या सर्वर प्रकार परिवर्तन हैं, तो Office 2003 अभी भी पुराने जानकारी मान्य है मान जाएगा कि इस रजिस्ट्री प्रविष्टि का उपयोग करने के downside है।

Office प्रोटोकॉल खोज कैश – Office प्रोटोकॉल खोज कैश उपकुंजी प्रविष्टियाँ जो खोला है और जो कोई विकल्प अनुरोध प्रतिसाद किया हर वेब फ़ोल्डर के लिए है। Office 2003 के द्वारा उपयोग किया जाता है जो रजिस्ट्री कुंजी निम्नानुसार है:

HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Common\Internet\Server कैश

नोट 2007 Microsoft Office किसी समान कुंजी का उपयोग करता है लेकिन "12.0" के बजाय "11.0." शामिल हैं. Microsoft Office 2010 "14.0" के बजाय "11.0." का उपयोग करता है

कैश प्रविष्टियों की अधिकतम संख्या से ही सर्वर कैश कुंजी के अंतर्गतMaxCount रजिस्ट्री मान सेट किया जा सकता है। Office अधिकतम संख्या तक पहुँच है यदि पर उपलब्ध स्थान बढ़ाने के लिए पुरानी प्रविष्टियों को निकालता है। कोई स्थान साफ़ नहीं किया जा सकता है, तो विकल्प कॉल के परिणाम कैश नहीं हैं।

विकल्प प्रतिसाद preconfiguring क्रेडेंशियल के लिए सभी अनुरोध दूर नहीं हो सकता है। या सिर PROPFIND अनुरोध भी प्रमाणन के लिए अनुरोध में परिणाम कर सकते हैं।

विधि 3: DAV वेब सर्वर का समर्थन नहीं करता है या सीमित कार्यक्षमता स्वीकार्य है, जब वैकल्पिक कॉन्फ़िगरेशन

अतिरिक्त क्रेडेंशियल्स द्वारा बलपूर्वक स्थानीय रूप से कैश की गई दस्तावेज़ का उपयोग की आवश्यकता नहीं है ताकि किसी साइट को कॉन्फ़िगर करने के तरीके भी हैं। हालाँकि, कॉन्फ़िगरेशन जो निर्दिष्ट URL के लिए सभी उपयोगकर्ताओं को प्रभावित करेगा, और प्रत्यक्ष-संपादन कार्यक्षमता अक्षम किया गया है। इसलिए, उपयोगकर्ताओं को Office अनुप्रयोग से सर्वर पर सीधे सहेजने में सक्षम नहीं होंगे। दस्तावेज़ ऑफ़लाइन संपादित और सर्वर पर अपलोड करना होगा। श्रेष्ठ प्रकिया विशिष्ट परिदृश्य और इच्छित व्यवहार पर निर्भर करता है।

नोट का उपयोग एक 200 प्रतिक्रिया के साथ एक PROPFIND के प्रतिसाद वेब सर्वर कर सकते हैं भी परिणाम एक प्रमाणीकरण प्रॉम्प्ट में कुकीज़ मौजूद हैं। जब Windows WebClient सेवा PROPFIND अनुरोध भेजता है, तब उसे उचित 207 बहु-स्थिति प्रतिक्रिया XML गुण, मान और अलग-अलग स्थिति के साथ लौटेगा PROPFIND अनुरोध लक्ष्य होस्ट समर्थन करता है, तो यह जो मानता है। WebClient सेवा भी यदि लक्ष्य होस्ट इस 405 जैसा कोई त्रुटि स्थिति लौट जाएगा PROPFIND का समर्थन नहीं करता विधि अनुमति नहीं है जो मानता है। हालांकि, WebClient सेवा इसके बजाय सुगठित XML नहीं है कोई स्थिति कोड 200 के साथ एक प्रतिसाद प्राप्त फिर 'अमान्य पैरामीटर' में कोई त्रुटि है आंतरिक रूप से जनरेट किया गया और के साथ मूल्यांकन रूटिन करने के लिए दिया गया। कुकीज़ और एक समय सीमा समाप्त कुकी का परीक्षण कर रहा है जब दुर्भाग्यवश 'अमान्य पैरामीटर' त्रुटि भी उठाया जा सकते हैं। रूटिन जिस मूल्यांकन नहीं जानते हैं, क्योंकि जिसने यह कुकीज़ अनुरोध पर मौजूद नहीं हैं, तो यह देखने के लिए जाँच करता है त्रुटि उठाया। कुकीज़ अनुरोध में मौजूद नहीं थे, तो 'अमान्य पैरामीटर' पर ध्यान न दें करने के लिए सुरक्षित है और यह एक WebDAV सर्वर नहीं है कि अंततः सेवा concludes; इसलिए यह किसी समयसीमा समाप्त कुकी के रूप में मानता है और 'पहुँच अस्वीकृत' त्रुटि में कनवर्ट करता है हालांकि, मौजूद कुकीज़ के साथ उसे उस निर्धारण वापस चेन की कॉल्स को पहुँचने से पहले कर सकता है। अंततः 'प्रवेश निषेध' द्वारा इसे की आवश्यकता है और संकेत दिया गया है Windows प्रमाणन क्रेडेंशियल के लिए के रूप में interprets कोई घटक हो है। या तो दो विकल्पों का पालन करें जो इस विशिष्ट कारण को संबोधित करेंगे।

सामग्री-प्रकार के अनुलग्नक (नॉन-SharePoint) का उपयोग करें – GET अनुरोध Internet Explorer समस्याएँ करते हैं, एक वेब अनुप्रयोग में सीधे संपादन सत्र के लिए नहीं है, तो स्पष्ट रूप से सामग्री किसी केवल-पढ़ने के लिए डाउनलोड के रूप में चिह्नित करने के लिए सक्षम हो सकता है। सर्वर के लिए फ़ाइलें (जैसे ASP या ASP.NET) कोई कस्टम वेब अनुप्रयोग के माध्यम से प्रदान कर इस ज्ञानकोश आलेख 899927में चर्चा है। "हाइपरलिंक से Internet Explorer के लिए Office" खंड, जो बताता है कि कैसे का उपयोग करने के लिए, देखें "सामग्री-विन्यास: अनुलग्नक" शीर्ष लेख.) जिससे कि अन्य फ़ाइलें शीर्ष लेख का उद्देश्य चुनें नहीं सर्वर फ़ाइल सिस्टम से सीधे ही फ़ाइलें होस्ट कर रहा है और अन्य फ़ाइलों से अलग-अलग फ़ोल्डर में Office फ़ाइलें हैं, तो शीर्ष लेख में वेब सर्वर कॉन्फ़िगरेशन - फ़ोल्डर स्तर पर जोड़ा जा सकता है, तो विभाजन prepferred है।

WebDAV और/या समर्थन विकल्प और PROPFIND क्रियाएँ (SharePoint और नॉन-SharePoint) के लिए अक्षम वेब अनुप्रयोग WebDAV के लिए उपयोग किया जा करने के लिए लक्षित नहीं है, तो वेब सेवा प्रदान WebDAV कार्यक्षमता एक्सटेंशन Prohibited करने के लिए डिफ़ॉल्ट सर्वर पर IIS चल रहा है जो सेट किया जा सकता है। (यह WebDAV या FrontPage सर्वर एक्सटेंशन हो सकता है.) इस साइट से कोई अन्य एक्सटेंशन WebDAV कार्यक्षमता प्रदान करता है, तो उस एक्सटेंशन के प्रदाता अनुलग्न करना चाहिए। उदाहरण के लिए, Windows SharePoint सेवाएँ (WSS) के साथ ऐसा करने के लिए, साइट क्लाइंट एकीकरण या विकल्प को अक्षम करने के लिए कॉन्फ़िगर किया गया है और PROPFIND क्रिया रोकी गई होना चाहिए। (रोकें विकल्प और PROPFIND क्रियाएँ पर इंटरनेट सूचना सेवाओं (IIS) संस्करण 6 के लिए, क्रियाएँ < httpHandlers > पंजीकरण लाइन में web. config फ़ाइल से निकालें। IIS 7.0 पर, फ़िल्टरिंग अनुरोध सुविधा का HTTP क्रियाएँ टैब क्रियापद को अस्वीकार करने के लिए का उपयोग करें.) यह प्रकिया प्रत्यक्ष-संपादन कार्यक्षमता अक्षम कर देता है, क्योंकि यह प्रकिया सामग्री केवल-पढ़ने के लिए मोड में खुलेगा कि अवगत होना है।

नोट Office 2010 विकल्प अनुरोध के साथ ही एक HEAD अनुरोध इश्यू हो सकता है। यह इसे अन्य प्रयोजनों के लिए अन्य अनुप्रयोगों द्वारा उपयोग किया जा सकता, क्योंकि सिर अनुरोध को रोकें करने के लिए अनुशंसित नहीं है।

किस प्रकार का वेब ऑथरिंग प्रोटोकॉल उपलब्ध है और वह सर्वर प्रकार निर्धारित करने के लिए अनाम (नॉन-SharePoint के लिए) विकल्प कॉल अनुमति– Office पहले एक विकल्प कॉल भेजता है। विकल्प कॉल सफल करने के लिए ब्राउज़ करें या सूची अनुमतियों की आवश्यकता है।

दूसरी प्रमाणन अनुरोध को रोकने के लिए, विकल्प प्रतिसाद का कोई "401" कोड के अलावा कुछ वापस स्थिति होना आवश्यक है। फ़ाइलों तक पहुँचने के लिए किसी वेब अनुप्रयोग वेब सर्वर का उपयोग है, तो अनुप्रयोग विकल्प अनुरोध हैंडल करने के लिए परिवर्तित किया जा सका (जैसे के साथ एक "405: विधि की अनुमति नहीं" संदेश)। फ़ाइलों को वेब सर्वर पर फ़ाइल सिस्टम में स्थित हैं, तो हालाँकि, अवांछित अनुरोध सफल हो, और इस प्रकार एक सही तरह से बनी "200" प्रत्युत्तर में परिणाम करने के लिए विकल्प कॉल की अनुमति दें करने के लिए अनुमतियाँ परिवर्तित कर से बचना कर सकते हैं।

IIS सर्वर के लिए, यदि आप IIS प्रबंधक में साइट के लिए अनाम पहुँच को सक्षम करके ऐसा कर सकते हैं।

नोट यदि नेटिव IIS WebDAV वेब सेवा एक्सटेंशन WebDAV कार्यक्षमता प्रदान कर रहा है, तो केवल इस समाधान का उपयोग करें। FrontPage सर्वर एक्सटेंशन का उपयोग किया जा रहा है, तो यह समाधान लागू नहीं करना चाहिए। यह केवल सीमित पहुँच प्रदान कर रहा है जो किसी साइट के लिए counterintuitive हुआ लग रहा है। हालाँकि, सीमित पहुँच फ़ाइल सिस्टम स्तर पर लागू कर सकते हैं। विकल्प अनुरोध केवल (सामान्यतया पर साइट की रुट) सूची सामग्री की अनुमति आवश्यक है, क्योंकि पढ़ने को अस्वीकार , और अनाम पहुँच के लिए (IIS प्रबंधक में लेकिन कभी-कभी के साथ "इंटरनेट अतिथि खाता" के दोस्ताना नाम निर्धारित के रूप में) में प्रयुक्त होने वाले खाते के लिए लेखन को अस्वीकार करने के लिए फ़ोल्डर के लिए अनुमतियाँ परिवर्तित करना चाहिए। यह विकल्प कॉल को संतुष्ट करने के लिए आवश्यक अनुमतियाँ की अनुमति देता है, लेकिन अभी भी किसी भी सामग्री के लिए पहुँच अस्वीकृत कर देता है। Office अनुप्रयोग फिर इंटरनेट कैश से वह दस्तावेज़ खोलें जाएगा।

गुण

आलेख ID: 2019105 - पिछली समीक्षा: 27/01/2017 - संशोधन: 1

प्रतिक्रिया