फायरवॉल अनुमती सूचीमध्ये ArcGIS Online ला कोणत्या डोमेनची गरज आहे?
नकाशा पोर्टल, बेसमॅप, डेटा आणि स्टोरेज एंडपॉइंटला स्पर्श करतो. अनुमती सूची Esri च्या सध्याच्या डोमेन आवश्यकतांमधून तयार करा, एका DNS उत्तरातून नाही.
DNS उत्तर तुम्हाला सांगते की तुम्ही विचारलेल्या क्षणी होस्टनेम कोणत्या पत्त्यावर सोडवले गेले। ते सांगत नाही की पत्ता कायमचा आहे, आणि नकाशा ज्या सर्व गोष्टींना स्पर्श करतो त्यांची यादी करत नाही। जेव्हा आउटबाउंड कोणी एकाच शोधातून टाइप केलेल्या छोट्या अनुमती सूचीपुरता मर्यादित असतो तेव्हा हा फरक सर्वाधिक महत्त्वाचा ठरतो। कार्यप्रवाहापासून सुरुवात करा, नंतर पुरवठादाराच्या सध्याच्या आवश्यकतांमधून सूची काढा। वारंवार येणारे उदाहरण म्हणजे मर्यादित VPN आउटबाउंडद्वारे ArcGIS Online पर्यंत पोहोचणारा एंटरप्राइझ GIS क्लायंट।
नकाशा क्रिया ज्या प्रत्येक घटकाला स्पर्श करते त्याची यादी करा
क्रियेचे भाग करा: संस्थेचे पोर्टल आणि आयटम प्रवेश, बेसमॅप टाइल्स, होस्ट केलेल्या फीचर किंवा विश्लेषण सेवा, आणि कोणतेही आयटम डाउनलोड। प्रत्येक वेगळ्या एंडपॉइंटमागे असू शकते। बाह्य ArcGIS Enterprise सेवा किंवा OGC एंडपॉइंटचा संदर्भ देणारा नकाशा अशी अवलंबित्व जोडतो ज्याबद्दल नेटवर्क टीमने कधी ऐकले नाही। कोणी अनुमती सूचीची विनंती दाखल करण्यापूर्वी हे सर्व लिहून ठेवा। या यादीतून गहाळ असलेला घटक नंतर क्रेडेन्शियलच्या समस्येसारखा दिसणाऱ्या पद्धतीने अयशस्वी होतो।
| Component | Example host family | Form | Who owns it |
|---|---|---|---|
| Portal and item access | *.arcgis.com | Wildcard | Esri, under the organization subdomain |
| Basemaps and static tiles | *.arcgisonline.com | Wildcard | Esri |
| Hosted feature and analysis services | *.arcgis.com | Wildcard | Esri, same revision |
| Item downloads and regional storage | storage hosts named in the current revision | Revision-specific | Esri |
| ArcGIS Enterprise service | gis.example.com | FQDN | Your organization |
| OGC or third-party endpoint | provider host | FQDN | The provider |
| Custom domain in front of the portal | maps.example.com | FQDN | Your organization |
The Domain and FQDN Requirements document is where those families come from, and two of them carry most of the workflow: *.arcgis.com covers the organization portal, its items and the hosted services behind them, while *.arcgisonline.com serves basemaps and static tiles. Everything else is organization-specific, because an ArcGIS Enterprise service you host, an OGC endpoint or a custom domain in front of the portal has to be added by name. Take those entries from the same revision you read, since the regional storage hosts change between versions.
पोर्टलवर साइन-इन यशस्वी होणे हा कमकुवत पुरावा आहे। ते मंजूर मार्गातून पोर्टल एंडपॉइंटपर्यंत पोहोचता येते हे सिद्ध करते, आणि टाइल्स, विश्लेषण किंवा डाउनलोडबद्दल काहीही सांगत नाही।
सध्याच्या दस्तऐवजातून wildcard किंवा FQDN निवडा
Esri Domain and FQDN Requirements प्रकाशित करते, आणि आवृत्त्या बदलल्यावर प्रादेशिक स्टोरेज नोंदी बदलतात त्यामुळे आवृत्ती महत्त्वाची आहे। सध्याचा दस्तऐवज डोमेन-स्तरीय wildcard दृष्टिकोन आणि अधिक कठोर होस्टनेम-स्तरीय यादी असे दोन्ही देतो। तो प्रादेशिक स्टोरेज होस्ट्स देखील नमूद करतो आणि बाह्य प्रणाली व सानुकूल डोमेन संस्था-विशिष्ट नोंदी जोडतात असा इशारा देतो। तुम्ही प्रत्यक्षात वाचलेली आवृत्ती तारखेसह बदल नोंदीत कॉपी करा।
अधिक कठोर सूची देखभालीचा वेळ घेते; अधिक व्यापक परवानगी सुरक्षा-व्याप्ती घेते। ती देवघेव नेटवर्क मालकाची आहे, आणि ती दस्तऐवजाच्या आधारे ठरवली पाहिजे, कोणी एकदा कामाच्या सत्रात टिपलेल्या पत्त्यांच्या संचाच्या आधारे नाही।
स्थिर बेसमॅप पर्याय अरुंद ठेवा
Esri च्या फायरवॉल FAQ मध्ये असे म्हटले आहे की वेगवान बेसमॅप वितरण गतिशील पत्ते परत करू शकते। त्याच नोंदीत बेसमॅपसाठी विशेष स्थिर IP व्यवस्था नोंदवली आहे, जी वेगवान मार्ग सोडते आणि कार्यक्षमता कमी करू शकते। या दोन्ही विधानांपैकी कोणतेही पोर्टल, होस्ट केलेला डेटा आणि स्टोरेज होस्ट्स एका स्थिर पत्त्यात बदलत नाही। केवळ IP पत्त्यांना परवानगी देणारे धोरण बंधनकारक असल्यास, तुम्ही अंदाजलेली श्रेणी रुंदावण्याऐवजी Esri कडून समर्थित व्यवस्था मिळवा।
जुने DNS उत्तर समर्थित व्यवस्था नाही, आणि ते सडेल।
मार्गाला परवानगीपासून वेगळे करा
VPN मार्ग एक मार्ग निवडतो; आउटबाउंड नियम ठरवतात की त्या मार्गाला गंतव्यस्थानापर्यंत पोहोचता येईल का। हे वेगवेगळे नियंत्रण आहेत, आणि निरोगी टनेल दुसऱ्याबद्दल काहीही सांगत नाही। म्हणूनच एका नेटवर्कवरील एका वापरकर्त्यासाठी नकाशा अयशस्वी होऊ शकतो आणि त्याच खात्यावरील दुसऱ्या वापरकर्त्यासाठी कार्य करू शकतो। सेवेला दोष देण्यापूर्वी नियम आणि मार्ग स्वतंत्रपणे तपासा।
यादी अपूर्ण असल्यास कार्यप्रवाह अजूनही अयशस्वी होत असताना दोन्ही बरोबर असू शकतात।
घटक-दर-घटक पडताळणी करा, नंतर सूचीला मालक नियुक्त करा
अयशस्वी होणारी क्रिया पुनरुत्पादित करा आणि कोणता घटक अयशस्वी झाला ते नोंदवा: पोर्टल, टाइल, फीचर सेवा, डाउनलोड किंवा बाह्य सेवा। नंतर धोरणाचा एक घटक बदला आणि पुन्हा करा। टाइल्स सुधारणारा बदल विश्लेषण सेवांबद्दल तुम्हाला काहीही सांगत नाही। हीच घटक-निहाय नोंद पुढील प्रादेशिक अद्ययावत करण्याला अंदाजाच्या अजून एका फेरीऐवजी अवलंबित्व-बदलात बदलते। निदान URL कोठेही पेस्ट करण्यापूर्वी तपासा, कारण क्वेरी स्ट्रिंग टोकन आणि आयटम ओळखकर्ते वाहू शकते।
आवश्यकता सूचीला मालक आणि दस्तऐवजाच्या आवृत्तीशी जोडलेली पुनरावलोकन तारीख द्या। Esri स्टोरेज प्रदेश किंवा सेवा होस्ट जोडते तेव्हा तो मालक घटनेच्या वेळी त्रुटी शोधण्याऐवजी यादी पुन्हा चालवतो।