Jak ustawić domyślny obiekt główny dla podkatalogów dla witryny hostowanej statycznie w Cloudfront?

Jak ustawić domyślny obiekt główny dla podkatalogów w witrynie hostowanej statycznie w Cloudfront? W szczególności chciałbym www.example.com/subdir/index.htmlbyć obsługiwany za każdym razem, gdy poprosi o to użytkownik www.example.com/subdir. Uwaga: służy to dostarczaniu statycznej witryny internetowej przechowywanej w zasobniku S3. Ponadto chciałbym użyć tożsamości dostępu pochodzenia, aby ograniczyć dostęp do zasobnika S3 tylko do Cloudfront.

Teraz zdaję sobie sprawę, że Cloudfront działa inaczej niż S3 i stany amazon w szczególności :

Zachowanie domyślnych obiektów głównych CloudFront różni się od zachowania dokumentów indeksowych Amazon S3. Po skonfigurowaniu zasobnika Amazon S3 jako witryny internetowej i określeniu dokumentu indeksu Amazon S3 zwraca dokument indeksu, nawet jeśli użytkownik zażąda podkatalogu w zasobniku. (Kopia dokumentu indeksu musi znajdować się w każdym podkatalogu). Aby uzyskać więcej informacji na temat konfigurowania zasobników Amazon S3 jako witryn internetowych i dokumentów indeksowych, zobacz rozdział Hostowanie witryn internetowych na Amazon S3 w podręczniku programisty Amazon Simple Storage Service.

W związku z tym, mimo że Cloudfront pozwala nam określić domyślny obiekt główny, działa to tylko dla, www.example.coma nie dla www.example.com/subdir. Aby obejść tę trudność, możemy zmienić nazwę domeny pochodzenia tak, aby wskazywała punkt końcowy witryny internetowej podany przez S3. Działa to świetnie i umożliwia jednolite określanie obiektów głównych. Niestety wydaje się, że nie jest to zgodne z tożsamościami dostępu pochodzenia . W szczególności powyższe linki stanowią:

Zmień na tryb edycji:

Dystrybucje internetowe - kliknij kartę Początki, kliknij źródło, które chcesz edytować, i kliknij Edytuj. Możesz utworzyć tożsamość dostępu do źródła tylko dla źródeł, dla których Typ pochodzenia to S3 Origin.

Zasadniczo, aby ustawić prawidłowy domyślny obiekt główny, używamy punktu końcowego witryny S3, a nie samego zasobnika witryny. Nie jest to zgodne z używaniem tożsamości dostępu pochodzenia. Jako takie, moje pytania sprowadzają się do jednego z nich

1. Czy można określić domyślny obiekt główny dla wszystkich podkatalogów dla witryny hostowanej statycznie w Cloudfront?

2. Czy można skonfigurować tożsamość dostępu pochodzenia dla treści udostępnianej z Cloudfront, gdzie źródłem jest punkt końcowy witryny S3, a nie zasobnik S3?

AKTUALIZACJA: Wygląda na to, że się pomyliłem! Zobacz odpowiedź JBaczuka, która powinna być akceptowaną odpowiedzią w tym wątku.

Niestety, odpowiedź na oba pytania brzmi: nie.

1. Czy można określić domyślny obiekt główny dla wszystkich podkatalogów w witrynie hostowanej statycznie w Cloudfront?

Nie. Jak stwierdzono w dokumentacji AWS CloudFront ...

... Jeśli zdefiniujesz domyślny obiekt główny, żądanie użytkownika końcowego dotyczące podkatalogu Twojej dystrybucji nie zwróci domyślnego obiektu głównego. Na przykład załóżmy, że index.htmljest to domyślny obiekt główny i CloudFront odbiera żądanie użytkownika końcowego dotyczące katalogu instalacyjnego w Twojej dystrybucji CloudFront:

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

CloudFront nie zwróci domyślnego obiektu głównego, nawet jeśli kopia programu index.htmlpojawi się w katalogu instalacyjnym.

...

Zachowanie domyślnych obiektów głównych CloudFront różni się od zachowania dokumentów indeksowych Amazon S3. Po skonfigurowaniu zasobnika Amazon S3 jako witryny internetowej i określeniu dokumentu indeksu Amazon S3 zwraca dokument indeksu, nawet jeśli użytkownik zażąda podkatalogu w zasobniku. (Kopia dokumentu indeksu musi znajdować się w każdym podkatalogu).

2. Czy można skonfigurować tożsamość dostępu pochodzenia dla treści udostępnianej z Cloudfront, gdzie źródłem jest punkt końcowy witryny S3, a nie zasobnik S3?

Nie bezpośrednio. Twoje opcje początkowe w CloudFront to zasobniki S3 lub własny serwer.

Jednak to ta druga opcja otwiera kilka interesujących możliwości. To prawdopodobnie podważa cel tego, co próbujesz zrobić, ale możesz skonfigurować własny serwer, którego jedynym zadaniem jest być serwerem pochodzenia CloudFront.

