Разработка для серверной части сайта

1. Разработка для серверной части сайта

*
* Что такое
БЭКЭНД?

2. Принципы работы сайтов

*
* Веб-браузеры взаимодействуют с веб-серверами при помощи
гипертекстового транспортного протокола (HTTP). Когда вы
нажимаете на ссылку на веб-странице, заполняете форму или
запускаете поиск, HTTP-запрос отправляется из вашего браузера
на целевой сервер.
* Запрос включает в себя URL, определяющий затронутый ресурс,
метод, определяющий требуемое действие (например, получить,
удалить или опубликовать ресурс) и может включать
дополнительную информацию, закодированную в параметрах URL
(пары поле-значение, отправленные как строка запроса), как POST
запрос (данные, отправленные методом HTTP POST) или в кукифайлах.
* Веб-серверы ожидают сообщений с клиентскими запросами,
обрабатывают их по прибытию и отвечают веб-браузеру при
помощи ответного HTTP сообщения (HTTP-ответ). Ответ содержит
строку состояния, показывающую, был ли запрос успешным или
нет (например, «HTTP/1.1 200 OK» в случае успеха).
* Тело успешного ответа на запрос может содержать
запрашиваемые данные (например, новую HTML-страницу или
изображение, и т. п.), который может отображаться через веббраузер.

3. Статические сайты

*
* Схема ниже показывает базовую архитектуру веб-сервера для
статического сайта (статический сайт — это тот, который
возвращает одно и то же жёстко закодированное содержимое с
сервера всякий раз, когда запрашивается конкретный ресурс).
Когда пользователь хочет перейти на страницу, браузер
отправляет HTTP-запрос «GET» с указанием его URL.
* Сервер извлекает запрошенный документ из своей файловой
системы и возвращает HTTP-ответ, содержащий документ и
успешный статус (обычно 200 OK). Если файл не может быть
извлечён по каким-либо причинам, возвращается статус ошибки.

4. Динамические сайты

*
* Динамический веб-сайт — это тот, где часть содержимого ответа
генерируется динамически только при необходимости. На динамическом вебсайте HTML-страницы обычно создаются путём вставки данных из базы данных
в заполнители в HTML-шаблонах (это гораздо более эффективный способ
хранения большого количества контента, чем использование статических
сайтов).
* Динамический сайт может возвращать разные данные для URL-адреса на
основе информации, предоставленной пользователем или сохранёнными
настройками, и может выполнять другие операции, как часть возврата ответа
(например, отправку уведомлений).
* Большая часть кода для поддержки динамического веб-сайта должна
выполняться на сервере. Создание этого кода известно, как
«программирование серверной части» (или иногда «программирование
бэкенда»).
* Схема ниже показывает простую архитектуру динамического сайта. Как и на
предыдущей схеме, браузеры отправляют HTTP-запросы на сервер, затем
сервер обрабатывает запросы и возвращает соответствующие HTTP-ответы.
* Запросы статических ресурсов обрабатываются так же, как и для статических
сайтов (статические ресурсы — это любые файлы, которые не меняются,
обычно это: CSS, JavaScript, изображения, предварительно созданные PDFфайлы и прочее).

5. Динамические сайты

*
* Запросы динамических данных отправляются (2) в код
серверной части (показано на диаграмме как Вебприложение). Для «динамических запросов» сервер
интерпретирует запрос, читает необходимую информацию
из базы данных (3), комбинирует извлечённые данные с
шаблонами HTML и возвращает ответ, содержащий
сгенерированный HTML (5, 6).

6. Код серверной и клиентской части

*
* Они имеют различные цели и назначение.
* Как правило, они не используют одни и те же языки
программирования (исключение составляет JavaScript,
который можно использовать на стороне сервера и
клиента).
* Они выполняются в разных средах операционной системы.

7. Код серверной и клиентской части

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

8. Код серверной и клиентской части

