Step 2 (S-44889)

From Stepik Wiki
Revision as of 14:26, 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/14833/step/2

Step 2 (S-44889) 1.png

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


[00:17 - 00:36] понимать кто из пользователей именно выполняет какие действия а начнем немножко в сторе исторически протокола http предполагался установка для обмена документами и был спроектирован как status


Step 2 (S-44889) 2.png

[00:36 - 00:54] а стоит лос то есть протокол без поддержания сетевого соединения как напомним в протокол http состоит из серии запросов ответов и предполагалось что каждый запрос будет порождать новое сетевое соединение а позже


[00:54 - 01:09] p 1 1 добавилось а такая фича как персистентные соединения то есть клиент может договориться с обсервер не закрывать соединение но а эта фича сделано


[01:09 - 01:24] для исключительно для оптимизации трафика при загрузке 1 страницы а и такое соединение даже президента соединением 6 5 1 1 как правило недолго то есть 10 там 15


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


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


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


[02:21 - 02:37] а исторически есть несколько разных вариантов авторизации мы рассмотрим 2 а сегодня этот бзик авторизация и авторизации основанное на


[02:37 - 02:51] а так а авторизация этот вариант авторизации реализован практически во всех веб серверах на сегодняшний момент вот довольно старое довольно простой


Step 2 (S-44889) 3.png

[02:51 - 03:08] давайте посмотрим как происходит обмен и запросами при бзиков 13 а начинается с того что на сервере некоторая группа ресурсов например некоторые локейшн


Step 2 (S-44889) 4.png

[03:08 - 03:25] отмечены как ok но от мечтах локейшен требующий авторизации допустим у нас этого локейшен слэш admin ну логично для доступа


[03:25 - 03:41] административной части нужна авторизация а пользователь вводит урл и браузер делает get запрос а допустим по такому пути слэш admin server


[03:41 - 04:00] пытается авторизовать пользователя но поскольку пользователь не передал никакой информации сервер сконфигурирован так что требуется для данного локейшен авторизация а то специальный код ответа 401


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


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


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


[04:52 - 05:08] часть сайта мы запрашиваем авторизацию а браузер получает ответ 411 и показывают пользователю диалог ввода логина и пароля это стандартный для браузера окно


[05:08 - 05:23] можно ввести логин пароль браузер как правило и запоминает его самостоятельно при следующем запросе то есть логин пароль введен бразер повторяет запрос нашем случае это


[05:23 - 05:38] гет слэш admin заголовок заголовок авторизуешь здесь также указывается что то бы быть авторизация и какие то данные


[05:38 - 05:53] а вот эти данные на самом деле закодированы незашифрованное закодированы а логин и пароль пользователя а сервер получает запрос извлекает логин пароль пользователя проверяет авторизацию


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


[06:09 - 06:24] так или иначе он решает что данные логин пароль они правильны то есть пользователь авторизовался и он возвращает 200 ok а


[06:24 - 06:39] в общем то вся схема после того как пользователь авторизовался то есть вот ввел логин пароль


[06:39 - 06:56] авторизация запоминается то есть последующие запросы браузер будет делать передавая заголовок авторизуешь так теперь давайте посмотрим еще раз повторим какие основные моменты в 13


Step 2 (S-44889) 5.png

[06:56 - 07:15] момент номер 1 когда пользователь первоначально делает запрос к ресурсу у него нет доступа а то есть не передано логин пароль от сервера отвечает кодом 401 не авторизован вместе с этим он передает специальный заголовок


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


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


[07:50 - 08:07] раскодировать в нем суббот 64 это примитивно задача для программиста поэтому при базовой авторизации мы считаем что пароль придется вообще в открытом виде так или иначе если пароль подходят


[08:07 - 08:25] сервер даст вернет документ который запрашивали если не подходят веб сервер ответят 403 а тут нужно понимать что проверка авторизации на самом деле происходит на каждый запрос то есть


[08:25 - 08:40] заголовков 3 браузера передаются с каждым запросом то есть в каждом запросе логин пароль запрос браузер авторизует пользователя а и соответственно и подает ему доступ либо не дали


[08:40 - 08:57] если мы говорим про код статический документ дает документ лего не отдает если мы говорим про а проксирование то есть если наш сервер отдает документа запускает скажем


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


[09:16 - 09:35] так или иначе в ремонт юзов содержится имя пользователя после того как он успешно авторизовался при проксировании эта информация не предается но не составляет труда ее добавить в отделе заголовок вот таким образом работает basic авторизации


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


Step 2 (S-44889) 6.png

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


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


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


[10:40 - 10:55] 1 недостаток то что логин пароль передается фактически в открытом виде это означает что его легко можно перехватить например послушать если у злоумышленника есть доступ к сети wifi


[10:55 - 11:13] а у него может перехватить пароль в открытом виде это опасно поэтому при использовании basic авторизации необходимо использовать спец с точки зрения безопасности а


[11:13 - 11:30] 2 недостаток невозможно сменить форму логина то есть форма входа куда вводится логин пароль от окна браузера а модальное окно которое всплывает у него стандартный дизайн и он никак не связан с вашего приложения


[11:30 - 11:48] соответственно в этом а в этом окне нет никаких опции только логин и пароль если вы хотите сделать опцию за по запомнить меня там на 5 дней этого ничего нет вы никак не можете кастомизировать процесс логин 2 - 3 - невозможность


[11:48 - 12:03] управлять авторизации а то есть мы говорили что пользователь вводит логин пароль 1 раз а браузеры запоминает и потом при каждом запросе передает а вот время в течение которого браузер


[12:03 - 12:19] передает эту авторизацию оно в разных браузерах по разному как правило это до закрытия окна пока текущее окно пользователь не закроет браузер будет считать что авторизация сохраняется да


[12:19 - 12:34] браузер закроется откроется заново авторизации так или иначе сайт приложение не может управлять авторизации не может ее сбросить например это существенный - а поэтому


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


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


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