Почему на али и ряде китайских магазинов авторизация(и работа с ней) на Js?

Question

[Ainur Shakirov]

Если заходить на али и не безвестный JD, то загружается кнопка "войти", а только потом JS подменяет его на "мой аккаунт".

С чем это связанно? Для чего сделано так? Безопасность? Костыль?
Ведь для юзера это дико не удобно, особенно если медленный интернет.

Answer 1

[Толстый Лорри]

Потому что сейчас модно делать "толстые" интерфейсы на javascript и REST api бэкенд, к которому обращается UI (через ajax) с минимумом перезагрузок страницы.

Скрипты весят много, генерируют дополнительные запросы, из-за чего сначала прогружается просто статическая страничка (с кнопкой), потом подъезжают скрипты (они подключаются в самом низу, перед </body>), снова делают ajax-запрос к серверу: "А авторизован ли этот юзер?", на что сервер отвечает: "да", и скрипт рисует ссылку на "мой аккаунт".

Так что это, скорее, баг, как особенность сайтов с rich-UI.

Comments

[xmoonlight]

Чушь не говорите!!! Это формирование токена для текущей сессии, чтобы шифровать трафик.

[Толстый Лорри]

xmoonlight: Эм...трафик шифруется средствами SSL без всяких токенов и джаваскрипта.

Еще раз прошу: пойдите почитайте что-нибудь про HTTP, что такое куки, как работает браузер и HTTP-сервер, как реализуется аутентификация для веб-приложений и что такое ассиметричное шифрование, прежде чем стоить догадки.

[xmoonlight]

Free_ze: Ок. А Вы - про шифрование без SSL.

[Толстый Лорри]

xmoonlight: Спасибо, я об этом знаю достаточно и с радостью делюсь с желающими)

А не могли бы вы мне объяснить смысл формирования токена сессии на клиенте (в потенциально небезопасной среде), а не на сервере, где, собственно, хранятся данные сессии?
Просто у вас в инфо написано: "комплексная архитектура крупных проектов, создание API для любых задач и безопасная авторизация пользователей", наверняка вы - матерый специалист в области ИБ и веб-сервисов.

[xmoonlight]

Free_ze: токен сессии - формирует сервер, а токен прохождения аутентификации - клиент на основе серверных данных. Т.к. сервер знает Ваш пароль (его хэш или plain))) ), Вы - свой пароль в plain. Сервер отсылает Вам формулу шифрования и свой ключ, основанный на текущей сессии (IP, useragent и других), и ждет пару секунд ответа (иначе - верное совпадение считается недействительным). Получая формулу, JS (браузер) подставляет туда все нужные значения, формирует ответный хэш и отправляет обратно на сервер. Сервер сверяет и если все верно, формирует новый длинный ключ и привязывает его к текущей сессии и отправляет клиенту. Клиент использует его в формуле для отправки последующих запросов серверу в зашифрованном виде, используя любой тип обратимого шифрования.
Смысл простой: нет доверия SSL шифрованию.

[Толстый Лорри]

xmoonlight: Если мы не доверяем SSL, то такая аутентификация боится MITM =)

[xmoonlight]

Free_ze: ну, я бы так не сказал))) (я тестировал)

[Толстый Лорри]

xmoonlight: Вы уже сломали SSL?

[xmoonlight]

Free_ze: я воздержусь от комментариев)

Answer 2

[xmoonlight]

Это "кривость" концептуального алгоритма автоматической авторизации. (а не кода или кодера)
Вначале, нужно проверить, а потом уже - показывать: залогинен или нет.
А не делать автоматическую авторизацию, визуализируя процесс как мультик.

Comments

[Толстый Лорри]

Почему бы не проверить до возвращения ответа пользователю?

[xmoonlight]

Free_ze: куки обрабатываются только после загрузки страницы для очередной отправки.

[Толстый Лорри]

xmoonlight: Клиент каждый раз отправляет серверу куки с запросом. RTFM

[Ainur Shakirov]

xmoonlight: ну а для чего так то сделано, а не по обычному?

[xmoonlight]

Ainur Shakirov: шифруют они через JS данные авторизации.

[Толстый Лорри]

xmoonlight: Как все плохо)

Авторизация - это проверка прав доступа. На клиенте она НИКОГДА не выполняется.
Клиенту выдается кука с его идентификатором, который он все время ее жизни предъявляет серверу при любом запросе (гуглить "протокол HTTP заголовок Cookie"). Это называется АУТЕНТИФИКАЦИЯ. Выполняется она так же сервером и джаваскрипт клиента здесь тоже не нужен =)

[Толстый Лорри]

xmoonlight: И, да, погуглите еще про ajax!

[xmoonlight]

Free_ze: Ваш уровень достаточно низок: MD5CRAM читайте повнимательнее и дальше на его основе можно делать формирование ключа на клиенте.

[Толстый Лорри]

xmoonlight: На Алиэкспрессе не используется ни MD5CRAM, ни какое-либо другое клиентское шифрование.

Еще раз: зачем шифровать уже зашифрованный трафик?)

[xmoonlight]

Free_ze: токен сессии - формирует сервер, а токен прохождения аутентификации - клиент на основе серверных данных. Т.к. сервер знает Ваш пароль (его хэш или plain))) ), Вы - свой пароль в plain. Сервер отсылает Вам формулу шифрования и свой ключ, основанный на текущей сессии (IP, useragent и других), и ждет пару секунд ответа (иначе - верное совпадение считается недействительным). Получая формулу, JS (браузер) подставляет туда все нужные значения, формирует ответный хэш и отправляет обратно на сервер. Сервер сверяет и если все верно, формирует новый длинный ключ и привязывает его к текущей сессии и отправляет клиенту. Клиент использует его в формуле для отправки последующих запросов серверу в зашифрованном виде, используя любой тип обратимого шифрования.
Смысл простой: нет доверия SSL шифрованию.

Answer 3

[Алексей Николаев]

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

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

Answer 4

[sim3x]

Кеширование всего и вся
Те отдаем всем одну и ту же страницу из памяти, а лучше из кеша браузера, а потом уже модифицируем под пользователя

Быстрее или медленне еще нужно мерять