Jakie szczegóły techniczne powinien rozważyć programista aplikacji internetowej przed upublicznieniem strony?

Jakie rzeczy powinien rozważyć programista wdrażający szczegóły techniczne aplikacji internetowej przed upublicznieniem strony? Jeśli Jeff Atwood można zapomnieć o HttpOnly ciasteczka , mapy witryn , oraz cross-site request fałszerstw wszystkie w tym samym miejscu , co ważne, co mogę być zapominając, jak również?

Myślę o tym z perspektywy programisty, tak, że ktoś inny tworzy rzeczywisty projekt i treść witryny. Tak więc, chociaż użyteczność i treść mogą być ważniejsze niż platforma, Ty, programista, nie masz wiele do powiedzenia. Musisz się martwić, że implementacja platformy jest stabilna, działa dobrze, jest bezpieczna i spełnia wszelkie inne cele biznesowe (np. Nie kosztuje zbyt wiele, zajmuje zbyt dużo czasu, a także pozycjonuje się w Google jako obsługa treści).

Pomyśl o tym z perspektywy programisty, który wykonał prace dla aplikacji typu intranet w dość zaufanym środowisku, i ma zamiar po raz pierwszy wypróbować potencjalnie popularną witrynę dla całej dużej złej sieci.

Ponadto szukam czegoś bardziej konkretnego niż tylko niejasną odpowiedź na „standardy sieciowe”. Chodzi mi o to, że HTML, JavaScript i CSS przez HTTP są praktycznie pewne, szczególnie gdy już określiłem, że jesteś profesjonalnym programistą. Tak dzieje poza tym, Które normy? W jakich okolicznościach i dlaczego? Podaj link do specyfikacji standardu.

Chodzi o to, że większość z nas powinna już wiedzieć większość z tej listy. Ale może istnieć jeden lub dwa przedmioty, na które tak naprawdę nigdy nie zaglądałeś, nie do końca rozumiesz, a może nawet o nich nie słyszałeś.

Interfejs i wrażenia użytkownika

• Pamiętaj, że przeglądarki niekonsekwentnie wdrażają standardy i upewnij się, że witryna działa w miarę dobrze we wszystkich głównych przeglądarkach. Przy minimalnym teście z najnowszym silnikiem Gecko ( Firefox ), silnikiem WebKit ( Safari i niektórymi przeglądarkami mobilnymi), Chrome , obsługiwanymi przeglądarkami IE (skorzystaj z obrazów VPC kompatybilności aplikacji ) i Opera . Zastanów się także, jak przeglądarki renderują Twoją witrynę w różnych systemach operacyjnych.
• Zastanów się, w jaki sposób ludzie mogą korzystać z witryny inaczej niż z głównych przeglądarek: na przykład telefonów komórkowych, czytników ekranu i wyszukiwarek. - Niektóre informacje dostępność: WAI i Section508 , rozwój komórkowy: MobiForge .
• Inscenizacja: jak wdrażać aktualizacje bez wpływu na użytkowników. Mieć jedno lub więcej środowisk testowych lub testowych, aby wdrożyć zmiany w architekturze, kodzie lub obszernej zawartości i zapewnić, że można je wdrożyć w kontrolowany sposób, nie niszcząc niczego. Zautomatyzuj sposób wdrażania zatwierdzonych zmian w działającej witrynie. Jest to najskuteczniej realizowane w połączeniu z systemem kontroli wersji (git, Subversion itp.) I mechanizmem automatycznej kompilacji (Ant, NAnt itp.).
• Nie wyświetlaj nieprzyjaznych błędów bezpośrednio użytkownikowi.
• Nie umieszczaj adresów e-mail użytkowników zwykłym tekstem, ponieważ zostaną spamowani na śmierć.
• Dodaj atrybut rel="nofollow"do linków generowanych przez użytkowników, aby uniknąć spamu .
• Wprowadź w swojej witrynie przemyślane ograniczenia - należy to również do działu Bezpieczeństwo.
• Dowiedz się, jak robić stopniowe ulepszenia .
• Przekieruj po POST, jeśli ten POST się powiódł, aby zapobiec ponownemu przesłaniu odświeżenia.
• Nie zapomnij wziąć pod uwagę dostępności. To zawsze dobry pomysł, aw niektórych okolicznościach wymóg prawny . WAI-ARIA i WCAG 2 to dobre zasoby w tej dziedzinie.
• Przeczytaj Nie każ mi myśleć .

