- Repository
- Unit of Work - отвечает за отслеживание изменений объектов сущностей и сохранение их в базе данных при выполнении операции "commit"
- Identity Map - идентичность сущности гарантия, что одна и та же сущность всегда представлена одним и тем же объектом.
- Lazy Loading - отложенную загрузку связанных сущностей
- Query Object - позволяет строить сложные SQL-запросы
- Value Objects, Embeddables, Associations
Контекст и язык:
- Bounded Context: Order (заказ)
- Ubiquitous Language: Заказ, Товар, Количество, Цена, Статус заказа и т.д.
Сущности:
- Заказ (Order): Представляет заказ, который содержит информацию о покупаемых товарах, их количестве, общей цене и статусе заказа.
- Товар (Product): Представляет товар, имеющий уникальный идентификатор, название, описание, цену и другие атрибуты.
Значимые объекты (Value Objects):
- Количество (Quantity): Представляет количество товара, которое может быть положительным целым числом.
- Цена (Price): Представляет цену товара, которая может быть положительным числом с десятичной частью.
Агрегат:
- Заказ (Order): Является агрегатом, который объединяет сущности и значимые объекты вместе. Он управляет состоянием заказа и обеспечивает инварианты, такие как правильность расчета общей цены, обновление статуса заказа и другие бизнес-правила.
Репозиторий:
- Репозиторий (OrderRepository): Отвечает за поиск и сохранение заказов. Позволяет получать информацию о заказе, добавлять новые заказы в хранилище и обновлять существующие заказы.
Сервисы:
- Сервис создания заказа (OrderCreationService): Отвечает за создание нового заказа, включая проверку наличия товаров, расчет общей цены, установку начального статуса заказа и сохранение в репозитории.
Фабрики:
- Фабрика заказа (OrderFactory): Предоставляет удобный способ создания экземпляров заказа с правильными значениями и настройками.
Значения перечислений:
- Статус заказа (OrderStatus): Представляет возможные статусы заказа, такие как "новый", "в обработке", "выполнен" и т.д.
События:
- События заказа (OrderEvents): Определяет различные события, связанные с заказом, такие как "создан", "обновлен", "отменен" и т.д. Эти события могут быть использованы для обновления других компонентов системы или для обеспечения синхронизации с другими
- Используем метод HTTP PATCH
- Определите конечную точку (endpoint) /orders/{order_id}
- Передавайте данные в формате JSON
- Проверьте и валидируйте данные
- Измените данные в хранилище
- Верните подтверждение обновления
- Логин/пароль
Это наиболее распространенный метод аутентификации, при котором пользователь вводит свой логин и пароль для доступа к приложению. Данные проверяются на соответствие хранящимся в системе, и в случае успеха пользователю предоставляется доступ.
- Токены аутентификации
Вместо передачи логина и пароля при каждом запросе, используются аутентификационные токены, такие, как JSON Web Tokens (JWT) или OAuth-токены. При успешной аутентификации сервер выдает токен, который клиент передает с каждым последующим запросом для подтверждения своей личности.
- Одноразовые пароли OTP (one time password)
Этот метод предоставляет временные пароли, которые действительны только для одного входа. Они могут быть отправлены по электронной почте или SMS и обычно используются для дополнительного слоя безопасности при аутентификации.
- Biometric-аутентификация
Этот метод использует биометрические данные, такие как отпечатки пальцев, сканер лица или сканер сетчатки глаза, для аутентификации пользователя. Это особенно популярно на мобильных устройствах.
- Авторизация на основе ролей
После успешной аутентификации пользователь получает роль или роли, которые определяют его права доступа в системе. Авторизация на основе ролей определяет, какие действия пользователь может выполнять в приложении.
- Двухфакторная аутентификация
Этот метод требует от пользователя предоставить два разных типа аутентификационных данных для подтверждения личности, например, пароль и одноразовый код, полученный по SMS.
- Социальная аутентификация
Вместо создания отдельного аккаунта в приложении, пользователь может использовать учетные данные социальной сети, такие как Facebook, Google или Twitter, для аутентификации.
Один из основных минусов паттерна ActiveRecord заключается в том, что он смешивает ответственности модели данных (объекта) и работы с базой данных. Вместо того чтобы разделить эти ответственности на отдельные компоненты
- Нарушение принципа единственной ответственности (Single Responsibility Principle)
- Большая связанность (High Coupling)
- Ограниченность возможностей
- Затруднение тестирования
- Смешивание логики
- Зависимость от ORM
- Идентификация. Сверка идентичности отвечающий на вопрос «Кто ты?». В качестве ответа пользователь предоставляет свой логин, email и т.п.
- Аутентификация. Подтверждение, что он тот, за кого себя выдает. Для этого он вводит пароль, доказывая регистрацию в системе.
- Авторизация. Проверка прав доступа пользователя к ресурсу.
JWT (JSON Web Token) - это открытый стандарт (RFC 7519), который определяет формат для передачи безопасной информации между сторонами в виде JSON объектов. JWT токен используется для аутентификации и авторизации в веб-приложениях и API.
JWT токен состоит из трех частей, разделенных точкой:
- Header (Заголовок)
Содержит информацию о типе токена (обычно это "JWT") и алгоритме шифрования, используемом для подписи токена.
- Payload (Тело)
Содержит утверждения (claims) - данные, которые хранят информацию о пользователе или другие метаданные. Утверждения могут быть стандартными (например, идентификатор пользователя, роль) или настраиваемыми (дополнительные данные, необходимые для приложения).
- Signature (Подпись)
Используется для проверки целостности токена и подтверждения его подлинности. Подпись создается на основе заголовка, тела и секретного ключа, известного только серверу, который будет проверять токены.
JWT токены имеют несколько преимуществ:
Переносимость, cамодостаточность, расширяемость
Однако, важно обеспечить безопасность JWT токенов, так как они могут быть декодированы и прочитаны клиентами. Поэтому необходимо применять соответствующие меры безопасности, такие как использование HTTPS для защищенной передачи токенов и надежное хранение секретного ключа на сервере.
Существую два вида токенов access и refresh: Как правило, access-токен — это некий короткоживущий токен, который много раз используется приложением для обращения к серверу. Когда срок жизни токена истекает, можно обратиться к серверу для продления срока. Для этого и понадобится refresh-токен. Он одноразовый, но имеет более долгий срок жизни и позволяет получить новую пару токенов.
Проблемы:
Невозможно провести полноценный логаут. Во фронтенд-приложении после нажатия кнопки выхода пользователь уверен, что он вылогинился из системы. Но выданные ему токены проживут еще некоторое время! По этой же причине невозможно вылогинить юзера в случае утери или кражи токена.
А еще есть проблемы при краже секретной строки. Да, это происходит не часто, потому что этот ключ лежит на сервере. Но если строка украдена, то все токены будут скомпрометированными.
https://highload.today/blogs/jwt-avtorizatsiya/
Он одноразовый, но имеет более долгий срок жизни и позволяет получить новую пару токенов. Если его перехватить, то можно скомпрометировать систему. И получить доступ на время жизни refresh token.
- Обеспечение безопасности соединения. Протокол HTTPS позволяет, например, предотвратить атаки когда в заголовке передаются токены.
- Хранение ключа в защищенном месте на сервере.
- Не хранить токены в БД. В БД можно хранить идентификатор, который содержится в токене.
- Работа с парой токенов. Короткоживущий access- и долгоживущий refresh-токены.
- Не хранить токены в local storage или session storage браузера. Такой способ хранения чувствителен к XSS-атакам.
- Всегда валидировать данные пользователя.
- Ограничивать источники подгружаемых ресурсов. Для этого понадобится заголовок Content-Security-Policy.
- Флаг HttpOnly для cookie и ограничение Same Site для cookie
- CSRF-токены. Хороший механизм защиты от CSRF-атак — использование CSRF-токенов — специальных токенов, которые сервер присылает клиенту в cookie, при этом каждый запрос клиента к серверу должен сопровождаться cookie с этим токеном и/или HTTP-заголовком X-CSRF-Token, содержащим этот токен.
Попробовать зашифровать head, body и сравнить сигнатуру на сервере используя секретный ключ
OpenId,JWT - аутентификация OAuth2 - авторизация
Компонент Symfony Event Dispatcher отвечает за управление и распространение событий (events) внутри приложения. Он предоставляет механизм для создания, регистрации, диспетчеризации и обработки событий, позволяя различным частям приложения взаимодействовать друг с другом.
OAuth (Open Authorization) - это протокол аутентификации и авторизации, который позволяет одному веб-сайту или приложению запросить доступ к ресурсам пользователя на другом сайте или приложении, без необходимости предоставлять свои учетные данные.
Шаги работы:
- Регистрация приложения
Пользователь регистрирует свое приложение на сервере, предоставляющем доступ к ресурсам получая Client ID и секретный ключ Secret Token
- Авторизация
Пользователь, желающий предоставить доступ к своим ресурсам, аутентифицируется на стороне предоставления ресурсов.
- Выдача кода авторизации
После успешной аутентификации, сторона предоставления ресурсов перенаправляет пользователя обратно на сайт или приложение, запрашивающее доступ, и передает временный код авторизации (Authorization Code).
- Обмен кода на токен доступа
Сайт или приложение, запрашивающее доступ, отправляет полученный код авторизации на сервер предоставления ресурсов, вместе с идентификатором клиента и секретным ключом. В ответ сервер предоставления ресурсов выдает токен доступа (Access Token) и, возможно, обновляемый токен обновления (Refresh Token).
- Доступ к ресурсам
С токеном доступа приложение может делать API-запросы к серверу предоставления ресурсов, запрашивая доступ к различным ресурсам пользователя. Токен предоставляет приложению доступ к ресурсам в соответствии с разрешениями, предоставленными пользователем.
- Обновление токена (необязательно)
Токен доступа может иметь ограниченное время жизни. Если необходимо продолжить доступ к ресурсам после истечения срока действия токена, приложение может использовать токен обновления для получения нового токена доступа без необходимости повторной аутентификации пользователя.
- Широкий спектр инструментов и функций для разработки веб-приложений.
- Компонентный подход
- Структурированная архитектура - лучшие практики разработки и применение архитектурных шаблонов
- Гибкость и настраиваемость
- Обширная документация и сообщество
- Поддержка стандартов и лучших практик
- Использование исключений (Exceptions)
- Логирование ошибок
- Обработка и возврат ошибок API - обрабатывать ошибки и возвращаете соответствующие HTTP статусы и сообщения об ошибках.
- Мониторинг ошибок
- Уведомления
Теги - это метаданные которые можно добавлять к сервисам и другим компонентам. Предоставляют механизм гибкой конфигурации и расширения в Symfony, позволяя влиять на поведение приложения, не изменяя сам код фреймворка.
- Автопривязывание сервисов (Service Auto Wiring) Использование тегов для автоматической регистрации сервисов в основном приложении.
- События (Event Dispatching) Определения какие слушатели событий должны быть автоматически зарегистрированы и подключены к системе событий.
- Консольные команды (Console Commands) Это позволяет создавать расширения консольных команд и автоматически добавлять их в консольное приложение Symfony.
- Кэширование (Caching) Вы можете добавлять теги к кэшируемым элементам, а затем сбрасывать кэш для всех элементов с определенным тегом при необходимости.
- Конфигурация и настройка Вы можете использовать теги для добавления дополнительной конфигурации или настройки к определенным сервисам. Это позволяет вам создавать более гибкие и настраиваемые компоненты.
Используется для обработки сообщений для работы с командами и событиями.
Message (Сообщение):
- Объект, который содержит данные, необходимые для выполнения определенного действия в системе.
Envelope (Конверт):
- "Обертка" (Envelope) представляет собой структуру данных, объединяющую сообщение и дополнительные метаданные о сообщении, содержит и информацию о том, как обрабатывать это сообщение,
Middleware:
- Обработчики envelope
Используется блокирующий вызов очереди, из-за этого медленная работа.
public: Определяет, будет ли сервис доступен извне контейнера зависимостей
autowire: Указывает, должна ли автоматическая внедрение зависимостей (autowiring) быть включена для данного сервиса.
autoconfigure: Используется для автоматической настройки сервисов, которые реализуют интерфейсы или наследуют от классов, предоставляя им некоторый общий функционал.
Аннотации в Symfony - это способ добавления метаданных и конфигурации к классам и их методам с использованием специальных аннотаций в комментариях. Они позволяют определить различные аспекты приложения, такие как маршруты, доступ к базе данных, аутентификацию, кеширование и многое другое, без необходимости создавать сложные XML-файлы или конфигурационные файлы.
- Конфигурация: Маршрутизация с использованием @Route, контроль доступа с использованием @Security, авторизация с использованием @IsGranted
- Документация и метаданные: @ApiResource
- Валидация: Вы можете создать собственные аннотации для задания правил валидации данных в формах или других местах.
- Расширение фреймворка: Например, аннотация @Entity из Doctrine используется для указания, что класс является сущностью базы данных.
- Логирование и отладка: Аннотации могут использоваться для указания информации, связанной с логированием и отладкой. Например, аннотация @Loggable может указывать, что метод или класс должен быть отслеживаемым и логироваться.
- Собственные метаданные: Эти метаданные могут использоваться для различных целей, включая автоматическую генерацию кода или настройку. Описания своего типа данных, подключения других сущностей.
PSR-0, PSR-4 namespace.
PSR-7 Http interface не используется в Symfony PSR-6 — стандарт интерфейсов кеширования. PSR-11 — стандарт контейнера интерфейсов.
Преобразование из строки в массив или объект и наоборот
24. Как в symfony можно написать чтоб любые последовательные flush были сохраненены в одной транзакции
Обернуть в start и commit transaction + rollback
25. Как гарантировать отправку event в очередь если заказ сохранился, но потом произошёл die в скрипте?
Сохранить этот event в БД и обработать его позже через cron
- Сложность обучения
- Требовательность к ресурсам
- Сложность конфигурации
- Зависимость от компонентов (Обновление компонентов или разрешение конфликтов зависимостей может потребовать)
- Обилие стандартов и соглашений
- Медленная скорость разработки для маленьких проектов