फायरवल अनुमति सूचीमा 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 ले भण्डारण क्षेत्र वा सेवा होस्ट थप्दा, त्यो मालिकले घटनाको क्रममा खाडल फेला पार्नुको सट्टा सूची फेरि चलाउँछ।