A
Только ген.ключи
Size: a a a
2020 February 24
A
Но при этом нужно сделать такую генерку, которая отдаст одинаковые ключи
A
Это реально?
AP
Просто для личного кабинета и для клиента две разных таблицы юзеров. Для сайта я написал админку, проверки и тд. А вот для лоадера какую проверку сделать
2 таблици для юзеров? Зачем? Юзер есть юзер, админ, клиент и тд. Это все одна и та же абстракция. Они отличаются только правами, которые можно описать в других таблицах.
Я не совсем понимаю какая у тебя там схема и как происходит авторизация пользователя из клиента. Я это представляю как передача токена авторизации на сервер от каждого пользователя, чтобы нельзя было отсылать эти самые репорты без авторизации и необходимых прав на это
Соотвественно, если злоумышленник и отследит адрес скрипта, то без токена и прав ему он ничего не даст
A
Я не совсем понимаю какая у тебя там схема и как происходит авторизация пользователя из клиента. Я это представляю как передача токена авторизации на сервер от каждого пользователя, чтобы нельзя было отсылать эти самые репорты без авторизации и необходимых прав на это
У клиента есть окно авторизации, когда он проходит в авторизацию, то может управлять клиентом, но при этом идет фоновый поток, которые управляет защитой лоадер. Если он ловит какой-то подозрительный момент, то отсылает запрос на веб-часть, а точнее на php файл с функцией бана.
запрос подобие такого ban.php?hwid=12142414 и вот в чем загвоздка. Любой, кто смог отследить траффик клиента сможет зайди в браузер и задрачивать этот самый файл ban.php?hwid=12142414(меняя значения hwid), ибо никаких проверок нет
запрос подобие такого ban.php?hwid=12142414 и вот в чем загвоздка. Любой, кто смог отследить траффик клиента сможет зайди в браузер и задрачивать этот самый файл ban.php?hwid=12142414(меняя значения hwid), ибо никаких проверок нет
A
по этому у меня идея упала сразу на то, чтобы генерировать и на клиенте, и на веб-часте ключ. А потом сверять его и запрос будет уже подобие ban.php?hwid=13124&key=da2341a14csaf
A
Но при этом ещё нужно умудриться, чтобы генерка выдала одинаковый ключ
При авторизации что является гарантом авторизированности пользователя?
Ты его по ID отслеживаешь?
A
Передаю с клиента login, password и уже ищу его по базе. Если такой логин существует, то сверяем пароль и выдает print_r('suc'); а в клиенте прописывает подобие if(hashtostring == 'suc')
{
пишем нужный функционал
}
{
пишем нужный функционал
}
Передаю с клиента login, password и уже ищу его по базе. Если такой логин существует, то сверяем пароль и выдает print_r('suc'); а в клиенте прописывает подобие if(hashtostring == 'suc')
{
пишем нужный функционал
}
{
пишем нужный функционал
}
А что является гарантом авторизации пользователя в будущем?
A
а зачем в будущем? если ему клиент нужен, чтобы один раз авторизоваться, запустить нужный хак и клиент закроется
Если только по ID, у тебя проблема серьёзнее, я после авторизации могу подменить ID и притвориться другим пользователем, а это серьёзнее чем баны
A
оу
A
А как ты такое провернешь? допустим на обычном сайте. я сейчас посмотрел куки от своего сайта, там только phpsessid
A
или ты его и имел ввиду
А как ты такое провернешь? допустим на обычном сайте. я сейчас посмотрел куки от своего сайта, там только phpsessid
Как ты передаешь серверу информацию о том, что именно пользователь Вася Пупин нажал на кнопку?
A
Через логин с буфера или hwid, который прописан в таблице с юзерами. А уже находя этого пользователя, через хвид, проверяю его на наличие лицедеи