Какие технические детали должен учитывать программист веб-приложения, прежде чем делать сайт общедоступным?

Что нужно учесть программисту, реализующему технические детали веб-приложения, перед тем как сделать сайт общедоступным? Если Jeff Atwood можно забыть о HttpOnly печенье , сайтмепов , и запрос подделки межсайтовых все в том же месте , какая важная вещь я мог бы забыть, а?

Я думаю об этом с точки зрения веб-разработчика, так что кто-то другой создает реальный дизайн и контент для сайта. Таким образом, хотя удобство использования и контент могут быть важнее платформы, вы, программист, не можете сказать об этом. Вам нужно беспокоиться о том, что ваша реализация платформы стабильна, работает хорошо, безопасна и отвечает любым другим бизнес-целям (например, не требует больших затрат, занимает слишком много времени на сборку и имеет такой же высокий рейтинг, как и Google). контент поддерживает).

Подумайте об этом с точки зрения разработчика, который проделал некоторую работу для приложений типа интранет в довольно надежной среде и собирается сделать свой первый шаг и выпустить потенциально популярный сайт для всей большой плохой всемирной паутины.

Кроме того, я ищу что-то более конкретное, чем просто расплывчатый ответ «веб-стандартов». Я имею в виду, что HTML, JavaScript и CSS поверх HTTP в значительной степени являются данностью, особенно когда я уже указал, что вы профессиональный веб-разработчик. Выходя за рамки этого, какие стандарты? При каких обстоятельствах и почему? Предоставьте ссылку на спецификацию стандарта.

Идея заключается в том, что большинство из нас уже должно знать большую часть того, что находится в этом списке. Но может быть один или два предмета, которые вы на самом деле не изучали раньше, не до конца понимаете или, возможно, даже не слышали.

Интерфейс и пользовательский опыт

• Имейте в виду, что браузеры не всегда поддерживают стандарты, и убедитесь, что ваш сайт работает достаточно хорошо во всех основных браузерах. Как минимум протестируйте новейший движок Gecko ( Firefox ), движок WebKit ( Safari и некоторые мобильные браузеры), Chrome , ваши поддерживаемые браузеры IE (воспользуйтесь изображениями VPC Application Compatibility ) и Opera . Также рассмотрите, как браузеры отображают ваш сайт в разных операционных системах.
• Подумайте, как люди могут использовать сайт, кроме как из основных браузеров: сотовых телефонов, программ для чтения с экрана и поисковых систем, например. - Некоторая информация о доступности: WAI и Section508 , Разработка мобильных приложений: MobiForge .
• Постановка: как развернуть обновления, не затрагивая ваших пользователей. Подготовьте одну или несколько тестовых или промежуточных сред для реализации изменений в архитектуре, коде или развернутом контенте и убедитесь, что они могут быть развернуты контролируемым образом, ничего не нарушая. Иметь автоматизированный способ развертывания утвержденных изменений на действующем сайте. Это наиболее эффективно реализуется в сочетании с использованием системы контроля версий (git, Subversion и т. Д.) И автоматического механизма сборки (Ant, NAnt и т. Д.).
• Не отображайте недружественные ошибки непосредственно для пользователя.
• Не помещайте адреса электронной почты пользователей в простой текст, поскольку они будут спамить до смерти.
• Добавьте атрибут rel="nofollow"в сгенерированные пользователем ссылки, чтобы избежать спама .
• Создайте продуманные ограничения на своем сайте - это также относится к безопасности.
• Узнайте, как сделать прогрессивное улучшение .
• Перенаправить после POST, если этот POST прошел успешно, чтобы предотвратить повторную отправку обновления.
• Не забудьте принять во внимание доступность. Это всегда хорошая идея, и в определенных обстоятельствах это законное требование . WAI-ARIA и WCAG 2 - хорошие ресурсы в этой области.
• Читать не заставляй меня думать .

Безопасность

