Увеличить пароль на сервере

[IshidaRex]

Хроники

1. Interlude

Исходники

Присутствуют

Сборка

Pain Team

Всем доброго времени суток. Таков не большой вопрос возник, хотел увеличить максимальное колиество символов что бы можно было вводить до 23 символов и цыфр. Но в итоге если вводишь пароль для аккаунта допустим 24 символа, то на сервер не пускает пишет не правильный пароль, если воодишь из 12 симвалов пароль то все работает.
Как я понял максимальное количество пароля меняется в файле loginserver.properties

# Автоматическое создание аккаунтов
AutoCreateAccounts = True
# Шаблон для логина и пароля
AccountTemplate = [A-Za-z0-9]{3,14}
PasswordTemplate = [A-Za-z0-9]{3,16} - с 16 заменил до 32

 

[artiompiii]

А сам клиент игры тоже должен реагировать на эти символы

 

[IshidaRex]

А сам клиент игры тоже должен реагировать на эти символы

В каком именно файле?

 

[artiompiii]

В каком именно файле?

Тут то я не знаю...

 

[Test]

Не получится больше сделать ибо есть лимит в клиенте который просто так не повысить.

 

[Argest]

Сделайте просто серверную опцию второго пароля, и туда запихайте свои 24-32 символа. Быстрая и простая реализация...
Еще можно пароли эти держать в шифрованном каком-нибудь xml файле, а не в бд, что уж 100% до него негодяи разные не добрались)

 

[crossover]

Сделайте просто серверную опцию второго пароля, и туда запихайте свои 24-32 символа. Быстрая и простая реализация...
Еще можно пароли эти держать в шифрованном каком-нибудь xml файле, а не в бд, что уж 100% до него негодяи разные не добрались)

Опция второго пароля есть, так называемый ключ. За базу хорошая подсказка, вынесу сохранение ключей из бд в xml.

 

[Aristo]

Опция второго пароля есть, так называемый ключ. За базу хорошая подсказка, вынесу сохранение ключей из бд в xml.

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

 

[Argest]

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

2 миллиона аккаунтов хм.... даже на астериосе или глобале таких показателей нету даже близко...
Для реальностей ла2 хорошо если там за 2-3 года лайф сервера набежит тысяч 100. Ну а для интерлюда еще поменьше...

ЗЫ Логи сборки в лайф режиме пишут в текстовики около 30-40 гигов логов в сутки, там много миллионов строк и сборке совершенно пофигу. Откровение для тебя?)

А синхронность тут вообще с какого бока? java отлично синхронит любые файлы если релизить нормально.


P/S У меня в офисе обрабатывает java приложение 11 миллионов строк из xml, и по тестам представь себе sql выполняет дольше просто все привыкли к sql, так как многим "кодерам" проще запросы в бд делать чем писать макросы или алгоритмы для xml.

 

[Aristo]

2 миллиона аккаунтов хм.... даже на астериосе или глобале таких показателей нету даже близко...
Для реальностей ла2 хорошо если там за 2-3 года лайф сервера набежит тысяч 100. Ну а для интерлюда еще поменьше...

ЗЫ Логи сборки в лайф режиме пишут в текстовики около 30-40 гигов логов в сутки, там много миллионов строк и сборке совершенно пофигу. Откровение для тебя?)

А синхронность тут вообще с какого бока? java отлично синхронит любые файлы если релизить нормально.


P/S У меня в офисе обрабатывает java приложение 11 миллионов строк из xml, и по тестам представь себе sql выполняет дольше просто все привыкли к sql, так как многим "кодерам" проще запросы в бд делать чем писать макросы или алгоритмы для xml.

Я не буду с вами спорить, т.к мне похер.

 

[MaZz]

2 миллиона аккаунтов хм.... даже на астериосе или глобале таких показателей нету даже близко...
Для реальностей ла2 хорошо если там за 2-3 года лайф сервера набежит тысяч 100. Ну а для интерлюда еще поменьше...

ЗЫ Логи сборки в лайф режиме пишут в текстовики около 30-40 гигов логов в сутки, там много миллионов строк и сборке совершенно пофигу. Откровение для тебя?)

А синхронность тут вообще с какого бока? java отлично синхронит любые файлы если релизить нормально.


P/S У меня в офисе обрабатывает java приложение 11 миллионов строк из xml, и по тестам представь себе sql выполняет дольше просто все привыкли к sql, так как многим "кодерам" проще запросы в бд делать чем писать макросы или алгоритмы для xml.

Я не буду с вами спорить, т.к мне похер.

А я поспорю. Всё зависит от задачи и что хранится в xml.
Было бы всё так просто, разрабы наверное не изобретали СУБД работающие исключительно с ОЗУ, а сразу бы всё пихали в xml.

P.S. запись лога не есть чтение данных. и выполняется в разы быстрее, т.к. нет никакого поиска.

 

[Aristo]

А я поспорю. Всё зависит от задачи и что хранится в xml.
Было бы всё так просто, разрабы наверное не изобретали СУБД работающие исключительно с ОЗУ, а сразу бы всё пихали в xml.

P.S. запись лога не есть чтение данных. и выполняется в разы быстрее, т.к. нет никакого поиска.

Зачем спорить с некомпетентными людьми? В его сообщении достаточное количество информации, чтобы судить о его компетенциях и соответственно, сделать выводы и не тратить свое время.

 

[Argest]

А я поспорю. Всё зависит от задачи и что хранится в xml.
Было бы всё так просто, разрабы наверное не изобретали СУБД работающие исключительно с ОЗУ, а сразу бы всё пихали в xml.

P.S. запись лога не есть чтение данных. и выполняется в разы быстрее, т.к. нет никакого поиска.

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

