Step 3 (S-44886)

From Stepik Wiki
Revision as of 14:19, 6 August 2017 by Admin (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Step on Stepik: https://stepik.org/lesson/14832/step/3

Step 3 (S-44886) 1.png

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


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


Step 3 (S-44886) 2.png

[00:34 - 00:52] post запрос то есть 1 запрос произвольный допустим у нас был post запрос как в примере с формой мы сохраняли форму сервер выполняет некоторую логику


[00:52 - 01:11] и вместо что мы страничке отдает а код ответа 302 тело ответа при этом пустое то есть а само тело пустое но вставить специальный код ответа 302


[01:11 - 01:28] + к этому стоит заголовок локейшн а такая комбинация код ответа 302 заголовок локейшен говорит браузеру что нужно сделать


[01:28 - 01:47] запрос повторно но уже по новому урлу заголовки локейшен как раз передается новый которому нужно делать запрос браузер повторяет запрос но уже по новому урлу и это будет уже get запрос


[01:47 - 02:06] сервер получает запрос по новому урлу выполняет некоторую логику и на этот раз уже отдает нормально мою страничку то есть вы здесь вращается что


[02:06 - 02:22] ну и соответственно пользователь я видел а что здесь важно здесь важно что код ответа 302 заголовок локейшен а и что повторный запрос может быть а


[02:22 - 02:38] повторный запрос идет методов гет 1 может быть методом общем то любых а в принципе станция может не ограничиваться 1 редиректов а может отдать


[02:38 - 02:55] и во 2 раз не 200 год а 302 с давайте рассмотрим более сложный случай сервер и во 2 раз создает здесь код ответ 302 и заголовок локейшен а соответственно веб клиент повторить запрос


[02:55 - 03:13] причем запрос может осуществляться уже каком то другому серверу сервера 2 это нормальная практика до тех пор пока вы в сервер будет отдавать 302 год


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


[03:29 - 03:45] а перестает делать запрос помимо этого клиент также следит за зацикливанием то есть какой то момент такое часто случается что отдает перенаправление


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


Step 3 (S-44886) 3.png

[04:03 - 04:19] для того чтобы браузер а проследовал по другому нужно чтобы это был 302 либо 301 302 это временное перенаправление то есть браузер однократно пройдет по новому 301


[04:19 - 04:35] это постоянное давление отличие в том что а вот с данной редирект кэшируются запоминаются в браузере и повторно браузер может вообще не пойти то есть он


[04:35 - 04:54] запоминающееся заменил снова и сразу пойдет по новому поэтому 302 код используется при обработке форм а 301 используется намного реже код 301 используется при различного рода перемещениях документов когда сменился урук документа


[04:54 - 05:13] а при смене протокола когда раньше сайт был ваш степи доступен теперь постить ps и нужно глобально все высушить и на 6 а при использовании 301 либо 302 года в заголовке локейшен


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


Step 3 (S-44886) 4.png

[05:31 - 05:50] давайте посмотрим вспомним как это делается в джанге а для этого используется специальный объект теперь спонсор и директ он импортируется из пакета django в степи


[05:50 - 06:07] а в конструкторе указывается новый урл на которой следует отправить то есть это твой рот упадет заголовок локейшен и собственно говоря объект


[06:07 - 06:26] данного класса возвращается из вьюшки это проведет ходу 302 с указано заголовком а когда мы говорим про редиректы следует сказать а следующее


[06:26 - 06:42] очень часто а в обработчиках форм ур на которой пользователь отправят после обработки формы а заранее неизвестен то есть например при добавлении поста этот угол известен заранее мы добавляем post


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


[07:00 - 07:17] вот пример to continue передается на которой мы отправим пользователя то есть создается опять таки а теперь сполз редирект


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


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


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


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


[08:24 - 08:41] сайт дот ком они считают данную ссылку а достоверные то есть они доверяют также данной ссылке но поскольку она ссылается ссылка с вашего сайта а не по не щелкают но в конце концов они попадают


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


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


[09:18 - 09:35] разрабатываете скажем там google можно считать что все редиректов раку google они достоверно для вас на потому что от вашей компании можете проверять домен домен


[09:35 - 09:45] если домен соответствует вашей компании то можете делать редирект сможете вести список доверенных доменов и тому подобные механизмы