Step 4 (S-44891)

From Stepik Wiki
Jump to: navigation, search

Step on Stepik: https://stepik.org/lesson/14833/step/4

Step 4 (S-44891) 1.png

[00:00 - 00:15] теперь перейдем к рассмотрению посмотрим как с помощью механизма кук а можно реализовать систему авторизации веб приложений начнем с рассмотрения


Step 4 (S-44891) 2.png

[00:15 - 00:30] а общей схемы а авторизация приложений cookie без авторизации она основана на 2 основных с вами во 1 это либо вход


[00:30 - 00:47] r на сайт и проверка сессию а мы начинаем с того что при обращении к какому то ресурсу аппликейшен сервер решает что пользователь не авторизован и нужно запросить авторизацию


[00:47 - 01:06] а в этот момент аппликейшен сервер перенаправляет пользователя на страницу а фото то есть пользователь видит форму фото где он должен ввести логин и пароль это вот это точка форма входа а дальше


[01:06 - 01:24] пользователь заполняет логин и пароль и отправлять форму формула 1 как говорили это форма изменяет состояние поэтому должны отправляться методом post вот мы видим этот вопрос то есть это по запросу


[01:24 - 01:42] слэш логин и в по запросе передаются а и пользователя и пароль передаются не в открытом виде а сервер сервер получается


[01:42 - 01:59] логин пароль и запускают процесс авторизации процессе авторизации сервер с этим логин и пароль по совершенно по разному он может проверять делал запрос в базу данных


[01:59 - 02:18] проверять наличие пользователя с таким логином паролем ходить во внешний сервер сервер с авторизацией это неважно а в результате если во всем что прикидываться понимаешь логин пароль подходит а он создает так называемую сессию


[02:18 - 02:36] процессе мы попозже поговорим сессии есть ключ а ключ это длинное относительно длинной которой невозможно угадать и а аппликейшен сервер ставят спасенную куку то есть мы видим что


[02:36 - 02:52] в ответе присутствуют заголовок set cookie и ставится кука с id но название может быть другим мы выбрали просто посадить а и значение данной иконки этот ключ сессии


[02:52 - 03:08] это запрос вида и директ то есть пользователь ввел форму логина она оказалась верна и теперь его нужно отправить на целевую страницу откуда он пришел поэтому отдает редирект и


[03:08 - 03:23] с помощью заголовка location указываем пользователя куда нужно идти а пользователи попадают на целевую страницу соответственно браузер делает get запрос по указанному ру


[03:23 - 03:39] и поскольку была установлена а кука он передает заголовки куки значение этой книге то есть мы видим что у нас


[03:39 - 03:55] а мы видим что у нас вот это значение ключ сессии он возвращается на сервер а сервер видит что к нему пришла со всем наука и делает проверку сессия


[03:55 - 04:11] а при проверке он осмотра действительно такой ключ сессии где то был у него запомнил а если уж был заполнен то с ним сервера связано связано текущий пользоваться


[04:11 - 04:30] сервер может понять о какой пользователь к нему пришел соответственно он генерирует ответ с учетом уже текущего пользователя а вот таким образом в общих чертах работает авторизация а теперь давайте


[04:30 - 04:46] подробнее рассмотрим каждый из тот а для начала нам нужно поговорить то как мы будем хранить пользователей и сессию а в реальных приложениях они могут храниться


Step 4 (S-44891) 3.png

[04:46 - 05:06] вот эти объекты могут разниться очень разных хранилищах поступим просто мы будем и пользователей и сессии хранить в базе данных мы создадим 2 модели 1 модель это модель пользователя предназначен для хранения информации


[05:06 - 05:21] юзер обязательные поля которое есть плагин и пароль а + очевидно что у нас будет множество дополнительных полей в которых хранятся хвалиться всякая другая информация пользователя например имя


[05:21 - 05:39] дата регистрации на сайте тому подобное это немедленно сейчас интереса имеют интерес логин и пароль а + django автоматически добавятся список полей уникальный первичный ключ 2 модель


[05:39 - 05:55] эта модель сессия а сессия это сеанс работы с ся представляет собой сеанс работы пользователя новый пользователь может быть параллельно открыто несколько сессий например может


[05:55 - 06:12] пользоваться приложением а через браузер и через мобильный браузер либо из дома и с работы а сессии есть следующие поля атрибуты ключ ключ сессия как раз


[06:12 - 06:27] а та строка которая отправляется от скуки то есть которая хранится у пользователя в браузере а эта строка должна быть уникальным уникальный ник


