क्लाउडफ्रंट पर वैधानिक रूप से होस्ट की गई वेबसाइट के लिए उपनिर्देशिकाओं के लिए डिफ़ॉल्ट रूट ऑब्जेक्ट कैसे सेट करते हैं?


100

क्लाउडफ्रंट पर वैधानिक रूप से होस्ट की गई वेबसाइट पर उपनिर्देशिकाओं के लिए डिफ़ॉल्ट रूट ऑब्जेक्ट कैसे सेट करते हैं? विशेष रूप से, www.example.com/subdir/index.htmlजब भी उपयोगकर्ता पूछेगा , मैं उसे परोसा जाना चाहूंगा www.example.com/subdir। ध्यान दें, यह S3 बाल्टी में रखी गई स्थैतिक वेबसाइट को डिलीवर करने के लिए है। इसके अलावा, मैं केवल क्लाउडफ्रंट के लिए S3 बाल्टी तक पहुंच को प्रतिबंधित करने के लिए एक मूल पहुंच पहचान का उपयोग करना चाहूंगा।

अब, मुझे पता है कि क्लाउडफ्रंट S3 और अमेजन राज्यों से अलग काम करता है :

CloudFront की डिफ़ॉल्ट रूट ऑब्जेक्ट का व्यवहार Amazon S3 इंडेक्स दस्तावेज़ों के व्यवहार से अलग है। जब आप Amazon S3 बाल्टी को एक वेबसाइट के रूप में कॉन्फ़िगर करते हैं और इंडेक्स डॉक्यूमेंट को निर्दिष्ट करते हैं, तो Amazon S3 इंडेक्स डॉक्यूमेंट लौटाता है, भले ही उपयोगकर्ता बाल्टी में एक उपनिर्देशिका का अनुरोध करता हो। (अनुक्रमणिका दस्तावेज़ की एक प्रति प्रत्येक उपनिर्देशिका में दिखाई देनी चाहिए।) अमेज़ॅन एस 3 बाल्टी को वेबसाइटों के रूप में और सूचकांक दस्तावेज़ों के बारे में अधिक जानकारी के लिए, अमेज़ॅन सरल संग्रहण सेवा डेवलपर गाइड में अमेज़ॅन एस 3 अध्याय पर होस्टिंग वेबसाइटें देखें।

जैसे, भले ही Cloudfront हमें डिफ़ॉल्ट रूट ऑब्जेक्ट निर्दिष्ट करने की अनुमति देता है, यह केवल इसके लिए काम करता है www.example.comऔर इसके लिए नहीं www.example.com/subdir। इस कठिनाई को प्राप्त करने के लिए, हम मूल डोमेन नाम को S3 द्वारा दी गई वेबसाइट एंडपॉइंट पर इंगित कर सकते हैं। यह महान काम करता है और रूट ऑब्जेक्ट को समान रूप से निर्दिष्ट करने की अनुमति देता है। दुर्भाग्य से, यह मूल अभिगम पहचान के साथ अनुकूल नहीं प्रतीत होता है । विशेष रूप से, उपरोक्त लिंक बताता है:

संपादन मोड में बदलें:

वेब वितरण - मूल टैब पर क्लिक करें, उस मूल पर क्लिक करें जिसे आप संपादित करना चाहते हैं, और संपादित करें पर क्लिक करें। आप केवल उत्पत्ति के लिए एक मूल पहुंच पहचान बना सकते हैं जिसके लिए उत्पत्ति प्रकार S3 मूल है।

मूल रूप से, सही डिफॉल्ट रूट ऑब्जेक्ट सेट करने के लिए, हम S3 वेबसाइट एंडपॉइंट का उपयोग करते हैं न कि वेबसाइट की बकेट का। यह मूल अभिगम पहचान का उपयोग करने के साथ संगत नहीं है। जैसे, मेरे सवाल या तो उबलते हैं

  1. क्या क्लाउडफ्रंट पर वैधानिक रूप से होस्ट की गई वेबसाइट के लिए सभी उपनिर्देशिकाओं के लिए एक डिफ़ॉल्ट रूट ऑब्जेक्ट निर्दिष्ट करना संभव है?

  2. क्या यह संभव है कि क्लाउडफ्रंट से प्राप्त सामग्री के लिए एक मूल अभिगम पहचान को सेटअप किया जाए जहां मूल एक S3 वेबसाइट समापन बिंदु है और S3 बाल्टी नहीं है?


1
मुझे लगता है कि यह अब लैम्ब्डा @ एज के साथ संभव है, एक फ़ंक्शन का उपयोग करके जो सभी URL को / toindex.html पर समाप्त होने वाले रीडायरेक्ट करता है। मैं इसे अपनी वेबसाइट पर आज़माऊंगा और परिणामों की रिपोर्ट करूंगा और विस्तृत कॉन्फ़िगरेशन को उत्तर के रूप में पोस्ट करूंगा।
क्रिस्टियन मागेरुएन-स्टैनसीयू

