SPRING BOOT, SPRING SECURITY и REST

• 
  Spring security
  

Это фреймворк, набор фильтров сервлетов, которые помогают добавить аутентификацию, авторизацию и защиту от распространенных атак в веб-приложение.

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

Базируется на двух интерфейсах, которые определяют связь сущностей с секьюрностью: UserDetails и GrantedAuthority.

UserDetails - то, что будет интерпретироваться системой как пользователь.

GrantedAuthority - сущность, описывающая права юзера.

Аутентификация и авторизация должны на уровне фильтров до выполнения любой иной логики приложения.

• 
  Что такое авторизация, аутентификация.
  

Аутентификация — процедура проверки подлинности, например проверка подлинности пользователя путем сравнения введённого им пароля с паролем, сохраненным в базе данных.

Авторизация — предоставление определённому лицу или группе лиц прав на выполнение определенных действий.

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

Прежде чем попасть в контроллер, запрос проходит через цепочку фильтров. UsernamePasswordAuthenticationFilter получает имя и пароль и формирует объект Authentication. Имя хранится в поле principal, а пароль - credenticals (строковое представление), isAuthenticated() устанавливается в false

На следующем этапе AuthenticationManager при помощи единственного метода authenticate() выполняет аутентификацию, сама проверка делегируется конкретным провайдерам (In-Memory, Jdbc, LDAP и др - в зависимости от того, как хранится реальный пользователь).

Если аутентификация не прошла (имя и пароль неверны), то выбрасывается исключение BadCredentials.

В случае же успеха возвращается тоже объект Authentication, но заполненный по-другому: в поле Principal объекта Authentication будет реальный пользователь в виде UserDetails (сюда перемещаются имя и пароль), поле Credentials обнуляется, а isAuthenticated() меняется с false на true.

• 
  Чем отличается In Memory Authentication от basic Authentication?
  

Basic Authentication представляет собой процедуру обмена конфиденциальной информацией (имя пользователя и пароль) для получения доступа к защищенным частям сайта или приложения, а In-Memory Authentication - механизм использования временной базы данных, которая

---

остается в оперативной памяти приложения.

• 
  Как мы можем добавить секьюрность к контроллеру? (минимум 2 способа)
  

Класс настроек:

1. 
   Метод configure
   

Аннотации:

1. 
   @Secured и @RolesAllowed (эквивалентная аннотация JSR-250)
   

н-р:

@Secured({ "ROLE_VIEWER", "ROLE_EDITOR" }) public boolean isValidUsername(String username) { return userRoleRepository.isValidUsername(username); }