[06:27 - 06:45] по той причине что мы должны по этому ключу как то загрузить сессию из базы мы должны знать единством образом определить сессию а у соседей есть связь с пользователем то есть мы видим что есть каждая сессия связано с каким то определенным пользователям


[06:45 - 07:01] загрузи в сессию мы автоматически создаем пользователя с которым она связана и у сессии есть дата устаревают а в принципах механизм устаревания сессия которую он дублирует


[07:01 - 07:21] механизмов страхования cookie но дело в том что мы не хотим доверять пользователям пользоваться браузер это имя пользователя поэтому у каждой сессии на сервере хранится дату


[07:21 - 07:36] в общем то все мы будем использовать эти 2 простые модели итак рассмотрим а 1 пост сценарий сценарий входа на сайт когда пользователь отправляет свой логин и пароль и


Step 4 (S-44891) 4.png

[07:36 - 07:54] мы создаем для него сессию для определенности мы будем считать что у нас и форму входа и обработчик этой формы находится в пару слэш логин это вполне нормально соглашения


[07:54 - 08:10] все начинается с того что пользователь зашел на какую то страницу страницу и посчитала что его нужно авторизовать и с помощью редиректа 302 перебросила на страницу логин а


[08:10 - 08:29] пользователь видит форму входа и понимает что ему нужно авторизоваться он заполняет логин и пароль и отправляет на сервер отправка идет методом post отправляются в теле запроса и они отправляются в открытом виде то есть plan текст


[08:29 - 08:47] поэтому крайне желательно чтобы форму логина работала по протоколу http s а здесь уже это не так критично как прибалтика встречался там с логин пароль передается только 1 раз


[08:47 - 09:05] а не на каждый запрос но тем не менее поскольку предусмотрено виде очень желательно чтобы было спец ну это лирическое отступление сервер получается логин пароль от пользователя и проверяет логин пароль


[09:05 - 09:24] в нашем случае используя модель пользователя после того как сервер понял что пользователь есть он создает сессию создает новый объект смеси добавляют ее в базу данных и а устанавливают в куки содержащий ключ сессии


[09:24 - 09:40] ключ к разгадке поле в базе и а возвращается с помощью заголовка со скуки клиенту после чего сервер делаем перенаправление на целевую страницу


Step 4 (S-44891) 5.png

Step 4 (S-44891) 6.png

[09:40 - 09:57] 302 то есть она ту страницу с которой пользователь изначально пришел давайте посмотрим как это реализовано в коде а здесь мы видим вью вью называется логин это view отвечает за


Step 4 (S-44891) 7.png

[09:57 - 10:12] отображения формы логина и за обработку формулой 1 мы видимо она состоит во 1 здесь есть 1 большой и а если нет


[10:12 - 10:28] post тогда происходит обработка если метод не post происходит просто отрисовка формы логина это сценарий он простой нам неинтересен поэтому будем посмотреть что происходит внутри методов а то есть когда


[10:28 - 10:43] происходит отправка формы с методом post а 1 что мы делаем мы получаем параметры формы это логин и пароль


[10:43 - 11:02] мы извлекаем из request post то есть из данных формы а опционально также слегка параметр картине котея указывает нам на страницу куртка на которые нужно вернуть пользователя после успешной авторизации


[11:02 - 11:19] а когда у вас есть логин пароль мы вызываем функцию логин а здесь мы специально вынесли код непосредственной проверке авторизации из вьюшки


[11:19 - 11:38] да то есть несколько причин во 1 мы говорили что размещение всего кода все все бизнес логики во вьюшках этот лох это анти паттернов этот контрольных проверка авторизации это самый что ни на есть бизнес логика


[11:38 - 11:56] проверка авторизации может быть сложной а вот взаимодействия с протоколом http в частности выставления кук редиректы это как раз относится к лодке которая должна находиться в контроллерах а как работают функции она принимает логин и пароль


[11:56 - 12:12] пользователя в открытом виде и а возвращает идентификатор сессии ключ новой смеси либо не возвращает ничего если пароль а не подошел а


[12:12 - 12:27] мы получаем некоторую перемена сади смотрим если переменная передана то есть а удалось создать новую сессию значит авторизация прошла успешно если этой переменной нет она пустая


[12:27 - 12:45] значит мы устанавливаем код ошибки и заново форму чтобы пользователь мог увидеть эту ошибку и вести правильный пароль а заметил что хорошей практикой является не разделять


