|
   |
| Модератор форума: Dimitro |
| Форум TrinityCore [TrinityCore] Help Авторизация игрока с параметрами (Авторизация игрового клиента с дополнительными параметрами) |
| Авторизация игрока с параметрами |
Всем привет!
Заинтересовал такой вопрос, можно ли внедрить дополнительный параметр при авторизации игрока на сервере? То есть, игрок вводит лог, пасс и к этому всему добавляется какая нибудь переменная, где сервер авторизации проверяет ее наличие (например, сравнивает значение в отдельной базе), далее проверяет лог пасс и только после этого разрешает игроку войти в игру. Есть идеи, как это можно сделать ? Добавлено (22.03.2018, 10:36) 
Сообщение # 1 написано 22.03.2018 в 10:36
|
Разумеется. Узким местом, однако, будет клиентская сторона (т.к. там передача такой переменной предусмотрена не была, а исходного кода от нее нет). Применение ряда методик позволит обойти эту проблему (серверную сторону, само собой, надлежит изменять в любом случае, однако это никакой сложности в данном контексте не представляет, т.к. она целиком открыта):
Без изменений исполняемого файла #1: Смотреть API клиента и пытаться использовать его функционал при помощи Lua-аддона (существует официальная книга, насколько я помню, аж в двух изданиях, написанная сотрудником Blizzard, которая покрывает как сам Lua, так и потенциал его применения в рамках разработки аддонов для официального клиента; без труда найдете в интернете электронную копию). Пользователям предоставляется аддон. Следует иметь в виду, что в этом случае весь код, отвечающий за сбор и пересылку параметра на клиентской стороне будет по умолчанию открытым, что может поставить под удар всю затею, если она является реализацией какой-нибудь системы безопасности. Без изменений исполняемого файла #2: Вынести процесс авторизации из клиента во внешнее приложение (самописный лаунчер, например). Данные, присылаемые через форму аутентификации из клиента при этом можно будет игнорировать на сервере. Саму форму можно как оставить, так и вырезать (предпочтительнее). Пользователям предоставляется лаунчер и, в зависимости от решения по оформлению, аддон. Сбор и отправка параметра могут находиться в закрытом виде (зависит от средств написания лаунчера). С изменением исполняемого файла: Вероятно, наиболее трудоемкий подход. В этом случае производится реверс-инженеринг клиента для выявления компонента, отвечающего за сериализацию и отправку реквизитов авторизации. Далее эта подпрограмма изменяется на угодный Вам манер: либо исчерпывающим исправлением исполняемого файла, либо достаточным для инъекции в него динамической библиотеки, в которой и будет прописан требуемый функционал (в этом случае можно будет использовать более высокоуровневый язык). Пользователям предоставляется измененный исполняемый файл и/или динамическая библиотека и аддон для изменения интерфейса формы аутентификации. Сбор и отправка параметра обязательно находятся в закрытом виде. |
| |||
| |||