Что касается xml, то вполне безопасно и быстро хранить файлики 2-5 мб, 10-20-100 тысяч строк вообще полная хрень, как более безопасный метод хранения данных игроков я бы такое вполне советовал и да представьте, многие модули защит используют для хранения данных именно xml не sql,
Не люблю этих волшебных людей фанатов забивать все в sql.
Благодаря таким мы даже сейчас находим сборки в которых даже статика хранится в sql.... (Не ну а че давайте уж запихаем в sql все итемы, скиллы, рецепты удобно же?)

 

[MaZz]

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

Что касается xml, то вполне безопасно и быстро хранить файлики 2-5 мб, 10-20-100 тысяч строк вообще полная хрень, как более безопасный метод хранения данных игроков я бы такое вполне советовал и да представьте, многие модули защит используют для хранения данных именно xml не sql,
Не люблю этих волшебных людей фанатов забивать все в sql.
Благодаря таким мы даже сейчас находим сборки в которых даже статика хранится в sql.... (Не ну а че давайте уж запихаем в sql все итемы, скиллы, рецепты удобно же?)

Разговор про 11кк строк в xml и sql.
То что сейчас ты написал, это всё понятно.

Для поиска в логах админу, не нужно моментального выполнения запроса.

 

[Argest]

Разговор про 11кк строк в xml и sql.
То что сейчас ты написал, это всё понятно.

Для поиска в логах админу, не нужно моментального выполнения запроса.

Ну 11кк строк, я не относил этого к ла2. Ты где столько данных то найдешь? Тут даже если итемдату игроков вытянуть 2-3кк строк будет всего-лишь за пол года сервера... про 1кк это выполняет приложение в офисе. Там тоже моментального ответа не требуется, но изначально система была на sql и ее фризило жутко)
Если тебе понятно, что я написал к чему вообще спор? Есть же золотое правило, не храни все яйца в 1 корзине...
SQL вещь очень нужная и хорошая, но не нужно на ней одной зацикливаться)

 

[MaZz]

Ну 11кк строк, я не относил этого к ла2. Ты где столько данных то найдешь? Тут даже если итемдату игроков вытянуть 2-3кк строк будет всего-лишь за пол года сервера... про 1кк это выполняет приложение в офисе. Там тоже моментального ответа не требуется, но изначально система была на sql и ее фризило жутко)
Если тебе понятно, что я написал к чему вообще спор? Есть же золотое правило, не храни все яйца в 1 корзине...
SQL вещь очень нужная и хорошая, но не нужно на ней одной зацикливаться)

Я поэтому и написал зависит от задач.

 

[crossover]

Ранее хранилось в xml пару тысяч ключей без каких либо проблем, на большее количество пока не рассчитываем.

 

[MrKirill1232]

Сделайте просто серверную опцию второго пароля, и туда запихайте свои 24-32 символа. Быстрая и простая реализация...
Еще можно пароли эти держать в шифрованном каком-нибудь xml файле, а не в бд, что уж 100% до него негодяи разные не добрались)

Вы не можете просматривать ссылку пожалуйста воспользуйтесь следующими ссылками Вход или Регистрация

OTP поле можно еще использовать, но туда, скорее всего, только инт символы можно запихнуть.
Еще можно использовать "одноразовые коды" как у японцев сделано, но там только 4 символа можно написать и то вроде числовых.

 

[ANZO]

Сделайте просто серверную опцию второго пароля, и туда запихайте свои 24-32 символа. Быстрая и простая реализация...
Еще можно пароли эти держать в шифрованном каком-нибудь xml файле, а не в бд, что уж 100% до него негодяи разные не добрались)

Если злоумышленник получит доступ к вашей СУБД при условии что она портами на мир не светит (т.е. фактически имеет доступ к файловой системе) - хоть в чем храните свои ключи и шифруйте хоть чем - толку от этого как мертвому припарка.
В остальном скорость асинхронной записи/чтения без acknowledge в ту же мускуль с выключенным журналированием, с нормально настроенной очередью, размером кэша (уже не говорю об такой элеметарной вещи как ключи) сопоставима с скоростью записи в файл.
Только на выходе с SQL вы получаете возможность, как минимум, связывать поля идентификаторов (accountId/playerId/itemId и проч.) с записями в логах, централизованное хранение, поиск, фильтр - а не грузить этот лог в какой-то кастомный просмотрщик-парсер.

 

[Argest]

Если злоумышленник получит доступ к вашей СУБД при условии что она портами на мир не светит (т.е. фактически имеет доступ к файловой системе) - хоть в чем храните свои ключи и шифруйте хоть чем - толку от этого как мертвому припарка.
В остальном скорость асинхронной записи/чтения без acknowledge в ту же мускуль с выключенным журналированием, с нормально настроенной очередью, размером кэша (уже не говорю об такой элеметарной вещи как ключи) сопоставима с скоростью записи в файл.
Только на выходе с SQL вы получаете возможность, как минимум, связывать поля идентификаторов (accountId/playerId/itemId и проч.) с записями в логах, централизованное хранение, поиск, фильтр - а не грузить этот лог в какой-то кастомный просмотрщик-парсер.

Что касается логгирования, то внутри игры это куда быстрее и удобнее обрабатывать если скрипт написан ровно)
Что касается доступа к бд - то не соглашусь. Если у человека стоит полностью закрытый линукс, и злоумышленники смогли подобрать пароль к mysql, это ничего им кроме доступа к бд не даст. То есть фактически ты сможешь только вытянуть базу данных и больше ничего.

Файлы из системы хоть убейся в потолок не вытянешь, чтобы получить доступ к ним тебе придется искать куда больше, чем доступ к бд.