Bezpieczeństwo

• To dużo do strawienia, ale przewodnik programistyczny OWASP obejmuje bezpieczeństwo witryny sieci Web od góry do dołu.
• Wiedzieć o iniekcji, szczególnie iniekcji SQL i jak temu zapobiec.
• Nigdy nie ufaj wkładowi użytkowników ani niczego innego, co pojawia się w żądaniu (w tym plików cookie i ukrytych wartości pól formularza!).
• Mieszaj hasła przy użyciu soli i używaj różnych soli do swoich wierszy, aby zapobiec atakom tęczy. Do przechowywania haseł używaj algorytmu powolnego mieszania, takiego jak bcrypt (testowany w czasie) lub scrypt (jeszcze silniejszy, ale nowszy) ( 1 , 2 ). ( Jak bezpiecznie przechowywać hasło ). NIST zatwierdza również PBKDF2 hash hasła ”, a to FIPS zatwierdzone w .NET (więcej informacji tutaj ). Należy unikać bezpośredniego używania MD5 lub SHA rodziny.
• Nie próbuj wymyślić własnego wymyślnego systemu uwierzytelniania . To taka łatwa rzecz do dostać złego w subtelny i nieweryfikowalnych sposobów i nawet nie wiem, aż po jesteś posiekany.
• Znać zasady przetwarzania kart kredytowych . ( Zobacz także to pytanie )
• Używaj SSL / TLS / HTTPS do witryn, na których wprowadzane są wrażliwe dane (takie jak dane uwierzytelniające, dane osobowe, informacje o karcie kredytowej). Let's Encrypt to bezpłatny urząd certyfikacji, który może pomóc.
• Zapobiegaj przejęciu sesji .
• Unikaj skryptów krzyżowych (XSS).
• Unikaj fałszowania żądań w różnych witrynach (CSRF).
• Unikaj Clickjacking .
• Aktualizuj swój system (systemy) za pomocą najnowszych poprawek.
• Upewnij się, że informacje o połączeniu z bazą danych są zabezpieczone.
• Bądź na bieżąco z najnowszymi technikami ataku i podatnościami na twoją platformę.
• Przeczytaj Podręcznik bezpieczeństwa przeglądarki Google .
• Przeczytaj Podręcznik hakera aplikacji sieci Web .
• Rozważ zasadę najmniejszych przywilejów . Spróbuj uruchomić serwer aplikacji jako użytkownik inny niż root . ( przykład tomcat )
• Umieść rel="noopener noreferrer"wszystkie linki podane przez użytkownika, target="_blank"aby zapobiec przekierowywaniu strony przez JavaScript na stronę docelową w inne miejsce, na przykład na fałszywą stronę logowania. Więcej informacji
• Rozważ zastosowanie ścisłej Polityki bezpieczeństwa treści .

Występ

• W razie potrzeby zaimplementuj buforowanie, poprawnie zrozum i używaj buforowania HTTP, a także manifestu HTML5 .
• Optymalizuj obrazy - nie używaj obrazu o wielkości 20 KB dla powtarzającego się tła.
• Kompresuj zawartość dla prędkości, patrz brotli , gzip / deflate ( deflacja jest lepsza ).
• Łącz / łącz wiele arkuszy stylów lub wiele plików skryptów, aby zmniejszyć liczbę połączeń przeglądarki i poprawić zdolność gzip do kompresji duplikatów między plikami.
• Zajrzyj na stronę Yahoo Exceptional Performance , wiele świetnych wskazówek, w tym poprawę wydajności front-endu i ich narzędzia YSlow (wymaga Firefox, Safari, Chrome lub Opera). Również prędkość stronę Google (użyj z rozszerzeniem przeglądarki ) jest kolejnym narzędziem do profilowania wydajności i optymalizuje obrazy zbyt.
• Użyj duszka obrazu CSS dla małych powiązanych obrazów, takich jak paski narzędzi (patrz punkt „Minimalizuj żądania HTTP”)
• Użyj duszków obrazów SVG do małych powiązanych obrazów, takich jak paski narzędzi. Kolorowanie SVG jest nieco trudne. Możesz przeczytać o tym tutaj .
• Zajęte witryny internetowe powinny rozważyć podział komponentów między domeny . Konkretnie...
• Treść statyczna (tj. Obrazy, CSS, JavaScript i ogólnie treść, która nie potrzebuje dostępu do plików cookie) powinna znajdować się w osobnej domenie , która nie korzysta z plików cookie , ponieważ wszystkie pliki cookie dla domeny i jej poddomen są wysyłane z każdym żądaniem do domena i jej poddomeny. Jedną dobrą opcją jest skorzystanie z sieci dostarczania treści (CDN), ale rozważ przypadek, w którym ta sieć CDN może zawieść, włączając alternatywne sieci CDN lub lokalne kopie, które można zamiast tego podać.
• Zminimalizuj całkowitą liczbę żądań HTTP wymaganych do wyświetlenia strony przez przeglądarkę.
• Wybierz silnik szablonów i renderuj / wstępnie skompiluj go za pomocą programów uruchamiających zadania, takich jak gulp lub chrząknięcie
• Upewnij się, że favicon.icow katalogu głównym witryny znajduje się plik, tj /favicon.ico. Przeglądarki automatycznie zażądają tego , nawet jeśli ikona nie jest w ogóle wymieniona w kodzie HTML. Jeśli nie masz /favicon.ico, spowoduje to wiele 404, zmniejszając przepustowość serwera.