*
* Код клиентской части написан с использованием HTML, CSS и JavaScript — он
запускается в веб-браузере и практически не имеет доступа к базовой
операционной системе (включая ограниченный доступ к файловой системе).
* Веб-разработчики не могут контролировать, какой браузер может
использовать каждый пользователь для просмотра веб-сайта — браузеры
обеспечивают противоречивые уровни совместимости с функциями кода на
стороне клиента, и одной из задач программирования на стороне клиента
является изящная обработка различий в поддержке браузера.
* Код серверной части может быть написан на любом количестве языков
программирования — примеры популярных языков серверной части включают
в себя PHP, Python, Ruby, C# и NodeJS (JavaScript). Код серверной части имеет
полный доступ к операционной системе сервера, и разработчик может
выбрать какой язык программирования (и какую версию) он хотел бы
использовать.
* Разработчики обычно пишут свой код, используя веб-фреймворки.
* Веб-фреймворки — это наборы функций, объектов, правил и других
конструкций кода, предназначенных для решения общих проблем,
ускорения разработки и упрощения различных типов задач, стоящих в
конкретной области.

9. Эффективное хранение и доставка информации

*
* Представьте, сколько товаров доступно на Amazon, и представьте,
сколько постов было написано на Facebook? Создание статической
страницы для каждого товара или поста было бы абсолютно
неэффективным.
* Программирование серверной части позволяет вместо этого
хранить информацию в базе данных и динамически создавать и
возвращать HTML и другие типы файлов (например, PDF,
изображения, и т. д.). Также есть возможность просто вернуть
данные (JSON, XML, и т. д.) для отображения, используя
подходящий фреймворк клиентской части (это уменьшает
загрузку процессора на сервере и количество передаваемых
данных).
* Сервер не ограничен в отправке информации из баз данных и
может вместо этого возвращать результат инструментов
программного обеспечения или данные из сервисов
коммуникации. Контент даже может быть целевым относительно
устройства клиента, который его получает.

10. Настраиваемый пользовательский опыт взаимодействия

*
* Серверы могут хранить и использовать информацию о клиентах чтобы
поставлять удобный и сделанный индивидуально пользовательский
опыт взаимодействия. Например, многие сайты хранят данные
кредитных карт, чтобы не нужно было вводить их повторно. Сайты,
наподобие Google Maps, могут использовать сохранённое и текущее
местоположение для предоставления информации о маршруте, а
также историю поиска или путешествий для выделения местных
предприятий в результатах поиска.
* Более глубокий анализ привычек пользователя может быть
использован для прогнозирования их интересов и дальнейших
настроек ответов и уведомлений, например, предоставление списка
ранее посещённых популярных мест, которые вы, возможно, захотите
найти на карте.

11. Контролируемый доступ к контенту

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

12. Хранение информации о сессии/состоянии

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

13. Уведомления и средства связи

*
* Серверы могут отправлять общие или пользовательские
уведомления непосредственно через сайт или по
электронной почте, через смс, мгновенные сообщения,
видеосвязь или другие средства связи.

14. Анализ данных

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

15. Веб-фреймворки

*
* Серверные веб-фреймворки (или «фреймворки веб-
приложений») — это программные среды, которые упрощают
создание, поддержку и масштабирование веб-приложений.
* Они предоставляют инструменты и библиотеки, которые
упрощают общие задачи веб-разработки, включая
маршрутизацию URL-адресов для соответствующих
обработчиков, взаимодействие с базами данных, поддержку
сеансов и авторизацию пользователей, форматирование
вывода (например, HTML, JSON, XML) и улучшение защиты
от веб-атак.

16. Обработка URL

*
* Большинство сайтов предоставляют несколько различных
ресурсов, доступных через отдельные URL-адреса.
* Если работать с ними в одной функции, поддерживать будет
трудно, поэтому веб-фреймворки предоставляют простые
механизмы для сопоставления шаблонов URL-адресов с
конкретными функциями обработчика.
* Этот подход также имеет преимущества с точки зрения
обслуживания, потому что вы можете изменить URL-адрес,
используемый для доставки определённой функции, без
изменения базового кода.

