Имеются вот расширения где присутствуют уникальные данные пользователя, но при это там нет авторизации. Как это работает? На стороне клиента генерируется уникальный ID, добавляем в LocalStorage и это и есть уникальность?
setupx, у меня вот один вариант есть как это примерно можно реализовать. После покупки услуги выдает ключ и этот ключ пользователь активирует и сам ключ храним уже. Но все равно, а вдруг у нас просто данные хранятся без каких-либо покупок
Решение: на стороне сервера у нас должен быть url который будет сверять переданный token из localstorage и если такого нет токена, генерируем новый и отдаем клиенту и кидаем в local. Все :)
да, всё верно. уникальность пользователя часто реализуется через генерацию уникального ID на стороне клиента. этот ID сохраняется в localStorage, и каждый раз при взаимодействии с расширением используется для идентификации пользователя
:-) :-) :-)
Ну подмените, пожалуйста, флаг в руки!
Если строка идентификации например 64 символа - сколько вы её будете подбирать, что бы она совпала с ID другого пользователя? Посчитали? Хотя-бы прикинули?
А теперь прикиньте поведение правильно построенного сайта, к которому 100500+ раз обратились с не существующими ID... Да даже 15-ти раз хватит!
0x80070005, подменить-то легко, зато подобрать реальный ID другого пользователя - черезвычайно сложно. Конечно если сайт адекватный, и не использует 123 в качестве идентификатора. А если ещё и отслеживает перескоки пользователя с одного IP+UserAgent на другой IP+UserAgent...
AUser0, у меня только вариант, что генерировать айди нужно на сервере с подписью и передавать клиенту и таким образом даже подделать его будет фактически сложно.
Хотя стоп! Если мы генерируем айди на сервере, то подписывать его не нужно получатся. Просто сверяем айди если он даже подделан и меняем в случае чего
0x80070005, да без разницы где генерировать случайный ID, хоть на сервере, хоть на клиенте. Главное - его длина/сложность, и его хранение/проверка на сервере. А дальше - хоть заподбирайся 64-ёхсимвольную, а ещё лучше 256-исимвольную случайную строку, ну-ну.
Нет, ну конечно, клиент, сгенерировавший себе ID в виде 000000000[64раза] - ССЗБ, это сразу понятно.
AUser0, разница есть. На клиенте если я буду генерировать токен и отдавать серверу, то смогу его подделать, а если я буду генерировать его на сервере и отдавать клиенту, подделать его уже невозможно :)
0x80070005, вы подделаете только свой токен, вот и всё. Взламывать самого себя по своему-же токену? И куда это вас приведёт?
Единственная проблема генерации токенов у клиента - это возможность заспамить сервер новыми неиспользуемыми токенами.
AUser0, я же вам выше пример приложил того, что может быть на клиенте. Представим, у нас генерация на клиенте идет и какой-то пользователь решил сделать себе токен «123» а не 16-ти битный. Другой пользователь что сделает? Возьмет откроет localstorage и просто укажет «123», ради интереса и тут у него оказывается доступ к другому аккаунту.
В случае генерации на стороне сервера, пользователь не сможет указать собственный токен.
Если генерировать на стороне клиента, его нужно подписывать. А-ля, использовать сквозное шифрование.
То, что я ему сгенерирую 64 битный токен на клиенте и отдам его серверу, ему ничего не помешает этот формат поменять. Это клиент
0x80070005, а с чего это вдруг клиент может менять токен как ему вздумается? Сервер не может проверить длину токена, количество символов в токене, их повторяемость типа 64 нуля подряд, не?
Простой