SEO (Search Engine Optimization)

• Użyj adresów URL „przyjaznych dla wyszukiwarek”, tzn. Użyj example.com/pages/45-article-titlezamiastexample.com/index.php?page=45
• Podczas korzystania #z zawartością dynamiczną zmianę #celu #!, a następnie na serwerze $_REQUEST["_escaped_fragment_"], co Googlebot używa zamiast #!. Innymi słowy, ./#!page=1staje się ./?_escaped_fragments_=page=1. Również dla użytkowników korzystających z FF.b4 lub Chromium history.pushState({"foo":"bar"}, "About", "./?page=1");to świetne polecenie. Więc nawet jeśli pasek adresu się zmienił, strona się nie ładuje. To pozwala ci używać ?zamiast #!utrzymywać dynamiczną zawartość, a także poinformować serwer, gdy prześlesz e-mailem link, że jesteśmy po tej stronie, a AJAX nie musi wysyłać kolejnego dodatkowego żądania.
• Nie używaj linków z napisem „kliknij tutaj” . Marnujesz szansę na SEO, a to utrudnia pracę osobom z czytnikami ekranu.
• Przygotuj mapę witryny XML , najlepiej w domyślnej lokalizacji /sitemap.xml.
• Użyj, <link rel="canonical" ... />gdy masz wiele adresów URL wskazujących na tę samą treść, ten problem można również rozwiązać w Narzędziach Google dla webmasterów .
• Użyj Narzędzi Google dla webmasterów i Narzędzi dla webmasterów Bing .
• Zainstaluj Google Analytics od samego początku (lub narzędzie do analizy typu open source, takie jak Piwik ).
• Dowiedz się, jak działają pliki robots.txt i wyszukiwarek.
• Przekierować żądania (za pomocą 301 Moved Permanently) domagając www.example.comsię example.com(lub na odwrót), aby zapobiec rozdzieleniu google ranking między obu stronach.
• Wiedz, że mogą tam być źle wychowane pająki.
• Jeśli masz treść nietekstową, zajrzyj do rozszerzeń mapy witryny Google dla wideo itp. Jest kilka dobrych informacji na ten temat w odpowiedzi Tima Farleya .

Technologia

