Kiedy używać protokołu HTTPS na potrzeby programowania lokalnego

Używanie http://localhost do programowania lokalnego jest zazwyczaj zalecane, z wyjątkiem niektórych szczególnych przypadków. Z tego posta dowiesz się, kiedy w lokalnej witrynie deweloperskiej musisz używać protokołu HTTPS.

Maud Nalpas

Zobacz też: jak używać protokołu HTTPS na potrzeby programowania lokalnego.

W tym poście stwierdzenia na temat localhost mają też zastosowanie w przypadku funkcji 127.0.0.1 i [::1], ponieważ oba opisują lokalny adres komputera, nazywany również „adresem w pętli”. Dla uproszczenia nie określono też numeru portu. Kiedy zobaczysz element http://localhost, odczytaj go jako http://localhost:{PORT} lub http://127.0.0.1:{PORT}.

Podsumowanie

Jeśli tworzysz aplikacje lokalnie, domyślnie używaj http://localhost. Skrypty Service Worker, interfejs Web Authentication API i inne będą działać. W tych przypadkach jednak potrzebujesz protokołu HTTPS na potrzeby programowania lokalnego:

• Konfigurowanie bezpiecznych plików cookie w spójny sposób w różnych przeglądarkach
• Debugowanie problemów z treścią mieszaną
• Korzystanie z HTTP/2 i nowszych
• korzystanie z bibliotek lub interfejsów API innych firm, które wymagają protokołu HTTPS;

• Korzystanie z niestandardowej nazwy hosta

  

✨ To wszystko, co musisz wiedzieć. Jeśli chcesz dowiedzieć się więcej, czytaj dalej.

Dlaczego witryna dla programistów powinna działać bezpiecznie

Aby uniknąć niespodziewanych problemów, zadbaj, by lokalna witryna deweloperska działała jak witryna produkcyjna. Jeśli więc Twoja witryna produkcyjna korzysta z protokołu HTTPS, chcesz, by lokalna witryna deweloperska działała tak jak witryna HTTPS.

Używaj domyślnie: http://localhost

Przeglądarki traktują dyrektywę http://localhost w specjalny sposób: mimo że protokół HTTP zachowuje się przeważnie jak strona HTTPS.

W http://localhost mechanizmy Service Worker, Sensor API, Authentication API, Payments i innych funkcji, które wymagają określonych gwarancji bezpieczeństwa, są obsługiwane i działają tak samo jak w witrynie HTTPS.

Kiedy używać protokołu HTTPS na potrzeby programowania lokalnego

Może się zdarzyć, że http://localhost nie będzie działać jak witryna HTTPS. Możesz też po prostu użyć niestandardowej nazwy witryny innej niż http://localhost.

W tych przypadkach musisz użyć protokołu HTTPS na potrzeby programowania lokalnego:

• Musisz ustawić lokalnie plik cookie. Ma on format Secure, SameSite:none lub prefiks __Host. Pliki cookie Secure są ustawiane tylko przez HTTPS, ale nie w http://localhost we wszystkich przeglądarkach. A ponieważ pliki SameSite:none i __Host również wymagają, aby plik cookie miał ustawienie Secure, ustawienie takich plików w lokalnej witrynie dla programistów również wymaga protokołu HTTPS.

• Musisz debugować lokalnie problem, który występuje tylko w witrynie HTTPS, a nie w witrynie HTTP, nawet w http://localhost. Przykładem może być problem z mieszaną treścią.

• Musisz przeprowadzić test lokalny lub odtworzyć działanie typowe dla protokołu HTTP/2 lub nowszego. Możesz na przykład przetestować wydajność wczytywania stron przez protokół HTTP/2 lub nowszy. Niezabezpieczony protokół HTTP/2 lub nowszy (nawet w localhost) nie jest obsługiwany.

• Musisz przetestować biblioteki innych firm lub interfejsy API, które wymagają protokołu HTTPS (na przykład OAuth).

• Nie używasz nazwy localhost, a niestandardowej nazwy hosta na potrzeby programowania lokalnego, na przykład mysite.example. Zwykle oznacza to zastąpienie lokalnego pliku hosts:

  

  W tym przypadku Chrome, Edge, Safari i Firefox domyślnie nie uznają mysite.example za bezpieczne, chociaż jest to witryna lokalna. Nie będzie więc działać jak witryna HTTPS.

• Inne przypadki! Ta lista nie jest wyczerpująca, ale jeśli natrafisz na przypadek, którego nie ma na tej liście, będziesz wiedzieć, że http://localhost zacznie działać nieprawidłowo lub witryna przestanie działać. 🙃

We wszystkich tych przypadkach musisz używać protokołu HTTPS na potrzeby programowania lokalnego.

Jak używać protokołu HTTPS na potrzeby programowania lokalnego

Jeśli musisz używać protokołu HTTPS na potrzeby programowania lokalnego, zapoznaj się z artykułem Jak używać protokołu HTTPS na potrzeby programowania lokalnego.

Wskazówki dotyczące używania niestandardowej nazwy hosta

Jeśli używasz niestandardowej nazwy hosta, na przykład podczas edytowania pliku hosts:

• Nie używaj samej nazwy hosta, takiej jak mysite, ponieważ jeśli istnieje domena najwyższego poziomu (TLD), która ma taką samą nazwę (mysite), mogą wystąpić problemy. To mało prawdopodobne: w 2020 roku istnieje ponad 1500 domen najwyższego poziomu, a ich lista stale się powiększa. coffee, museum, travel i wiele dużych firm (być może nawet firma, w której pracujesz) to domeny najwyższego poziomu. Pełną listę znajdziesz tutaj
• Używaj tylko domen, które należą do Ciebie lub są zarezerwowane do tego celu. Jeśli nie masz własnej domeny, możesz użyć test lub localhost (mysite.localhost). test nie jest traktowana specjalnie w przeglądarkach, ale localhost tak: Chrome i Edge od razu obsługują http://<name>.localhost i działa bezpiecznie, gdy host lokalny tak się stanie. Wypróbuj: uruchom dowolną stronę na lokalnym hoście i uzyskaj dostęp do http://<whatever name you like>.localhost:<your port> w Chrome lub Edge. Wkrótce ta funkcja będzie też dostępna w przeglądarkach Firefox i Safari. Jest to możliwe (ma subdomeny takie jak mysite.localhost), ponieważ localhost jest nie tylko nazwą hosta, ale także pełną domeną najwyższego poziomu, np. com.

Więcej informacji

• Bezpieczne konteksty
• localhost jako bezpieczny kontekst
• localhost jako bezpieczny kontekst w Chrome

Dziękujemy za publikowanie treści i przekazywanie opinii wszystkim weryfikatorom – w szczególności Ryan Sleevi, Filippo Valsorda, Milica Mihajlija, Rowan Merewood i Jake Archibald. 🙌

Baner powitalny od: @moses_lee, film Unsplash, edytowany.