Login security как настроить

Скачать плагин LoginSecurity | Защитите аккаунты игроков на сервере Майнкрафт | Плагин на авторизаци

Опубликовано 30-05-2021, 11:01 Категория Плагины / 1.14 / 1.13 / 1.12 / 1.11 / 1.10 / 1.9 / 1.8 / Безопасность Просмотров 1 677

Описание плагина:

LoginSecurity — плагин на авторизацию, который должен быть у каждого. Данный плагин поможет Вам защититься от взлома аккаунтов, поставив предварительный пароль на Ваш аккаунт, который придумываете Вы сами. Также данный плагин предусматривает смену Вашего пароля при его забытии.

Особенности плагина:

— 6 полезных команд для управления паролем.

— Легкий, быстрый и простой в настройке.

— Безопасное хранение паролей с использованием стандартной криптографии.

— Защищает и скрывает местоположение и инвентарь пользователя.

— Продолжение сеанса на основе IP и времени.

— Простой административный контроль.

— Удобная система капчи для новых игроков.

— Используется тысячами владельцев серверов.

— Безопасность благодаря автоматическим уведомлениям об обновлениях.

— Предотвращение взломов кикает игроков если вход в систему совершён из другого места.

— 20+ поддерживаемых языков и многое другое.

Команды плагина:

/lac — Админ команда. (сменить пароль, перезагрузить плагин и т.д.)

/changepass — Изменить пароль.

/unregister — Разрегистрировать свой аккаунт. (только если пароль не требуется)

/logout — Выйти из сессии. (когда вы авторизованы)

Права плагина:

— ls.admin — Админ команды.

— ls.update — Получать уведомления о обновлениях.

Как установить плагин?

1. Скачайте плагин.

2. Возьмите скачанный файл и перенесите в папку plugins вашего сервера.

Источник

Как настроить авторизацию в Spring Security

Продолжим тему аутентификации и авторизации в Spring Security.

Аутентификация — это проверка пользователя на то, является ли он тем, кем себя выдает. Приложение спрашивает «кто ты», а пользователь, например, вводит имя и пароль. Приложение проверяет, что такому имени действительно соответствует такой пароль и отвечает ок, проверка пройдена.

Авторизация — это выдача прав (либо отказ). Происходит уже после того, как пользователь подтвердил свою идентичность. Допустим, пользователь прошел аутентификацию и хочет попасть на url:

Приложение проверяет, какие стоят права у данного пользователя, и либо впускает его, либо нет.

Например, user может зайти на url /user, а admin и на /user, и еще на другие url.

Подготовка

В прошлом примере мы настроили аутентификацию типа In-Memory, при которой пользователи хранятся в памяти приложения. Пример простой и подходящий для демонстрации настройки авторизации.

Контроллер

Но для того, чтобы настроить права (для двух пользователей), дополним контроллер еще парой методов. Итак, пусть будут две роли USER и ADMIN, а также три URL:

Контроллер теперь имеет три URL:

Пользователи (In-Memory athentication)

А настройка аутентификации (см. предыдущий пример) выглядит теперь так:

Теперь мы ввели два разрешения ROLE_USER и ROLE_ADMIN, а в прошлом примере было одно.

Вот теперь разрешения нам пригодятся — для настройки авторизации.

Настройка авторизации

Чтобы настроить авторизацию, надо точно так же, как мы делали при настройке аутентификации, переопределить метод configure(), только теперь с другим аргументом HttpSecurity:

Именно этот объект HttpSecurity и нужно настраивать. Создавать его как бин не надо, его создает Spring Security, а мы получаем к нему доступ из метода configure(HttpSecurity http).

Как мы видели в прошлой статье, по умолчанию Spring Security дает доступ к любому url любому аутентифицированному пользователю. Иначе говоря, если хочешь попасть на url, перенаправляешься на форму ввода пароля, и только после этого попадаешь на url.

Переопределив метод configure(HttpSecurity http), мы немедленно отменили поведение по умолчанию. Теперь внутри переопределенного метода все требуется задать заново вручную (с небольшими нововведениями).

Мы по очереди перечисляем возможные url и задаем права доступа к ним (точнее, в нашем примере — роли).

Перечисление url

Это строкой мы говорим предоставить разрешения для следующих url.

Далее мы перечисляем не сами url (поскольку их может быть слишком много), а шаблоны. Шаблоны url задаются с помощью класса AntPathRequestMatcher .

Перечислять шаблоны надо в порядке от самых узкоохватывающих до широкоохватывающих:

Например, следующие три url подпадают под шаблон /admin/**:

Если в коде начать перечисление с всеобъемлющего шаблона /**, то перебор на нем остановится (так как любой url, в том числе /admin) соответствует шаблону /** , а значит всем будет разрешен доступ. Именно поэтому начинать нужно с узкоохватывающих шаблонов.

Настройка доступа (роли, разрешения)

Наконец, к главному. После шаблона в каждой строке указывается кому разрешен доступ: всем пользователям (метод permitAll() разрешает доступ всем, в том числе неаутентифицированным пользователям) или пользователям с определенной ролью — метод hasRole(«ADMIN») (либо ролями).

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

Можно было задать доступ с помощью разрешений, результат был бы аналогичный:

Еще такой есть полезный метод:

Страница ввода пароля

Наконец, страница логина теперь генерироваться не будет, чтобы ее вернуть, допишем строку:

Если пользователь не аутентифицирован (в данном случае так будет, если в запросе либо отсутствует кукис JSESSIONID, либо он неправильный), то выполняется редирект на страницу ввода логина и пароля.

Ввод логина и пароля в форму считается аутентификцией типа Form-Based, что означает, что имя и пароль приходят в POST-запросе в параметрах username и password (такие имена параметров по умолчанию используются в Spring Security). То есть когда пользователь попадет на страницу логина и введен туда данные, на сервер пойдет новый запрос, в котором данные будут передаваться в этом самом POST.

Чтобы задать аутентификацию типа Http Basic, строка в коде должна быть такая:

В этом случае браузеру придет ответ с требованием показать нативную браузерную форму, куда пользователь так же вводит данные. Но эти данные в случае Http Basic —аутентификации передаются уже в другом виде — в заголовке:

Это устаревший и небезопасный способ.

Но суть в том, что обе эти строки указывают Spring Security, как именно он должен брать из запроса имя пользователя и пароль.

Итоги

Пример доступен на GitHub.

Также см. тут как защитить конкретные методы с помощью @Preauthorize.

Как настроить авторизацию в Spring Security: 13 комментариев

Здравствуйте, подскажите, пожалуйста, как со всеми аналогичными настройками авторизоваться через постман? json с передачей username и password в формате json (raw) и через form-data не сработали. Возвращается всегда 403

1) Надо отключить csrf в configure(HttpSecurity http) (так как из браузера он с формой передается, а из POSTMAN — нет):
http.csrf().disable();
2) ну и перeдавать в POST-запросе localhost:8080/login form-data, к примеру такие:
username: user
password: password

Спасибо! Помогло 🙂 Еще вопрос: мне нужно чуть усложнить приложение, чтобы пользователь имел доступ на редактирование только созданных им объектов. Соответственно, роль будет по-прежнему юзер, но ограничениями доступа к «чужим аккаунтам». Предполагаю, что это можно решить как-то средствами группового разграничения доступа, но пока не получилось найти адекватный источник реализации этого всего добра. Можете натолкнуть на мысль?

Можно сделать авторизацию на уровне методов, например, если пользователь приложения AppUser может редактировать только свой объект Thing, то аннотируем метод редактирования так:

@PreAuthorize(«authentication.principal.username.equals(#thing.appUser.username)»)
public Thing editThing(Thing thing) <
//.
>
(подразумевается, что Thing имеет ссылку на юзера)

Есть также Spring Security ACL — мощная вещь (но возможно избыточная, нужно создавать обязательные таблицы и т.д.)

Я так понимаю, в контроллере использовать @PreAuthorize не выйдет? Нужно вынести куда-то в отдельный класс? Потому что вот так у меня не сработало (хотя блог с юзером связаны) Запрос выполнился даже не связанный:
@PutMapping(«/blog/»)
@PreAuthorize(«authentication.principal.username.equals(#blog.user.username)»)
public ResponseEntity updateBlog(@PathVariable int id, @Valid @RequestBody Blog blog) throws EntityNotFoundException <
ModelMapper mapper = new ModelMapper();

if (!blogRepository.findById(id).isPresent())
throw new EntityNotFoundException(«The blog with + id + » doesn’t exist»);
Blog blogToUpdate = blogRepository.getOne(id);
blogToUpdate.setTitle(blog.getTitle());
blogToUpdate.setContent(blog.getContent());
blogRepository.save(blogToUpdate);
return ResponseEntity.ok().body(mapper.map(blogToUpdate, BlogDto.class));
>

1. Возможно не включили @EnableGlobalMethodSecurity(prePostEnabled = true) на главном классе.
2. @PreAuthorize рекомендуется ставить на методы сервисов

Вы очень понятно объясняете, спасибо большое за ваш труд!
2 связанных вопроса:
1. Откуда в конфиге вытаскивается информация о наличии у юзера определенной роли hadRole? Я использую jwt token, по вашему примеру делала фильтр, чтобы токен при запуске апп.проверялся, обновлялся (дата продлевается) и заново ложился в хедер реквеста перед возвратом в чейн — и дальше уже в контроллер

2. Допустим, в jwt токен есть роли в authorities. Что срабатывает раньше: наш конфиг со своими hadRole, или фильтр? А то выходит, фильтр мне обновит токен (дату, и вытащит в токен актуальные роли из бд с помощью userDetails), но секьюрити конфиг сработает раньше фильтра и не будет знать, что юзер уже админ, например

уточните, пожалуйста, что вы имеете в виду под «конфиг где вытаскивается информация о наличии у юзера определенной роли hadRole»?
В методе configure(AuthenticationManagerBuilder auth) указаны два In-Memory пользователя user и admin с ролями, но если у вас база, то этих пользователей в этом методе не должно быть. Они созданы как замена реальным для демонстрации примера.
P.S. их можно считать аналогом пользователей из базы, но только они пересоздаются каждый раз при перезапуске приложения в том же виде.

Подскажите, использую микросервисную архитектуру, и авторизация выполняется на другом сервере. У пользователя есть два токена. Токен досупа и refresh токен. Второй устаревает каждый 3 минуты. За его обновлением следит свой сервис.
Для доступа к основыным сервсам приложения пользователь в базовой аутентификации передает логин и пароль. Логи это токен доступа… пароль… refreshToken. Так как второй все время обновляется то компроментация ему не страшна.
Но есть пролблем. Спринг хеширует авторизацию. И при повторных запросах уже не проверяет ее если установлен куки JSESSIONID.
А так как токен устаревает, то проверять надо при каждом доступе к серверу.
Сейчас у меня такие настройки Spring Security

@Override
protected void configure(HttpSecurity http) throws Exception <
http
.csrf().disable()
.authorizeRequests().anyRequest().authenticated()
.and().httpBasic()
.and().sessionManagement().disable()
.logout().deleteCookies(«JSESSIONID»).permitAll();

http.addFilterAfter(
new CustomFilter(), BasicAuthenticationFilter.class);

Подскажите, может еще надо что то дописать, чтоб каждый запрос проходил процедуру авторизации?

В декомпилированном BasicAuthenticationFilter нашел вот такой метод private boolean authenticationIsRequired(String username) <
Authentication existingAuth = SecurityContextHolder.getContext().getAuthentication();
if (existingAuth != null && existingAuth.isAuthenticated()) <
if (existingAuth instanceof UsernamePasswordAuthenticationToken && !existingAuth.getName().equals(username)) <
return true;
> else <
return existingAuth instanceof AnonymousAuthenticationToken;
>
> else <
return true;
>
>

тут он как раз проверяет необходимость повторной авторизации. Но как это мне поможет не понимаю.

Что касается сессий: попробуйте их таким образом отключить:
http.sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS); (вместо .and().sessionManagement().disable())

Спасибо! Помогло!
У меня токен обновления живет 3 минуты. Может мне не отключать совсем сессию, а сделать у нее таймаут, пару минут. Чтоб уменьшить нагрузку на сервис авторизации?

Источник

Скачать плагин OpenLogin & nLogin [1.17 — 1.7.10] | плагин авторизации для сервера Майнкрафт 1.3

Описание плагина nLogin:

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

В прошлом плагин назывался nLogin

Как установить плагин OpeNLogin?

1. Скачайте плагин.
2. Возьмите скачанный файл и перенесите в папку plugins вашего сервера.
3. Перезапустите сервер.
4. Готово.

Конфигурационные файлы плагина OpeNLogin

Это файл messages_ru.yml русского перевода плагина,

Его не нужно копировать и вставлять себе.

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

Как включить русский язык в плагине OpeNLogin

В плагине есть встроенная поддержка русского языка

Для начала установите плагин как написано выше, и запустите сервер.

Как только сервер загрузится, выключаете его командой stop в консоли.

Далее открываете config.yml плагина (/plugins/nLogin/config.yml)

Ищите строчку: languageFile.

На этой строче заменятете messages_br.yml на messages_ru.yml

Сохраняте и закрываете config.yml.

Всё, теперь у вас включён русский язык

Источник