• Poznaj HTTP i takie rzeczy jak GET, POST, sesje, pliki cookie i co to znaczy być „bezstanowym”.
• Napisz XHTML / HTML i CSS zgodnie ze specyfikacjami W3C i upewnij się, że są poprawne . Celem jest uniknięcie trybów dziwactwa w przeglądarkach, a dodatkowo znacznie ułatwia pracę z nietradycyjnymi przeglądarkami, takimi jak czytniki ekranu i urządzenia mobilne.
• Dowiedz się, jak JavaScript jest przetwarzany w przeglądarce.
• Dowiedz się, w jaki sposób JavaScript, arkusze stylów i inne zasoby używane przez twoją stronę są ładowane, i rozważ ich wpływ na postrzeganą wydajność. Obecnie powszechnie uważa się za właściwe przenoszenie skryptów na dół stron, z wyjątkami zwykle takimi jak aplikacje analityczne lub podkładki HTML5.
• Dowiedz się, jak działa piaskownica JavaScript, zwłaszcza jeśli zamierzasz używać ramek iframe.
• Pamiętaj, że JavaScript może i będzie wyłączony, dlatego też AJAX jest rozszerzeniem, a nie linią bazową. Nawet jeśli większość zwykłych użytkowników nie włącza go teraz, pamiętaj, że NoScript staje się coraz bardziej popularny, urządzenia mobilne mogą nie działać zgodnie z oczekiwaniami, a Google nie uruchomi większości Twojego JavaScript podczas indeksowania strony.
• Poznaj różnicę między przekierowaniami 301 i 302 (jest to również kwestia SEO).
• Dowiedz się, jak możesz, o swojej platformie wdrażania.
• Rozważ skorzystanie z Resetuj arkusz stylów lub normalize.css .
• Rozważ frameworki JavaScript (takie jak jQuery , MooTools , Prototype , Dojo lub YUI 3 ), które ukryją wiele różnic w przeglądarce podczas używania JavaScript do manipulacji DOM.
• Biorąc pod uwagę postrzeganą wydajność i frameworki JS, rozważ użycie usługi, takiej jak interfejs API bibliotek Google, aby załadować frameworki, aby przeglądarka mogła użyć kopii frameworku, który już buforował, zamiast pobierać duplikat z Twojej witryny.
• Nie wymyślaj koła na nowo. Przed wykonaniem NIC, wyszukaj komponent lub przykład, jak to zrobić. Istnieje 99% szans, że ktoś to zrobił i wydał wersję OSS kodu.
• Z drugiej strony, nie zaczynaj z 20 bibliotekami, zanim jeszcze zdecydujesz, jakie są twoje potrzeby. Zwłaszcza w sieci po stronie klienta, gdzie prawie zawsze najważniejsze jest utrzymanie lekkości, szybkości i elastyczności.

Naprawa błędów

• Zrozum, że spędzisz 20% czasu na kodowaniu, a 80% na jego utrzymywaniu, więc odpowiednio koduj.
• Skonfiguruj dobre rozwiązanie do zgłaszania błędów.
• Przygotuj system umożliwiający kontaktowanie się z Tobą za pomocą sugestii i krytyki.
• Udokumentuj działanie aplikacji dla przyszłych pracowników pomocy technicznej i osób wykonujących konserwację.
• Rób częste kopie zapasowe! (I upewnij się, że kopie zapasowe działają). Strategia przywracania, a nie tylko strategia tworzenia kopii zapasowych.
• Użyj systemu kontroli wersji do przechowywania plików, takich jak Subversion , Mercurial lub Git .
• Nie zapomnij wykonać testów akceptacyjnych. Ramy takie jak Selenium mogą pomóc. Zwłaszcza jeśli w pełni zautomatyzujesz swoje testy, być może za pomocą narzędzia do ciągłej integracji, takiego jak Jenkins .
• Upewnij się, że masz wystarczające logowanie przy użyciu platform takich jak log4j , log4net lub log4r . Jeśli coś pójdzie nie tak w Twojej witrynie na żywo, będziesz musiał dowiedzieć się, co.
• Podczas rejestrowania pamiętaj o przechwytywaniu zarówno obsługiwanych wyjątków, jak i nieobsługiwanych wyjątków. Zgłoś / przeanalizuj dane wyjściowe dziennika, ponieważ pokaże Ci, gdzie są najważniejsze problemy w Twojej witrynie.

Inny

• Wdrażaj monitorowanie i analizy zarówno po stronie serwera, jak i klienta (jeden powinien być bardziej proaktywny niż reaktywny).
• Korzystaj z usług takich jak UserVoice i Interkom (lub inne podobne narzędzia), aby stale pozostawać w kontakcie z użytkownikami.
• Śledź Vincent Driessen „s Git rozgałęzień modelu

Wiele rzeczy zostało pominiętych, niekoniecznie dlatego, że nie są użytecznymi odpowiedziami, ale ponieważ są albo zbyt szczegółowe, poza zakresem, albo idą za daleko dla kogoś, kto chce uzyskać przegląd rzeczy, które powinien wiedzieć. Zmodyfikuj to również, pewnie coś przeoczyłem lub popełniłem błędy.