17. Доступ к данным в запросе

*
* Данные могут быть закодированы в HTTP-запросе разными
способами.
* Для получения файлов или данных с сервера, HTTP-запрос
GET может кодировать, какие данные требуются в URLпараметрах или в структуре URL.
* HTTP-запрос POST для обновления ресурса на сервере
вместо этого будет включать обновлённую информацию как
«POST данные» внутри тела запроса.
* HTTP-запрос может также включать информацию о текущей
сессии или пользователе в cookie со стороны клиента.

18. Доступ к базе данных

*
* Веб-сайты используют базы данных для хранения
информации как для пользователей, так и о пользователях.
* Веб-фреймворки часто предоставляют слой базы данных,
который абстрагирует операции чтения, записи, запроса и
удаления базы данных.
* Этот уровень абстракции называется Object-Relational
Mapper (ORM).

19. Преимущества ORM

*
* Вы можете заменить лежащую в основе базу данных без
необходимости изменять код, который её использует. Это
позволяет разработчикам оптимизировать характеристики
различных баз данных в зависимости от их использования.
* Базовая проверка данных может быть реализована. Это
позволяет легче и безопаснее проверить, что данные
хранятся в правильном поле типа базы данных, имеют
правильный формат (например, адрес электронной почты) и
не являются вредоносными (взломщики могут использовать
определённые шаблоны кода, чтобы сделать такие вещи,
как удаление записей базы данных).

20. Отрисовка данных

*
* Веб-фреймворки часто предоставляют системы шаблонов.
Они позволяют вам указать структуру выходного документа,
используя заполнители для данных, которые будут
добавлены при создании страницы. Шаблоны часто
используются для создания HTML, но могут также создавать
другие типы документов.
* Веб-фреймворки часто предоставляют механизм,
позволяющий легко создавать другие форматы из хранимых
данных, включая JSON и XML.

21. Web API

*
* Взаимодействие браузеров и веб-сайтов (первые выступают в
роли Клиента, а вторые в роли Сервера) традиционно
делалось при помощи технологии html-рендеринга, именно
так изначально это делал Django.
* Чтобы получить данные с веб-сайта, браузер отправляет
запрос GET к Серверу. Сервер формирует ответ в виде htmlстраницы и передает ее браузеру.
* Так Сервер передает данные браузеру, но как браузер может
передать данные Серверу?
* В этой самой html-странице Сервер заложил все
необходимые веб-формы, заполнив которые, пользователь
мог бы передать свои данные обратно на сервер. Когда вы
ввели свои данные в форму на сайте, бразуер отправляет
Серверу запрос POST, в котором содержатся ваши данные, а
Сервер обрабатывает их и записывает в базу данных.

22. Web API

*
* Все это отлично работало, но уже в середине нулевых такой подход
перестал удовлетворять возрастающим требования в вебразработке.
* Появлялись мобильные приложения, различные гаджеты с
доступом в интернет, и для них уже не подходил стандартный
способ html-рендеринга на сервере, ведь теперь каждому клиенту
нужно было отрисовать данные по-своему.
* Постоянно увеличивалось взаимодействие серверов друг с другом,
и html-формат уже не подходил.
* Для всех этих задач есть другой способ обмена данными — Web API.
* Смысл этого способа в том, что Сервер передает Клиенту не htmlстраницу, а непосредственно данные, никак не влияя на то, как эти
данные будут в итоге представлены. Наиболее популярными
форматами для передачи данных становятся XML и JSON. Таким
образом Сервер полностью избавляется от задачи отрисовки
данных.
* Этому способствовало молниеносное развитие инструментов на
языке JavaScript, а также появление различных веб-фреймворков.

