Файл: Spring boot, spring security и restSpring security.pdf

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, если
указан
соответствующий тип.
@PostMapping
(
"/request"
)
public
ResponseEntity
postController
(
@RequestBody LoginForm loginForm) {
exampleService.fakeAuthenticate(loginForm);
return
ResponseEntity.ok(HttpStatus.OK);
}
Аннотация
@ResponseBody дает фреймворку понять, что объект, который вернули метода надо прогнать через
HttpMessageConverter, чтобы получить готовое к отправке на клиент представление
. В этот момент
происходит
обратная сериализация сущности в HttpResponse.

@Controller
@RequestMapping
(
"/post"
)
public class
ExamplePostController
{
@Autowired
ExampleService exampleService;
@PostMapping
(
"/response"
)
@ResponseBody
public
ResponseTransfer
postResponseController
(
@RequestBody LoginForm loginForm) {
return new
ResponseTransfer(
"Thanks For
Posting!!!"
);
}
}
Сериализация
/ десериализация RequestBody / ResponseBody, конечно,
не ограничивается
JSON (необходимо прописать пути к классам до
Jackson), оба могут обрабатывать несколько форматов, включая простой текст и
XML, но JSON, вероятно, является наиболее часто используемым форматом
● Что
такое AJAX/fetch?
Для сетевых запросов из
JavaScript есть широко известный термин
«AJAX» (аббревиатура от Asynchronous JavaScript And XML). Данная
технология предоставляет возможность отправлять сетевые
запросы на сервер и подгружать новую информацию по мере
необходимости
.
Есть несколько способов делать сетевые запросы и получать информацию с сервера.
Метод fetch() — современный и очень мощный, XMLHttpRequest нового
поколения
. Он не поддерживается старыми (можно использовать полифил
), но поддерживается всеми современными браузерами.
Базовый синтаксис:
let
promise = fetch(url, [options])
/*url - URL для отправки запроса.
options - дополнительные параметры: метод, заголовки и так далее*/

● Чем
аннотация RestController отличается от Controller
@RestController – это просто сокращенная запись для @Controller +
@ResponseBody.
●
RestTemplate и его методы
RestTemplate это специальный клиент для отправки запросов в Spring.
Он предоставляет удобные
API для легкого вызова конечных точек
REST’а в одну строку.
RestTemplate restTemplate =
new
RestTemplate();
String fooResourceUrl =
"http://localhost:8080/spring-rest/foos"
;
ResponseEntity response =
restTemplate.getForEntity(fooResourceUrl +
"/1"
,
String.class);
Основные методы:
getForEntity - выполняет запрос
GET и возвращает объект
ResponseEntity;
getForObject - аналогично getForEntity, но возвращает ресурс напрямую;
exchange - выполняет указанный метод HTTP, такой как GET, POST, PUT и т
. д., и возвращает объект ResponseEntity;
execute - аналогичен exchange методу, но требует дополнительных параметров
: RequestCallback и ResultSetExtractor;
headForHeaders - выполняет запрос HEAD и возвращает все заголовки;
optionsForAllow - выполняет запрос OPTIONS и использует заголовок
Allow;
delete - удаляет ресурсы по указанному URL-адресу с помощью метода
HTTP DELETE;
put - обновляет ресурс для заданного URL-адреса с помощью метода
HTTP PUT;
postForObject - создает новый запрос с использованием метода HTTP
POST и возвращает сущность;
postForLocation - создает новый запрос с использованием метода HTTP
POST и возвращает его расположение;
HTTP
● Что
такое HTTP, основные его методы?

HTTP (англ. - Hyper Text Transfer Protocol) — широко распространённый протокол передачи данных
, изначально предназначенный для передачи гипертекстовых документов
(то есть документов, которые могут содержать ссылки
, позволяющие организовать переход к другим документам
).
Протокол
HTTP
предполагает использование клиент
-серверной структуры передачи данных
. Клиентское приложение формирует запрос и отправляет его на сервер
, после чего серверное программное обеспечение обрабатывает данный запрос
, формирует ответ и передаёт его обратно клиенту
. После этого клиентское приложение может продолжить отправлять другие запросы
, которые будут обработаны аналогичным образом.
Задача
, которая традиционно решается с помощью протокола HTTP —
обмен данными между пользовательским приложением
,
осуществляющим доступ к веб
-ресурсам (обычно это веб-браузер) и веб
-сервером. На данный момент именно благодаря протоколу HTTP
обеспечивается работа Всемирной паутины.
GET
Метод
GET
запрашивает представление ресурса
Запросы с
использованием этого метода могут только извлекать данные.
HEAD
Запрашивает ресурс так же, как и метод GET, но без тела ответа.
POST
Используется для отправки сущностей к определённому ресурсу
. Часто вызывает изменение состояния или какие
-то побочные эффекты на сервере
PUT
Заменяет все текущие представления ресурса данными запроса.
DELETE
Удаляет указанный ресурс.
● Идемпотентность
HTTP-методов
Метод считается
«идемпотентным», если эффект на сервер от одного
запроса такой же как от нескольких идентичных запросов такого
типа
. PUT, DELETE и безопасные методы (только на чтение — не изменяют состояние сервера) запросы являются идемпотентными.