जवाबों:


2

अद्यतन करें: ऐसा लगता है कि मैं गलत था! JBaczuk का उत्तर देखें, जो इस सूत्र पर स्वीकृत उत्तर होना चाहिए।

दुर्भाग्य से, आपके दोनों सवालों का जवाब नहीं है।

1. क्या क्लाउडफ्रंट पर वैधानिक रूप से होस्ट की गई वेबसाइट के लिए सभी उपनिर्देशिकाओं के लिए एक डिफ़ॉल्ट रूट ऑब्जेक्ट निर्दिष्ट करना संभव है?

AWS क्लाउडफ़ोर्स डॉक्स में कहा गया है ...

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

http://d111111abcdef8.cloudfront.net/install/

CloudFront एक कॉपी होने पर भी डिफ़ॉल्ट रूट ऑब्जेक्ट को वापस नहीं करेगी index.html डायरेक्‍टर में दिखाई देने पर ।

...

CloudFront की डिफ़ॉल्ट रूट ऑब्जेक्ट का व्यवहार Amazon S3 इंडेक्स दस्तावेज़ों के व्यवहार से अलग है। जब आप Amazon S3 बाल्टी को वेबसाइट के रूप में कॉन्फ़िगर करते हैं और इंडेक्स डॉक्यूमेंट को निर्दिष्ट करते हैं, तो Amazon S3 इंडेक्स डॉक्यूमेंट लौटाता है, भले ही उपयोगकर्ता बाल्टी में एक उपनिर्देशिका का अनुरोध करता हो। (सूचकांक दस्तावेज़ की एक प्रति प्रत्येक उपनिर्देशिका में दिखाई देनी चाहिए।)

2. क्या क्लाउडफ्रंट से प्राप्त सामग्री के लिए एक मूल पहुंच पहचान को सेटअप करना संभव है जहां मूल एक S3 वेबसाइट एंडपॉइंट है न कि S3 बाल्टी?

प्रत्यक्ष नहीं। CloudFront के साथ उत्पत्ति के लिए आपके विकल्प S3 बाल्टी या आपके स्वयं के सर्वर हैं।

यह दूसरा विकल्प है जो कुछ दिलचस्प संभावनाओं को खोलता है, हालांकि। यह संभवतः उस उद्देश्य को हरा देता है जो आप करने की कोशिश कर रहे हैं, लेकिन आप अपने स्वयं के सर्वर को सेट कर सकते हैं जिसका एकमात्र काम क्लाउडफ्रंट मूल सर्वर होना है।

जब http://d111111abcdef8.cloudfront.net/install/ के लिए कोई अनुरोध आता है , तो CloudFront इस अनुरोध को आपके मूल सर्वर के लिए भेजेगा, जिसके लिए आप पूछ रहे हैं /install। आप अपने मूल सर्वर को कॉन्फ़िगर कर सकते हैं, हालांकि आप सेवा करना चाहते हैंindex.html इस मामले में ।

या आप एक छोटा सा वेब ऐप लिख सकते हैं जो सिर्फ इस कॉल को लेता है और इसे वैसे भी सीधे S3 से प्राप्त करता है।

लेकिन मुझे लगता है कि अपना सर्वर स्थापित करना और इसे बढ़ाने के बारे में चिंता करना इस उद्देश्य को हरा सकता है कि आप पहले स्थान पर क्या करने की कोशिश कर रहे हैं।


इसके साथ एक समस्या यह है कि इसे काम करने के लिए प्राप्त करें इसका मतलब है कि आपके पास s3 पर दो (2) URL हैं जो आपकी वेब साइट तक पहुँचने में सक्षम हैं। आपका क्लाउड फ्रंट URL और आपका s3 url (bucket_name.s3-website-us-east-1.amazonaws.com)
हेडन

223

वहाँ है यह करने के लिए एक तरीका है। ड्रॉपडाउन (www.example.com.s3.amazonaws.com) में इसे चुनकर अपनी बाल्टी पर इंगित करने के बजाय, इसे अपनी बाल्टी के स्थिर डोमेन (जैसे www.example.com.s3-website-us) पर इंगित करें। -west-2.amazonaws.com):

यहां छवि विवरण दर्ज करें

इस AWS फोरम थ्रेड के लिए धन्यवाद


6
किसी को पता है कि अगर यह s3 मूल बनाम एक वेब मूल होने पर अलग-अलग चार्ज करता है?
फिडेलॉपर

3
क्या यह ठीक है अगर मैं अपनी पूरी वेबसाइट और फ़ाइलों को HTTPSकेवल सेवा करना चाहता हूं ?
मंजीत कुमार