23. Web API

*
* Браузерные приложения быстро научились отрисовывать вебстраницы самостоятельно, получая чистые данные с Сервера.
* Веб-приложения на сервере научились создавать API быстро
и легко.
* Так сформировалась четкое разделение на Backend и
Frontend разработку: тех, кто поддерживает приложение на
Сервере, и тех, кто делает браузерные (клиентские)
приложения.
* Web API стал универсальным способом общения для Сервера
и всех его клиентов (браузеров, мобильных приложений,
других Серверов).

24. Web API

*

25. Web API

*

26. Web API

*
* Это не могло не привести к развитию стандартов в общении
между системами. И Клиенту, и Серверу необходимо знать
каким образом общаться с друг с другом, как передавать
данные, как сообщать об ошибках. Разработчики всегда
могли договориться о том, как взаимодействовать их
приложениям, но наличие некоего стандарта в вебразработке позволило бы эту задачу облегчить. И вот в
начале десятых таким стандартом стала концепция REST.

27. REST

*
* В 2000 году Рой Филдинг написал докторскую диссертацию, где
изложил концепцию REST. Там были рекомендации о том, как
спроектировать Сервер, чтобы ему было удобно общаться с
Клиентами. Выделю два главных принципа создания приложений в
стиле REST:
* Сервер не должен ничего знать о текущем состоянии Клиента. В
запросе от Клиента должна быть вся необходимая информация для
обработки этого запроса Сервером.
* Каждый ресурс на Сервере должен иметь определенный Id, а также
уникальный URL, по которому осуществляется доступ к этому
ресурсу.
* На данный момент мы можем найти фреймворк для создания
приложений в стиле REST практически для каждого языка
программирования, используемого в веб-разработке. Логика
построения Web API на Сервере в этих фреймворках реализована
одинаково.

28. REST

*
* Действия для управления данными привязаны к
определенным HTTP-методам. Существует несколько
стандартных действий для работы с данными — это Create,
Read, Update, Delete. Часто их обобщают как CRUD.
* Для создания объекта используется http-метод POST
* Для чтения — http-метод GET
* Для изменения — http-метод PUT
* Для удаления — http-метод DELETE
* Пр. У нас есть объект Кошка, и мы хотим создать запись о
кошке на Сервере. Для этого мы отправляем запрос на
сервер:

29. POST

*
* POST — http://www.pets-server.ru/cats/
* С данными в теле запроса
* Плюс к этому запросу (и все другим) будет добавлен ключ
аутентификации.
* Сервер ответит на этот запрос вот таким сообщением:

30. GET

*
* Теперь мы можем получить данную запись по URL
* GET — http://www.pets-server.ru/cats/21
* Ответ сервера:

31. PUT

*
* Что, если Клиент хочет изменить созданные им данные на
сервере?
* Отправляем запрос:
* PUT — http://www.pets-server.ru/cats/21
* С телом запроса:
* Ответ сервера:

32. DELETE

*
* Для удаления записи на Сервере достаточно отправить
запрос:
* DELETE — http://www.pets-server.ru/cats/21
* С пустым телом запроса.
* Тут также мы указываем в Id объекта в URL, но передавать
никаких данных в теле запроса для удаления объекта уже не
требуется.

33. HTTP или HTTPS?