Gdy nadejdzie żądanie dotyczące http://d111111abcdef8.cloudfront.net/install/ , CloudFront przekaże to żądanie do Twojego serwera pochodzenia, prosząc o /install. Możesz dowolnie konfigurować serwer pochodzenia, w tym do obsługi index.htmlw tym przypadku.

Możesz też napisać małą aplikację internetową, która po prostu odbiera to połączenie i i tak pobiera je bezpośrednio z S3.

Ale zdaję sobie sprawę, że skonfigurowanie własnego serwera i martwienie się o jego skalowanie może zniweczyć cel tego, co próbujesz zrobić.

Istnieje JEST sposób to zrobić. Zamiast kierować go do swojego zasobnika, wybierając go z listy rozwijanej (www.example.com.s3.amazonaws.com), wskaż statyczną domenę swojego zasobnika (np. Www.example.com.s3-website-us -west-2.amazonaws.com):

Dzięki wątku z tego forum AWS

Aktywacja hostingu S3 oznacza, że ​​musisz otworzyć wiadro na świat. W moim przypadku musiałem zachować prywatność zasobnika i użyć funkcji tożsamości pochodzenia, aby ograniczyć dostęp tylko do Cloudfront. Jak zasugerował @Juissi, funkcja Lambda może naprawić przekierowania:

'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);
};

Po opublikowaniu funkcji przejdź do dystrybucji w chmurze w konsoli AWS. Idź do Behaviors, następnie wybierz Origin Requestponiżej Lambda Function Associationsi na koniec wklej ARN do nowej funkcji.

Jest jeszcze jeden sposób na pobranie domyślnego pliku udostępnianego w podkatalogu, na przykład example.com/subdir/. Możesz faktycznie (programowo) przechowywać plik z kluczem subdir/w wiadrze. Ten plik nie pojawi się w konsoli zarządzania S3, ale faktycznie istnieje i CloudFront go obsłuży.

Obejściem tego problemu jest użycie lambda @ edge do ponownego zapisywania żądań. Wystarczy ustawić lambdę dla zdarzenia żądania przeglądarki w dystrybucji CloudFront i przepisać wszystko, co kończy się na „/” i nie jest równe „/” z domyślnym dokumentem głównym, np. Index.html.

Istnieje "oficjalny" przewodnik opublikowany na blogu AWS, który zaleca skonfigurowanie funkcji Lambda @ Edge uruchamianej przez Twoją dystrybucję CloudFront:

Oczywiście oczekiwanie, że użytkownicy zawsze wpisują index.html na końcu każdego adresu URL (lub nawet wiedzą, że powinien tam być), jest złym doświadczeniem użytkownika. Do tej pory nie było łatwego sposobu na udostępnienie użytkownikom tych prostszych adresów URL (odpowiednik dyrektywy DirectoryIndex w konfiguracji serwera internetowego Apache) za pośrednictwem CloudFront. Nie, jeśli nadal chcesz mieć możliwość ograniczenia dostępu do źródła S3 za pomocą OAI. Jednak wraz z wydaniem Lambda @ Edge można użyć funkcji JavaScript działającej na węzłach krawędziowych CloudFront, aby wyszukać te wzorce i zażądać odpowiedniego klucza obiektu ze źródła S3.

Rozwiązanie

W tym przykładzie używasz mocy obliczeniowej na krawędzi CloudFront do sprawdzania żądania przychodzącego od klienta. Następnie ponownie napisz żądanie, aby CloudFront zażądał domyślnego obiektu indeksu (w tym przypadku index.html) dla dowolnego identyfikatora URI żądania, który kończy się na „/”.

Gdy żądanie skierowane jest do serwera WWW, klient określa obiekt do uzyskania w żądaniu. Możesz użyć tego identyfikatora URI i zastosować do niego wyrażenie regularne, aby te identyfikatory URI zostały przetłumaczone na domyślny obiekt indeksu, zanim CloudFront zażąda obiektu od źródła. Użyj poniższego kodu:

'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);

};

Postępuj zgodnie z powyższym przewodnikiem, aby zobaczyć wszystkie kroki wymagane do skonfigurowania tego, w tym wiadro S3, dystrybucję CloudFront i tworzenie funkcji Lambda @ Edge .

Inną alternatywą dla używania lambda @ edge jest użycie stron błędów CloudFront. Skonfiguruj niestandardową odpowiedź na błąd, aby wysłać wszystkie 403 do określonego pliku. Następnie dodaj javascript do tego pliku, aby dołączyć index.html do adresów URL kończących się na /. Przykładowy kod:

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>");
}

Wiem, że to stare pytanie, ale sam się z tym zmagałem. Ostatecznie moim celem było mniej ustawienie domyślnego pliku w katalogu, a bardziej uzyskanie końcowego wyniku pliku, który był obsługiwany bez .htmlna końcu

Skończyło się na usunięciu .htmlz nazwy pliku i programowo / ręcznie ustawiłem typ MIME na text/html. Nie jest to tradycyjny sposób, ale wydaje się działać i spełnia moje wymagania dotyczące ładnych adresów URL, nie rezygnując z zalet cloudformation. Ustawienie typu mime jest denerwujące, ale moim zdaniem niewielka cena za korzyści