[12:45 - 13:00] разные ошибки авторизации то есть здесь могу 2 ошибки неправильный логин неправильный пароль а если мы будем разделять эти ошибки пользователь сможет последовательным перебором подобрать логин поэтому


[13:00 - 13:15] фото обычно показывают ошибку неверный логин пароль что именно из за этого неправильно это как бы предполагается что пользователь сам должен решать итак если у нас с сади


[13:15 - 13:34] пустой то есть не удалось а логин пароль неправильный мы показываем ошибку а если с сади вернулся то есть она была создана новая сессия пользователь успешно авторизована таком случае мы создаем новый теперь спонсор


[13:34 - 13:49] это у нас а редирект на указанный url мы берем либо тот который пользователь передал либо умолчанию слэш на главной странице


[13:49 - 14:06] в этот раз мы устанавливаем таки делал вызов со скуки это 2 важный вызов в данном коде авторизации установка кук мы останавливаемся темную куртку с именем с с 1


[14:06 - 14:21] значением тем что функция была где то есть с ключом сессии и указываем а также разные атрибутов например а домен


[14:21 - 14:39] платком а указывая что доступно только for степей потому что just у тя в нам не нужна это опасно они указывают expires в это время устаревания причем а как мы видим здесь указывается не виде


[14:39 - 14:58] а строки то есть он конечно ведь строки а здесь мы указываем expire использованию объектов data то есть вы вставляя буквы на 5 дней а после чего мы возвращаем данной response фреймворка то есть произойдет редирект


[14:58 - 15:14] с одновременной установкой кук а таким образом обрабатывает а вьюшка обрабатывающая форме а теперь посмотрим что происходит внутри функции dual 1 мы предполагаем что


Step 4 (S-44891) 8.png

[15:14 - 15:33] пользователя хранятся в базе данных модель которую вы рассказывали раньше 1 что происходит мы загружаем пользователя по указанному плагину если такого пользователя не было найдено мы перехватываем исключения does not exist


[15:33 - 15:50] и возвращать нам то есть не удалось залогиниться мы возвращаем пустой что весь процесс если пользователь был успешно загружен внимание важная строчка мы вычисляем


[15:50 - 16:08] а хэш пароля не должны находиться в базе данных в открытом виде в базе данных в поле в таблице пользователей хранится хеш от пароля то есть а что такое хэш


[16:08 - 16:27] это преобразованные из пароля посчитать хэш можно из хэша посчитать пароль нельзя а поэтому мы храним необратимо измененные пароли и а когда к нам пришел пароль из формы


[16:27 - 16:43] читай для него хэш с добавлением соли то есть получать дополнительные данные строки а получаем хэшировании сравнивает этот пароль с тем что хранится в базе


[16:43 - 17:02] если они не совпадают это значит что пользователь ошибся с вводом пароля и мы возвращаем авторизация не пройдена а в противном случае если вас пароль совпали значит пользователь


[17:02 - 17:19] прошел авторизацию мы должны создать новый объект смеси что мы делаем мы создаем экземпляр модели session а теперь мы должны создать ключ сессии


[17:19 - 17:34] ключ должен быть длинный а строкой которую сложно подобрать но чтобы это было сложно подобрать случайным образом здесь важно 2 во 1 его длина


[17:34 - 17:51] а во 2 а источник энтропии то есть с помощью какого метода вы генерируете эту случайную строчку нужно позаботиться о том чтобы источник был хорошим то есть использовать какие то достаточно хорошая функция генерации случайных последовательностей


[17:51 - 18:08] а чтобы нельзя было подобрать итак мы сгенерировали длинную длинную строчку а связывает объект цесис пользователем то есть мы загрузили пользователей из базы по логину паролю


[18:08 - 18:27] теперь мы связываем сессию с этим пользователям устанавливать даты устаревания и сохраняем сохраняем сессию все с этого момента мы возвращаем session


[18:27 - 18:43] а обратно в нашу юльку чтобы он был установлен итак повторим еще раз что происходит пользователь отправляет логин пароль а


[18:43 - 18:58] мы по логину загружая пользователей из базы а хеширует пароля в базе хранится зашифрованный пароль сравниваем пароля если пароли совпадают по создаем новый объект сессия


[18:58 - 19:15] а генерирует для него длинный случайный ключ связывает сессию с пользователем сессию сохранялись в базу а ключ сессии с помощью механизма кук возвращаю пользователя