Вопрос Какой плагин для авторизации с привязкой к соцсетям считается лучшим?
- Автор темы DrEa3
- Дата начала
-
- Теги
- auth авторизация
Без прокси таких плагинов нет. В целом, плагин авторизации не на прокси - небезопасная идея
DrEa3
Пользователь
- Сообщения
- 91
- Решения
- 1
Я сам это знаю но друг себе не может позволить пока что прокси вот и я начал искать решение на это!
- Сообщения
- 1 367
- Решения
- 47
Ну, если ставить на серверное ядро - согласен. У прокси больше преимуществ. Но сама концепция прокси является маршрутизацией игроков по серверам. В таком случае, наоборот, самый безопасный способ реализации авторизации - это децентрализованный и масштабируемый внешний сервис со всей логикой авторизации. Прокси плагин должен выступать в роли моста между каким-то сторонним сверх-быстрым сервисом на базе какого-то Лимбо сервере. А если он еще написан на Go или Rust по типу Picolimbo, то там потребление на миллионы игроков минимальное...
Так кстати говоря работает Sonar 3.0, он проверяет игроков на своих серверах и затем маршрутизирует их по нужных Бэкэндам, освобождая нагрузку серверов во время атак. Для бизнеса эта концепция буквально лучшая, т.к на основных серверах/прокси не тратятся ресурсы/процессорное время зря. После этапа проверки на ботов можно вешать и другие системы, например аунтификации по паспорту/гос услуги, биометрией, OAuth2 и т.д. Технически и архитектурно такое решение более правильное для любого вида авторизации.
Просто писать такое всем в падлу.
Нет рациональных причин иметь что-то больше, чем прокси + 1-2 инстанса пиколимбо. Выделение авторизации во внешний сервис сильно усложнит интеграцию с прокси из-за отсутствия прямого доступа к состоянию игрока
- Сообщения
- 585
- Решения
- 7
Ещё и сильно увеличится возможная поверхность для атак. Но с другой стороны это компенсируется безопасностью данных пользователей.
- Сообщения
- 1 367
- Решения
- 47
1. Невозможно сделать отказоустойчивую систему. Например чтобы люди никогда не замечали, что ваще что-то перезагружается или обновляется.
2. Невозможно расширять проекты больше 3к онлайна без вмешательства в код. Очень тупо при таком онлайне держать один инстант.
3. Это стандарт индустрии гейм дева и IT компаний уже много лет. Просто Minecraft сервера отсталые, они не знают что такое распределение нагрузки и масштабируемость.
4. Попрог входа устанавливается лишь тем, как ты организовал архитектуру системы. Хотя ладно, даже сейчас многие ноют что им сложно настроить Velocity/Bungeecord
5. Не усложняет интеграцию с Proxy. Тебя разработчики микро-сервисов и облачных интеграций просто закопают за такие вот слова xD
А вот и нет, все как раз-таки наоборот. Можно распределять узлы авторизации на разные сервера, но дело даже не в этом. Просто тут выступает уже сама архитектура систем защит от ботов, где проверка происходит внутри прокси, а не на внешнем сервисе. В отличии от того же sonar, NullcordX не позволяет поднимать /иметь внешние сервисы и указывать backend для подключения. Это означает, что тебе придётся делать костыль в виде "Игрок прошёл проверку на бота на Proxy -> Попал на лимбо сервис авторизации -> Попал обратно на прокси".
На самом деле, вот по этому такая архитектура сейчас костыльная из-за работы анти-бот защит. Зачем ваще позволять нагружать прокси? Его задача лишь перенаправлять игроков и управлять серверами, хотя последнее это лишь удобная особенность самого Minecraft. Это буквально худшее решение в бизнесе, которое можно было придумать. Но самое логически простое, по этому винить разработчиков анти-бот защит не имеет смысла. Тем более это покрывает свой спектр потребностей.
На самом деле идеальная экосистема выглядит так:
Игрок проходит проверку на бота на внешнем сервисе
Игрок проходит авторизацию на внешнем сервисе
Подключается к прокси серверу
Игровые сервера
Атаки и сама логика авторизации физически не происходят на прокси сервере, он лишь получает подтверждение от сервисов, что игрок прошёл проверки или авторизован, чтобы позволить ему зайти на прокси сервер. Это снимает огромную нагрузку, потому что ты можешь запустить сервисы на внешнем хосте. Если что-то упадёт или случится, можно за секунды поднять на другом.
Я думаю ни у кого нет столько времени на реализацию действительно современных систем. Короче, остаемся в эре динозавров.