*
* HTTP передает незашифрованные данные, что означает, что информация, отправленная
из браузера, может быть перехвачена и прочитана третьими лицами.
* HTTPS объединяет HTTP-запросы и ответы с технологиями SSL и TLS.
* Веб-сайты HTTPS должны получить сертификат SSL/TLS от независимого центра
сертификации (CA). Эти веб-сайты передают сертификат браузеру, а затем
обмениваются данными для установления доверия. Также SSL-сертификат содержит
криптографическую информацию, поэтому сервер и веб-браузеры могут обмениваться
зашифрованными данными.
Процесс работает следующим образом.
* Вы открываете веб-сайт HTTPS, введя формат URL-адреса https:// в адресной строке
браузера.
* Браузер пытается проверить подлинность сайта, запросив SSL-сертификат сервера.
* В ответ сервер отправляет сертификат SSL, содержащий открытый ключ.
* SSL-сертификат веб-сайта подтверждает личность сервера. Как только браузер
удовлетворен, он использует открытый ключ для шифрования и отправки сообщения,
содержащего секретный ключ сеанса.
* Веб-сервер использует свой закрытый ключ для расшифровки сообщения и получения
ключа сеанса. Затем он шифрует сеансовый ключ и отправляет подтверждающее
сообщение в браузер.
* Теперь и браузер, и веб-сервер переходят на использование одного и того же
сеансового ключа для безопасного обмена сообщениями.

34. SSL/TLS

*
* Сертификат SSL/TLS — это цифровой объект, который
позволяет системам проверять личность и впоследствии
устанавливать зашифрованное сетевое соединение с другой
системой с использованием протокола Secure Sockets
Layer/Transport Layer Security (SSL/TLS).
* Сертификаты используются в рамках криптографической
системы, известной как инфраструктура открытого
ключа (PKI). PKI дает одной стороне возможность
устанавливать подлинность другой стороны с помощью
сертификатов (при условии, что обе стороны доверяют
третьей стороне, известной как центр сертификации).
* Таким образом, сертификаты SSL/TLS действуют как
цифровые удостоверения личности для защиты сетевых
подключений и установления подлинности веб-сайтов в
Интернете, а также ресурсов в частных сетях.

35. Веб-безопасность

*
* Интернет - опасное место!
* Цель веб-безопасности заключается в предотвращении всех видов
атак интернет-ресурса.
* Более формальным определением веб-безопасности
является: способы защиты веб-сайтов от несанкционированного
доступа, использования, изменения, уничтожения или нарушения
работы.
* Для эффективной безопасности веб-сайта необходимо уделять
особое внимание к разработке всего веб-сайта: к вашему вебприложению, конфигурации веб-сервера, при написании политик
создания и обновления паролей, а так же кода на стороне клиента.
* Хотя все это звучит очень зловеще, хорошая новость заключается в
том, что если вы используете веб-фреймворк для серверной части, то
он почти наверняка обеспечит «по умолчанию» надёжные и
продуманные механизмы защиты от ряда наиболее распространённых
атак.
* Другие атаки можно смягчить с помощью конфигурации вашего вебсервера, например, включив HTTPS. Наконец, есть общедоступные
инструменты для сканирования уязвимостей, которые могут помочь
вам определить, если вы допустили какие-либо очевидные ошибки.

36. Межсайтовый скриптинг (XSS)

*
* XSS (Cross-Site Scripting - Межсайтовый скриптинг) это
термин, используемый для описания типа атак, которые
позволяют злоумышленнику внедрять вредоносный код
через веб-сайт в браузеры других пользователей.
* Поскольку внедрённый код поступает в браузер с сайта, он
является доверенным и может выполнять такие действия,
как отправка авторизационного файла cookie-пользователя
злоумышленнику.
* Когда у злоумышленника есть файл cookie, он может войти
на сайт, как если бы он был пользователем, и сделать все,
что может пользователь, например, получить доступ к
данным кредитной карты, просмотреть контактные данные
или изменить пароли.

37. XSS

*
* Уязвимости XSS делятся на отражённые и хранимые, в
зависимости от того, как сайт возвращает внедрённый код в
браузер.
* Отражённая XSS-уязвимость возникает, когда
пользовательский контент, который передаётся на
сервер, немедленно и без изменений возвращается для
отображения в браузере. Любой скрипт в исходном
пользовательском контенте запустится при загрузке новой
страницы.
* Постоянная уязвимость XSS возникает, когда вредоносный
скрипт хранится на веб-сайте, а затем снова отображается
без изменений, чтобы другие пользователи могли
выполнять его невольно.