• Это очень много, но руководство по разработке OWASP охватывает безопасность веб-сайтов сверху вниз.
• Знать об инъекциях, особенно о SQL-инъекциях, и о том, как их предотвратить.
• Никогда не доверяйте пользовательскому вводу и ничему другому, что приходит в запросе (который включает куки и скрытые значения полей формы!).
• Хеш пароли, используя соль и использовать различные соли для ваших строк, чтобы предотвратить атаки радуги. Используйте алгоритм медленного хеширования, такой как bcrypt (проверено временем) или scrypt (даже сильнее, но новее) ( 1 , 2 ), для хранения паролей. ( Как безопасно хранить пароль ). NIST также утверждает PBKDF2 хэш пароля », и это FIPS утвержденной в .NET (подробнее здесь ). Избегайте использование MD5 или SHA семьи напрямую.
• Не пытайтесь придумать собственную причудливую систему аутентификации . Это такая простая вещь , чтобы получить так в тонком и непроверяемом пути и вы даже не знаете, пока после вы взломали.
• Знать правила обработки кредитных карт . ( См. Также этот вопрос )
• Используйте SSL / TLS / HTTPS для любых сайтов, где вводятся конфиденциальные данные (например, учетные данные, личная информация, информация о кредитной карте). Let's Encrypt - это бесплатный центр сертификации, который может помочь.
• Предотвратить угон сеанса .
• Избегайте межсайтовых скриптов (XSS).
• Избегайте подделок межсайтовых запросов (CSRF).
• Избегайте Clickjacking .
• Держите ваши системы в курсе последних обновлений.
• Убедитесь, что ваша информация о соединении с базой данных защищена.
• Будьте в курсе последних методов атаки и уязвимостей, влияющих на вашу платформу.
• Прочитайте Руководство по безопасности браузера Google .
• Прочитайте Руководство по взлому веб-приложений .
• Рассмотрим принцип наименьших привилегий . Попробуйте запустить сервер приложений без полномочий root . ( пример кота )
• Поместите rel="noopener noreferrer"все предоставленные пользователем ссылки, target="_blank"чтобы JavaScript на целевой странице не перенаправлял вашу страницу куда-либо еще, например, на поддельную страницу входа. Больше информации
• Подумайте об использовании строгой политики безопасности контента .

Представление

• При необходимости используйте кеширование, правильно понимайте и используйте кеширование HTTP, а также манифест HTML5 .
• Оптимизируйте изображения - не используйте изображение размером 20 КБ для повторяющегося фона.
• Сжатие содержимого для скорости, см. Brotli , gzip / deflate ( лучше использовать deflate ).
• Объедините / объедините несколько таблиц стилей или несколько файлов сценариев, чтобы уменьшить количество подключений к браузеру и улучшить способность сжатия сжатых файлов между файлами с помощью gzip.
• Взгляните на сайт Yahoo Exceptional Performance , множество отличных рекомендаций, в том числе по улучшению производительности интерфейса и их инструмента YSlow (требуется Firefox, Safari, Chrome или Opera). Кроме того, скорость страницы Google (используется с расширением браузера ) - еще один инструмент для профилирования производительности, который также оптимизирует ваши изображения.
• Используйте CSS Image Sprites для небольших связанных изображений, таких как панели инструментов (см. Пункт «Минимизировать HTTP-запросы»)
• Используйте SVG-изображения спрайтов для небольших связанных изображений, таких как панели инструментов. SVG раскраска немного сложнее. Вы можете прочитать об этом здесь .
• Занятые веб-сайты должны рассмотреть возможность разделения компонентов по доменам . В частности ...
• Статический контент (т. Е. Изображения, CSS, JavaScript и, как правило, контент, который не требует доступа к файлам cookie), должен находиться в отдельном домене , который не использует файлы cookie , поскольку все файлы cookie для домена и его поддоменов отправляются с каждым запросом к домен и его поддоменов. Один хороший вариант здесь - это использовать сеть доставки контента (CDN), но рассмотрим случай, когда этот CDN может дать сбой путем включения альтернативных CDN или локальных копий, которые можно обслуживать вместо этого.
• Минимизируйте общее количество HTTP-запросов, необходимых браузеру для отображения страницы.
• Выберите шаблонизатор и отредактируйте / прекомпилируйте его, используя такие бегуны, как gulp или grunt.
• Убедитесь в том , что есть favicon.icoфайл в корне сайта, то есть /favicon.ico. Браузеры автоматически запросят его , даже если значок вообще не упоминается в HTML. Если у вас его нет /favicon.ico, это приведет к большому количеству 404-х, уменьшая пропускную способность вашего сервера.

SEO (поисковая оптимизация)

• Используйте "дружественные для поисковых систем" URL, т.е. используйте example.com/pages/45-article-titleвместоexample.com/index.php?page=45
• При использовании #для динамического контента изменить #к , #!а затем на сервере $_REQUEST["_escaped_fragment_"]является то , что Googlebot использует вместо #!. Другими словами, ./#!page=1становится ./?_escaped_fragments_=page=1. Кроме того, для пользователей, которые могут использовать FF.b4 или Chromium, history.pushState({"foo":"bar"}, "About", "./?page=1");это отличная команда. Таким образом, даже если адресная строка изменилась, страница не перезагружается. Это позволяет вам использовать ?вместо #!хранения динамический контент, а также сообщать серверу, когда вы отправляете по электронной почте ссылку, что мы за этой страницей, и AJAX не нужно делать еще один дополнительный запрос.
• Не используйте ссылки, которые говорят "нажмите здесь" . Вы тратите впустую возможность SEO, и это делает вещи более трудными для людей с программами чтения с экрана.
• Иметь карту сайта XML , желательно в расположении по умолчанию /sitemap.xml.
• Используйте, <link rel="canonical" ... />если у вас есть несколько URL-адресов, указывающих на один и тот же контент, эту проблему также можно устранить с помощью Инструментов Google для веб-мастеров .
• Используйте инструменты для веб - мастеров Google и инструменты Bing для веб - мастеров .
• Установите Google Analytics прямо в начале (или инструмент анализа с открытым исходным кодом, как Piwik ).
• Знать, как работают robots.txt и поисковые пауки.
• Перенаправлять запросы ( с использованием 301 Moved Permanently) просить , www.example.comчтобы example.com(или наоборот) , чтобы предотвратить раскол Google Рейтинг между двумя сайтами.
• Знайте, что там могут быть пауки с плохим поведением.
• Если у вас нетекстовый контент, поищите видео в расширениях карты сайта Google и т. Д. В ответе Тима Фарли есть хорошая информация об этом .

