Step 5 (S-44892)

From Stepik Wiki
Jump to: navigation, search

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

Step 5 (S-44892) 1.png

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


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


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


[00:48 - 01:07] еще раз как происходит проверка с то с основной сценарий а при любом запросе клиент передает заголовки cookie свой индикатор сессия совершеннолетия а перед выполнением какого либо кода а вьюшки сервер загружается


[01:07 - 01:24] сессию из базы данных по 1 кадру а если сессии не найдена значит клиент не авторизован если сессия найдена а из нее получается а id пользователя и


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


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


[01:57 - 02:14] копировании кода поэтому проверку авторизации имеет смысл делать а для всех view а таким образом выполнить какой то код для всех view еще и перед до того как в u будет запущен жанра для этого есть специальный механизм в


[02:14 - 02:29] мы про него не говорили поэтому давайте коротко сейчас его а что такое недугах джанго голубое это обычные а python класс в котором есть 1 из указанных ниже методов


Step 5 (S-44892) 2.png

[02:29 - 02:48] то есть просто класс в котором есть место с подходящие сигнатур а список всех недугов активных а находятся специальные настройки то есть с этим спи есть настройка такая глупая класс это список всех классов которые


[02:48 - 03:03] будут использованы то есть список всех активных чтобы жан знала какие ваши классы вообще рассматривать как виновного соответственно нужно будет создать класс и организовать не умеет а какие а


[03:03 - 03:19] методы могут быть в данном классе а здесь указаны 4 основных метода процесс request этот метод будет вызван а


[03:19 - 03:35] до начала диспетчеризации урлов то есть когда пришел отец переход на django даже не определила вью соответственно этот метод он будет называться для любой вьюшке а в начале в начале цикла обработки запроса


[03:35 - 03:53] продается переменная request это ж теперь я в тот же самый объект который попадет во вьюшку соответственно у нас есть возможность его немножко изменить а процесс you этот метод вызывается у мидуэйз а когда уже


[03:53 - 04:11] определена вьюшка которая будет выполняться здесь дополнительно передается функция вьюшке и ее аргументы то сказать про через отработала а процесс response вызывается после выполнения кода вьюшке


[04:11 - 04:26] когда появился объектов теперь сполз то есть ли успешно выполнил и процесс exception вызывается после обработки кодов южке если в процессе было выброшено неожиданно исключения


[04:26 - 04:41] а в нашем случае мы говорим про проверку авторизации вы хотели бы проверять для каждой вьюшке поэтому мы выберем 1 метод процесс request то есть мы будем обрабатывать


[04:41 - 04:58] до вызова до вызова любой излишек а давайте создадим разместить в отдельном файлике метлу в


Step 5 (S-44892) 1.png

[04:58 - 05:15] например в приложении проекта это обычное дело класс у него есть метод с требуемой сигнатуры то есть процесс request что происходит внутри данного метода 1 что мы делаем мы получаем


[05:15 - 05:34] значение куки то есть из request точка cookie мы извлекаем значение куки сойди куда мы записывали ключ сессии далее мы загружаем из баз данных с сессию мы указываем что ключ равняется сойди как мы помним у нас ключ


[05:34 - 05:49] отмечены так уникально поэтому сессию либо не вернет ее вообще а и дополнительно указывает проверку


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


[06:07 - 06:27] сессии запоминаю в request точка совершен и соответственно связанные с ним пользователя запоминаю абрикос точка юзер соответствовал этих 2 переменах внутри внутри у нас будут сессия пользователя и собственно сам объект пользователя если в процессе а


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


[06:45 - 07:01] соответственно мы а в рекой session required юзер записываем нам то есть я ничего не вижу сможет уже ориентировался есть авторизованный пользователь или авторизованного пользователя нет


Step 5 (S-44892) 4.png

[07:01 - 07:17] таким образом работает сценарий проверки авторизации и а давайте рассмотрим 3 снаряд совсем короткий выход с положения о том чтобы выйти из приложения сделал слагал


[07:17 - 07:36] пользователю достаточно удалить его объект сессия а для этого используется в you logout что происходит а пользователь заходит на такую вьюшку а часто ее делают обрабатывающие метод get хотя это не совсем правильно


[07:36 - 07:54] ну потому что часто кнопку выход делают виде ссылки желательно чтобы это работало с помощью метода post а мы получаем идентификатор сессии скука


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


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