@RolesAllowed("ROLE_VIEWER") public String getUsername2() { //... }

2. 
   @PreAuthorize и @PostAuthorize (обеспечивают управление доступом на основе выражений SpEL (Spring Expression Language) до и после выполнения аннотированного метода )
   

@PreAuthorize("hasRole('ROLE_VIEWER')") public String getUsernameInUpperCase() { return getUsername().toUpperCase(); }

@PostAuthorize("#username == authentication.principal.username") public String getMyRoles2(String username) { //... }

3. 
   @PreFilter и @PostFilter (обеспечивают фильтрацию коллекции, переданной в качестве аргумента до и после выполнения аннотированного метода)
   

@PreFilter("filterObject != authentication.principal.username") public String joinUsernames(List usernames) { return usernames.stream().collect(Collectors.joining(";")); }

@PostFilter("filterObject != authentication.principal.username") public List getAllUsernamesExceptCurrent() { return userRoleRepository.getAllUsernames(); }

• 
  Связи таблиц many-to-many one-to-one.
  

Один к одному (@OneToOne)

Данный тип связей встречается не часто. В этом случае объекту одной сущности можно сопоставить только один объект другой сущности. Например, на некоторых сайтах пользователь может иметь только один блог. То есть возникает отношение один пользователь - один блог.

---

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

В этом отношении первичный ключ зависимой таблицы в то же время является внешним ключом, который ссылается на первичный ключ из главной таблицы.

Многие ко многим (@ManyToMany)

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

Другой пример - статьи и теги: для одной статьи можно определить несколько тегов, а один тег может быть определен для нескольких статей.
Но в SQL Server на уровне базы данных мы не можем установить прямую связь многие ко многим между двумя таблицами. Это делается посредством вспомогательной промежуточной таблицы. Иногда данные из этой промежуточной таблицы представляют отдельную сущность.

• 
  Как работают каскады для таблиц и какие они бывают?
  

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

Стандарт JPA подразумевает использование шести видов каскадности:

1. 
   PERSIST — операции сохранения будут происходить каскадно (для методов save() и persist()). То есть, если мы сохраняем сущность, связанную с другими сущностями, они также сохраняются в БД (если их ещё там нет)
   
2. 
   MERGE — операции обновления будут происходить каскадно (для метода merge())
   
3. 
   REMOVE — операции удаления происходят каскадно (метод remove())
   
4. 
   ALL — содержит сразу три каскадные операции — PERSIST - MERGE - REMOVE
   

• 
  Bootstrap.
  

Cвободный набор инструментов (CSS-фреймворк) для создания сайтов и веб-приложений. Включает в себя HTML и CSS-шаблоны оформления для типографики, веб-форм, кнопок, меток, блоков навигации и прочих компонентов веб-интерфейса, включая JavaScript-расширения.

Основные инструменты Bootstrap:

Сетки — заранее заданные размеры колонок, которые можно сразу же использовать, например, ширина колонки 140 px относится к классу .span2 (.col-md-2 в третьей версии фреймворка), который можно использовать в CSS-описании документа.

Шаблоны

---

— фиксированный или резиновый шаблон документа.

Типографика — описания шрифтов, определение некоторых классов для шрифтов, таких как

код, цитаты и т. п.

Медиа — предоставляет некоторое управление изображениями и видео.

Таблицы — средства оформления таблиц, вплоть до добавления функциональности сортировки.

Формы — классы для оформления форм и некоторых событий, происходящих с ними.

Навигация — классы оформления для панелей, вкладок, перехода по страницам, меню и панели инструментов.

Алерты — оформление диалоговых окон, подсказок и всплывающих окон.

• 
  Rest-сервисы. Их преимущества и недостатки.
  

REST — архитектурный стиль построения веб-сервисов, чаще всего используемый для API. По сути, это набор соглашений, позволяющих стандартизировать работу с системой, предоставив единообразный интерфейс.

Пример ресурсного роутинга:

1. 
   GET /articles/ — возвращает все статьи
   
2. 
   GET /articles/new — форма для создания новой статьи
   
3. 
   POST /articles/ — создаёт новую статью
   
4. 
   GET /articles/1 — возвращает статью с идентификатором «1»
   
5. 
   GET /articles/1/edit — форма редактирования статьи
   
6. 
   PATCH или PUT /articles/1 — обновляет статью с идентификатором «1»
   
7. 
   DELETE /articles/1 — удаляет статью с идентификатором «1»
   

Несмотря на распространённость, REST часто критикуют. Происходит это из-за того, что жёстко формализованного стандарта реализации RESTful API не существует.

Часто проблемы возникают на уровне соответствий HTTP-кодов ответа сервера и тела ответа. Не для каждого кейса можно подобрать адекватный код ответа, да и обработка клиентом усложняется при передаче информации не только в теле ответа, но и в статус-коде. Использование кодов, отличных от 200, 404 и 500, обычно усложняет работу с API, особенно из браузеров, так как реализация реакции на одни и те же коды может отличаться (и отличается) в разных браузерах.

REST также сильно привязан к трансферному протоколу HTTP(S) — это усложняет его использование, например, через веб-сокеты.

Критикуют и работу с методами. Методы PATCH и DELETE часто реализуются через POST с передачей флага, обозначающего реальный тип запроса. Это добавляет еще один параметр в и без того насыщенный список.

По сути, в REST мы должны анализировать метод запроса (включая описанный выше параметр переназначения для patch & delete), путь запроса до ресурса, тело запроса, код ответа HTTP, код ответа в теле ответа, тело ответа.

---

Всё это усложняет отладку и сопровождаемость.

А обходят это обычно через повсеместное использование кода ответа 200 ОК, через строгое использование глаголов действий непосредственно в теле запроса, а кодов ответа — в теле ответа. Это «отвязывает» использование API от особенностей транспортного протокола, но при этои превращает REST уже во что-то иное.

• 
  Форматы данных использующиеся в REST-сервисах.
  

Архитектура REST позволяет поставщикам API доставлять данные в различных форматах, таких как: простой текст, HTML, XML, YAML и JSON.

• 
  Чем отличаются REST и SOAP?
  

REST и SOAP на самом деле не сопоставимы. REST — это архитектурный стиль. SOAP — это формат обмена сообщениями.

1. 
   Специфика SOAP — это формат обмена данными. С SOAP это всегда SOAP-XML, который представляет собой XML, включающий:
   

— Envelope (конверт) – корневой элемент, который определяет сообщение и пространство имен, использованное в документе,

— Header (заголовок) – содержит атрибуты сообщения, например: информация о безопасности или о сетевой маршрутизации,

— Body (тело) – содержит сообщение, которым обмениваются приложения,

— Fault – необязательный элемент, который предоставляет информацию об ошибках, которые произошли при обработке сообщений. И запрос, и ответ должны соответствовать структуре SOAP.

2. 
   Специфика REST — использование HTTP в качестве транспортного протокола. Он подразумевает наилучшее использование функций, предоставляемых HTTP — методы запросов, заголовки запросов, ответы, заголовки ответов и т. д.
   

• 
  Что такое responseBody, requestBody, ResponseEntity
  

ResponseEntity представляет собой специальный класс, который представляет http-ответ. Он содержит тело ответа, код состояния, заголовки. Мы можем использовать его для более тонкой настройки http-ответа.

@GetMapping("/hello") ResponseEntity hello() { return new ResponseEntity("Hello World!", HttpStatus.OK); }

HTTP-запрос кроме заголовков и параметров имеет также основную часть - тело запроса. Её содержимое также может быть распознано как параметр в методе контроллера. Для того, чтобы это произошло, необходимо указать @RequestBody в объявлении этого параметра.

Spring автоматически десериализует HttpRequest в тип Java, если указан соответствующий тип.

---

Смотрите также файлы

• Внедрение Интегрированной Информационной Системы Управления Предприятием (исуп) задача.docx

• 1. понятие и сущность адм процесса.docx

• Ориентирование звена гдзс в ндс в условиях нулевой видимости.docx

• Квалификация и уголовное обвинение.docx

• Закон Ома. Соединение проводников. Закон ДжоуляЛенца. Алгебра Преобразование выражений.docx