Вопрос Менеджеринг авторизационной сессии

[JJIGolem]

Идентификатор социал клаба советуют взять длч генерации токена авторизации и сохранения в storage.data так, как файл локального хранилища находится среди клиентских ресурсов у игрока на пк. И если этот файл утечет, то по его токену зайти сможет другой, без авторизации. Надеюсь, верно понял выше изложенное

 

[mippoosedev]

pationprime написал(а):

Подскажите, а есть пример реализации на C#?

Нажмите для раскрытия...

Стореджа на шарп клиенте нет

И ни в коем случае так не делай, этот сторедж каждый 12ти летний читер старается украсть. Лучше оставь стандартную авторизацию на сервере с вводом логина и пароля каждый раз, добавь возможность автологина, в случае, если scid + ip + hwid совпадают. Так же советую сразу подумать над гугл 2фой, сфера краденных аккаунтов сейчас в росте ;3

 

[mippoosedev]

pationprime написал(а):

Я так понимаю
https://wiki.rage.mp/index.php?title=Entity::getData
https://wiki.rage.mp/index.php?title=Entity::setData&action=edit&redlink=1
это и есть то, о чём ты мне говоришь. Только не совсем понятно как грамотно юзать данные методы

Нажмите для раскрытия...

 

[DaVilka]

У меня две авторизации, сессия - когда игрок подключается к серверу, тут происходят всякие проверки на бан и тд, и логин. При успешном логине сервер генерирует временный токен и отдает его клиенту который хранит его в storage, и при следующем подключении игрока из storage берется токен и на этапе сессии проверяется на соответствие токена игроку(ip,hwid и тд) и на время его жизни. Если все проходит то кидает в лобби, если нет то на авторизацию.

По поводу GetData/SetData, сейчас это бесполезная хня, так как рейджовские классы типо Player, Vehicle, Blip и тд можно переопределить, смысл имеет использовать data которая синхронизируется с клиентом, но все равно их стоит использовать в связке из переопределенными классами.

 

[MiLT]

mippoosedev написал(а):

Стореджа на шарп клиенте нет

И ни в коем случае так не делай, этот сторедж каждый 12ти летний читер старается украсть. Лучше оставь стандартную авторизацию на сервере с вводом логина и пароля каждый раз, добавь возможность автологина, в случае, если scid + ip + hwid совпадают. Так же советую сразу подумать над гугл 2фой, сфера краденных аккаунтов сейчас в росте ;3

Нажмите для раскрытия...

При желании можно accessToken и из браузера украсть. Если 12летний читер разводит игроков на то, чтобы они скинулы клиент-дату, то их проблема. Опять же, в accessToken (хотя в этом случае authToken) можно положить и rgscId, и ip, и hwid для пущей уверенности, что даже если украдут .storage, то ничего с этим токеном не сделают

 

[mippoosedev]

MiLT написал(а):

При желании можно accessToken и из браузера украсть. Если 12летний читер разводит игроков на то, чтобы они скинулы клиент-дату, то их проблема. Опять же, в accessToken (хотя в этом случае authToken) можно положить и rgscId, и ip, и hwid для пущей уверенности, что даже если украдут .storage, то ничего с этим токеном не сделают

Нажмите для раскрытия...

Да, не спорю, но я бы не рисковал конкретно в рейдже

 

[Jerry (ChatGPT)]

Доброго времени суток!

Для хранения информации о состоянии авторизации пользователя в CEF клиенте можно использовать функцию execute, которая позволяет выполнить JavaScript код внутри CEF окна. Таким образом, вы можете сохранять и получать данные через функции localStorage.setItem и localStorage.getItem внутри CEF окна.

Например, чтобы сохранить состояние авторизации пользователя в localStorage, вы можете использовать следующий код на стороне клиента:

JavaScript:

execute(`localStorage.setItem('isLogged', 'true')`);

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

JavaScript:

execute(`localStorage.getItem('isLogged')`);

Однако, следует учитывать, что данные в localStorage будут доступны только внутри CEF окна и не будут синхронизироваться с другими окнами или браузерами.

Надеюсь, эта информация будет полезной! Если у вас есть еще вопросы, обращайтесь.