LINUX.ORG.RU
Форум — Web-development  

токены. просветление

 ,


0

1

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

вот ход моей мысли: 

1. чувак хочет зайти в свой личный кабинет интернет-банка
2. он в своём браузере набирает адрес и видит форму авторизации
3. заполняет форму авторизации, после чего пароль отправляется запросом на сервер и там кодируется и записывается в БД
4. сервер генерирует уникальный токен и посылает в ответ клиенту
5. клиент помещает токен в куку, локалсторадж или другое удобное хранилище(возможно, тоже кодирует)
6. при этом сам токен никакого влияния на авторизацию не оказывает
7. далее чувак, например переводит часть денег со своего счёта на телефон
8. а потом переводит часть денег со своего счета на оплату интернета
9. роль токена, прикрепляемого к каждому запросу, состоит только в том чтобы убедить сервер, что запросы в пунктах 7 и 8 выполняет один и тот же человек(браузер)
10. сама же авторизация выполняется только на основе пароля и логина. без участия токена
если я в каких-нибудь пунктах не прав, скажите мне об этом. а так же посоветуйте на какую тему стоит почитать что-нибудь чтобы точно понимать что происходит

★

Последнее исправление: prozaik (всего исправлений: 1)
← Общие модели в Django
FatFree, really? →

Мне кажется, что ты пытаешся найти глубокий смысл там, где его нету.

В большинстве случаев токены нужны только для того, чтобы оставить за сервером возможность управления сессиями.

Напр: Сегодня парень зашел на сайт, залогинился и в куках сохранился не логин с паролем, а токен. Таким образом нет необходимости с каждым запросом к серверу гонять по сети логин/пароль, а серверу в свою очередь нет необходимости каждый раз проверять этот логин с паролем (иногда это занимает драгоценное процессорное время, тккак нужно напр вычислиьь хэш).

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

cyber_eagle
()

роль токена, прикрепляемого к каждому запросу, состоит только в том чтобы убедить сервер, что запросы в пунктах 7 и 8 выполняет один и тот же человек(браузер)

Почему бы и нет... А еще можно удалять старый токен при повторной авторизации.

Тогда мы будем знать, что с акаунтом одновременно может работать только однин браузер.

cyber_eagle
()

Тоже с этим мучался. п.3 - пароль сохраняется не когда ты входишь (если я правльно понял, вход===аутентификация), а когда регистрируешься (=== авторизация). Т.е. в п.3 вычисляется хеш пароля и сравнивается с записанным в БД хешем ,к -рый был создан из твоего пароля при аутентификации.

Вот чтиво про токены. Оно явно взято с англоязычного сайта и переведено машинным переводом, оригинал, наверное, можно найти по URL :)

http://qaru.site/questions/101423/best-practices-for-server-side-handling-of-...

п.6. - просто, если у тебя токен есть, то сервер знает, что это тот токен, который этим сервером отправлен. Выдан ли он нашему чуваку или какому-то ещё - то неведомо. Сервер может хранить сессию и по ней проверять, что этот токен был выдан нашему чуваку, а не какому-то другому. Если сервер не хранит сессию, то мне кажется, что он не может проверить, кому именно он выдал этот токен. Т.е. кража токена позволяет делать действия от имени любого пользователя.

ИМХО (тоже интересно, если меня кто-то поправит).

den73 ★★★★★
()

3. заполняет форму авторизации, после чего пароль отправляется запросом на сервер и там кодируется и записывается в БД

При авторизации обычно пароль не записывается в БД.
Он записывается на этапе регистрации или изменения пароля.

На данном шаге нам нужно проверить, что связка «логин-пароль», присланная с интернетов, действительно существует в БД.

Для этого нам нужно выполнить вот это:
1. Взять полученные логин и пароль и заэскейпить их, чтобы нам не передал привет SQL Injection.
2. Отправить селект-запрос в базу, чтобы найти логин.
3. Если нашли запись по логину, то привоидм пароль в нужный вид (если требуется).
4. Сверяем пароли. Если совпадают, переходим к следующему шагу. Если нет, отправляем ответ с 401-м кодом (ну или что-то другое делаем - зависит от требований бизнеса).

На этом шаг 3, если его рассматривать в общих чертах, завершён.

blackst0ne ★★★★★
()

Токен - это просто такой кэш-костыль, чтобы не заставлять клиента на каждый запрос вводить логин и пароль.

Проверили один раз логин-пароль, выдали билетик на ограниченное время. Дальше проверяем только билетики.

Проблема с токенами в том, что их можно стырить и делать злые действия от чужого имени.

blackst0ne ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Общие модели в Django
Web-development
FatFree, really? →