38. SQL injection

*
* Уязвимости SQL-инъекций позволяют злоумышленникам
выполнять произвольный код SQL в базе данных, позволяя
получать, изменять или удалять данные независимо от
разрешений пользователя. Успешная инъекционная атака
может подделать удостоверения, создать новые
удостоверения с правами администратора, получить доступ
ко всем данным на сервере или уничтожить / изменить
данные, чтобы сделать их непригодными для
использования.
* Типы внедрения SQL включают внедрение SQL на основе
ошибок, внедрение SQL на основе логических ошибок и
внедрение SQL на основе времени.

39. SQL injection

*
* Эта уязвимость присутствует, если пользовательский ввод,
который передаётся в базовый оператор SQL, может
изменить смысл оператора. Например, следующий код
предназначен для перечисления всех пользователей с
определённым именем (userName), которое было
предоставлено из формы HTML:
* Если пользователь указывает реальное имя, оператор будет
работать так, как задумано. Однако злонамеренный
пользователь может полностью изменить поведение этого
оператора SQL на новый оператор в следующем примере,
просто указав текст полужирным шрифтом для userName.

40. Подделка межсайтовых запросов (CSRF)

*
* CSRF-атаки позволяют злоумышленнику выполнять
действия, используя учётные данные другого пользователя,
без его ведома или согласия.
* Один из способов предотвратить этот тип атаки - запросить
сервером запросы POST, содержащие секрет, созданный
пользователем для конкретного сайта. Секрет будет
предоставлен сервером при отправке веб-формы,
используемой для переводов.

41. Прочие угрозы

*
* Clickjacking. В этой атаке злоумышленник перехватывает клики, предназначенные для
видимого сайта верхнего уровня, и направляет их на скрытую ниже страницу. Этот метод
можно использовать, например, для отображения законного сайта банка, но захвата учётных
данных для входа в невидимый <iframe> (en-US) , контролируемый злоумышленником.
Clickjacking также можно использовать для того, чтобы заставить пользователя нажать кнопку
на видимом сайте, но при этом на самом деле невольно нажимать совершенно другую кнопку.
В качестве защиты ваш сайт может предотвратить встраивание себя в iframe на другом сайте,
установив соответствующие заголовки HTTP.
* Denial of Service (en-US) (DoS). DoS обычно достигается за счёт наводнения целевого сайта
поддельными запросами, так что доступ к сайту нарушается для законных пользователей.
Запросы могут быть просто многочисленными или по отдельности потреблять большие объёмы
ресурсов (например, медленное чтение или загрузка больших файлов). Защита от DoS обычно
работает, выявляя и блокируя «плохой» трафик, пропуская при этом легитимные сообщения.
Эти средства защиты обычно расположены перед веб-сервером или на нем (они не являются
частью самого веб-приложения).
* Directory Traversal (Файл и раскрытие). В этой атаке злоумышленник пытается получить доступ
к частям файловой системы веб-сервера, к которым у него не должно быть доступа. Эта
уязвимость возникает, когда пользователь может передавать имена файлов, содержащие
символы навигации файловой системы (например, ../../). Решение состоит в том, чтобы
очищать ввод перед его использованием.
* File Inclusion. В этой атаке пользователь может "случайно" указать файл для отображения или
выполнения в данных, передаваемых на сервер. После загрузки этот файл может выполняться
на веб-сервере или на стороне клиента (что приводит к XSS-атаке). Решение состоит в том,
чтобы дезинфицировать ввод перед его использованием.
* Внедрение команд. Атаки с внедрением команд позволяют злоумышленнику выполнять
произвольные системные команды в операционной системе хоста. Решение состоит в том,
чтобы дезинфицировать вводимые пользователем данные до того, как их можно будет
использовать в системных вызовах.