3
क्या इसका मतलब है कि S3 को वेब सर्वर के रूप में सक्षम होना चाहिए?
एंथनी काँग

6
ओपी ने स्पष्ट रूप से इस दृष्टिकोण को उसके लिए काम नहीं कहा: "इस कठिनाई के आसपास पाने के लिए, हम मूल डोमेन नाम को S3 द्वारा दी गई वेबसाइट एंडपॉइंट की ओर इंगित कर सकते हैं। यह बहुत अच्छा काम करता है और रूट ऑब्जेक्ट को समान रूप से निर्दिष्ट करने की अनुमति देता है। दुर्भाग्य से।" , यह मूल अभिगम पहचान के साथ अनुकूल नहीं प्रतीत होता है "। AWS खुद को इसके लिए lamda @ एज की सिफारिश करता दिख रहा है - aws.amazon.com/blogs/compute/…
icyitscold

3
यह संगत क्लाउड फ्रंट नहीं है - ओरिजिन एक्सेस एक्सेस आइडेंटिटी। आप इस तरह से अपने S3 बाल्टी तक पहुंच को प्रतिबंधित नहीं कर पाएंगे।
रॉकेट्सपर्नर

15

S3 होस्टिंग को सक्रिय करने का मतलब है कि आपको दुनिया को बाल्टी खोलनी है। मेरे मामले में, मुझे बाल्टी को निजी रखने और केवल क्लाउडफ्रंट तक पहुंच को प्रतिबंधित करने के लिए मूल पहुंच पहचान कार्यक्षमता का उपयोग करने की आवश्यकता थी। जैसे @ जूसी ने सुझाव दिया, एक लैंबडा फ़ंक्शन रीडायरेक्ट को ठीक कर सकता है:

'use strict';

/**
 * Redirects URLs to default document. Examples:
 *
 * /blog            -> /blog/index.html
 * /blog/july/      -> /blog/july/index.html
 * /blog/header.png -> /blog/header.png
 *
 */

let defaultDocument = 'index.html';

exports.handler = (event, context, callback) => {
    const request = event.Records[0].cf.request;

    if(request.uri != "/") {
        let paths = request.uri.split('/');
        let lastPath = paths[paths.length - 1];
        let isFile = lastPath.split('.').length > 1;

        if(!isFile) {
            if(lastPath != "") {
                request.uri += "/";
            }

            request.uri += defaultDocument;
        }

        console.log(request.uri);
    }

    callback(null, request);
};

अपना कार्य प्रकाशित करने के बाद, AWS कंसोल में अपने क्लाउडफ्रंट वितरण पर जाएँ। पर जाएं Behaviors, फिर चुनें Origin Requestके तहत Lambda Function Associations, और अंत में अपने नए कार्य करने के लिए ARN पेस्ट करें।



यहां समस्या यह है कि इस फ़ंक्शन को हमें पूर्व-पूर्व -1 में तैनात करने की आवश्यकता है, इसलिए यदि आपके पास सख्त जीडीपीआर विनियमन के तहत एक कंपनी है जो जर्मनी के बाहर एक बिट की अनुमति नहीं देती है तो यह आपके लिए नहीं है।
रेनो गामा

5

उपनिर्देशिका में एक डिफ़ॉल्ट फ़ाइल प्राप्त करने का एक और तरीका है, जैसे example.com/subdir/। आप वास्तव में (प्रोग्रामेटिक रूप से) subdir/बाल्टी में कुंजी के साथ एक फ़ाइल स्टोर कर सकते हैं । यह फ़ाइल S3 प्रबंधन कंसोल में दिखाई नहीं देगी , लेकिन यह वास्तव में मौजूद है, और क्लाउडफ्रंट इसकी सेवा देगा।


एस 3 सबडिर / सबडिर में परिवर्तित; जब आप HTML अपलोड करने का प्रयास करते हैं। इसके अलावा, जब आप example.com/subdir/ पर पहुंचने का प्रयास करते हैं, तो यह विफल हो जाता है, और यदि आप example.com/subdir तक पहुंचने का प्रयास करते हैं; यह HTML फ़ाइल डाउनलोड करने के बजाय इसे डाउनलोड करता है।
जैकोबफॉग

4

समस्या को हल करने के लिए अनुरोध को फिर से लिखने के लिए lambda @ बढ़त का उपयोग करना है। CloudFront वितरण के अनुरोध अनुरोध ईवेंट के लिए एक लैम्ब्डा को सेटअप करने की आवश्यकता है और सब कुछ फिर से लिखना है जो '/' के साथ समाप्त होता है और डिफ़ॉल्ट रूट डॉक्यूमेंट जैसे index.html के साथ '/' के बराबर नहीं है।


इस दृष्टिकोण के बारे में अधिक जानकारी यहाँ: aws.amazon.com/blogs/compute/…
हेनरिक एल्ड सोरेंसन