Технологии

• Понимать HTTP и такие вещи, как GET, POST, сеансы, файлы cookie и то, что значит быть «не имеющим состояния».
• Напишите свои XHTML / HTML и CSS в соответствии со спецификациями W3C и убедитесь, что они проверены . Цель здесь состоит в том, чтобы избежать режимов причуда браузера и в качестве бонуса значительно облегчить работу с нетрадиционными браузерами, такими как программы чтения с экрана и мобильные устройства.
• Понять, как JavaScript обрабатывается в браузере.
• Узнайте, как загружаются JavaScript, таблицы стилей и другие ресурсы, используемые вашей страницей, и подумайте, как они влияют на воспринимаемую производительность. В настоящее время широко считается целесообразным перемещать скрипты вниз страницы, за исключением, как правило, таких вещей, как аналитические приложения или HTML5-прокладки.
• Понять, как работает песочница JavaScript, особенно если вы собираетесь использовать фреймы.
• Помните, что JavaScript может и будет отключен, и поэтому AJAX является расширением, а не базовой линией. Даже если большинство обычных пользователей оставят его включенным сейчас, помните, что NoScript становится все более популярным, мобильные устройства могут работать не так, как ожидалось, и Google не будет выполнять большую часть вашего JavaScript при индексации сайта.
• Узнайте разницу между редиректами 301 и 302 (это тоже проблема SEO).
• Узнайте как можно больше о своей платформе развертывания.
• Попробуйте использовать таблицу стилей Reset или normalize.css .
• Рассмотрим JavaScript-фреймворки (такие как jQuery , MooTools , Prototype , Dojo или YUI 3 ), которые скрывают множество различий в браузере при использовании JavaScript для манипулирования DOM.
• Взяв за основу воспринимаемую производительность и платформы JS, рассмотрите возможность использования службы, такой как API библиотек Google, для загрузки платформ, чтобы браузер мог использовать копию уже кэшированной платформы, а не загружать дубликаты с вашего сайта.
• Не изобретай велосипед. Прежде чем делать НИЧЕГО, найдите компонент или пример того, как это сделать. С вероятностью 99% кто-то сделал это и выпустил версию кода для OSS.
• С другой стороны, не начинайте с 20 библиотек, прежде чем вы даже решили, что ваши потребности. Особенно в сети на стороне клиента, где почти всегда в конечном итоге важнее поддерживать легкость, скорость и гибкость.

Исправление ошибок

• Поймите, что вы тратите 20% своего времени на кодирование и 80% его на поддержание, так что программируйте соответственно.
• Установите хорошее решение для сообщения об ошибках.
• Иметь систему, чтобы люди связывались с вами с предложениями и критикой.
• Документируйте, как приложение работает для будущего обслуживающего персонала и людей, выполняющих техническое обслуживание.
• Делайте частые резервные копии! (И убедитесь, что эти резервные копии работают). Используйте стратегию восстановления, а не просто стратегию резервного копирования.
• Используйте систему контроля версий для хранения ваших файлов, например, Subversion , Mercurial или Git .
• Не забудьте пройти приемочное тестирование. Каркасы, такие как Selenium, могут помочь. Особенно, если вы полностью автоматизируете тестирование, возможно, с помощью инструмента непрерывной интеграции, такого как Jenkins .
• Убедитесь, что у вас есть достаточно регистрации на месте, используя каркасы, такие как log4j , log4net или log4r . Если что-то пойдет не так на вашем живом сайте, вам нужен способ выяснить, что.
• При ведении журнала убедитесь, что вы захватили как обработанные исключения, так и необработанные исключения. Сообщите / проанализируйте вывод журнала, поскольку он покажет вам, где находятся ключевые проблемы на вашем сайте.

Другие

• Реализуйте мониторинг и аналитику как на стороне сервера, так и на стороне клиента (один должен быть активным, а не реактивным).
• Используйте такие сервисы, как UserVoice и Intercom (или любые другие подобные инструменты), чтобы постоянно поддерживать связь с вашими пользователями.
• Следуйте Винсент Дриссен «s Git разветвление модель

Многие вещи опущены не обязательно, потому что они не являются полезными ответами, а потому, что они либо слишком подробны, выходят за рамки, либо заходят слишком далеко для тех, кто хочет получить представление о том, что они должны знать. Пожалуйста, не стесняйтесь редактировать это, я, вероятно, пропустил некоторые вещи или сделал несколько ошибок.