दुर्भाग्य से लैम्ब्डा @ एज केवल हम-पूर्व -1 क्षेत्र पर काम करता है, स्रोत: github.com/awslabs/serverless-application-model/issues/635
mruanova 21

4

AWS ब्लॉग पर एक "आधिकारिक" मार्गदर्शिका प्रकाशित हुई है जो आपके क्लाउड वितरण द्वारा ट्रिगर किए गए लंबो @ एज फ़ंक्शन को स्थापित करने की अनुशंसा करती है:

बेशक, यह एक बुरा उपयोगकर्ता अनुभव है जो उपयोगकर्ताओं को हमेशा हर URL के अंत में index.html टाइप करने की उम्मीद करता है (या यह भी जानता है कि यह वहाँ होना चाहिए)। अब तक, उपयोगकर्ताओं को CloudFront के माध्यम से इन सरल URL (Apache वेब सर्वर कॉन्फ़िगरेशन में DirectoryIndex निर्देश के बराबर) प्रदान करने का एक आसान तरीका नहीं है। यदि आप अभी भी एक OAI का उपयोग कर S3 मूल तक पहुँच को प्रतिबंधित करने में सक्षम होना चाहते हैं। हालाँकि, लैम्ब्डा @ एज की रिलीज़ के साथ, आप इन पैटर्नों को देखने के लिए CloudFront एज नोड्स पर चल रहे एक जावास्क्रिप्ट फ़ंक्शन का उपयोग कर सकते हैं और S3 मूल से उपयुक्त ऑब्जेक्ट कुंजी का अनुरोध कर सकते हैं।

उपाय

इस उदाहरण में, आप क्लाइंट से आने वाले अनुरोध का निरीक्षण करने के लिए CloudFront किनारे पर गणना शक्ति का उपयोग करते हैं। फिर अनुरोध को फिर से लिखें ताकि CloudFront किसी भी अनुरोध URI के लिए एक डिफ़ॉल्ट सूचकांक ऑब्जेक्ट (index.html इस मामले में) का अनुरोध करता है जो '/' में समाप्त होता है।

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

'use strict';
exports.handler = (event, context, callback) => {

    // Extract the request from the CloudFront event that is sent to Lambda@Edge
    var request = event.Records[0].cf.request;

    // Extract the URI from the request
    var olduri = request.uri;

    // Match any '/' that occurs at the end of a URI. Replace it with a default index
    var newuri = olduri.replace(/\/$/, '\/index.html');

    // Log the URI as received by CloudFront and the new URI to be used to fetch from origin
    console.log("Old URI: " + olduri);
    console.log("New URI: " + newuri);

    // Replace the received URI with the URI that includes the index page
    request.uri = newuri;

    // Return to CloudFront
    return callback(null, request);

};

S3 बाल्टी, CloudFront वितरण और Lambda @ एज फ़ंक्शन निर्माण सहित, इसे स्थापित करने के लिए आवश्यक सभी चरणों को देखने के लिए ऊपर दिए गए मार्गदर्शिका का पालन करें ।


2

लैम्ब्डा @ एज का उपयोग करने का एक अन्य विकल्प क्लाउडफ्रंट के त्रुटि पृष्ठों का उपयोग करना है। सभी 403 के विशिष्ट फ़ाइल में भेजने के लिए एक कस्टम त्रुटि प्रतिक्रिया सेट करें । फिर उस फ़ाइल के लिए जावास्क्रिप्ट को जोड़कर index.html को url में जोड़ने के लिए / a में समाप्त करें। नमूना कोड:

if ((window.location.href.endsWith("/") && !window.location.href.endsWith(".com/"))) {
    window.location.href = window.location.href + "index.html";
}
else {
    document.write("<Your 403 error message here>");
}

1

मुझे पता है कि यह एक पुराना सवाल है, लेकिन मैं सिर्फ अपने आप से संघर्ष करता हूं। अंततः मेरा लक्ष्य एक निर्देशिका में एक डिफ़ॉल्ट फ़ाइल सेट करने के लिए कम था, और एक फ़ाइल के अंतिम परिणाम के लिए अधिक था .htmlजो इसके अंत में बिना सेवा के था

मैं .htmlफ़ाइल नाम और प्रोग्राम से हटाने के समाप्त हो गया / मैन्युअल रूप से माइम प्रकार सेट करने के लिए text/html। यह पारंपरिक तरीका नहीं है, लेकिन यह काम करने लगता है, और क्लाउडफॉर्म के लाभों का त्याग किए बिना सुंदर यूआरएल के लिए मेरी आवश्यकताओं को संतुष्ट करता है। माइम प्रकार सेट करना कष्टप्रद है, लेकिन मेरी राय में लाभ के लिए भुगतान करने के लिए एक छोटी सी कीमत

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.