Реализация системы закладок: polymorphic БД, Laravel API, React

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

Разработка и обслуживание любых видов сайтов:

Информационные сайты или веб-приложения
Сайты визитки, landing page, корпоративные сайты, онлайн каталоги, квиз, промо-сайты, блоги, новостные ресурсы, информационные порталы, форумы, агрегаторы
Сайты или веб-приложения электронной коммерции
Интернет-магазины, B2B-порталы, маркетплейсы, онлайн-обменники, кэшбэк-сайты, биржи, дропшиппинг-платформы, парсеры товаров
Веб-приложения для управления бизнес-процессами
CRM-системы, ERP-системы, корпоративные порталы, системы управления производством, парсеры информации
Сайты или веб-приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, конструкторы сайтов, порталы предоставления электронных услуг, видеохостинги, тематические порталы

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

Услуги, которые мы предлагаем
Показано 1 из 1Все 2062 услуг
Реализация системы закладок: polymorphic БД, Laravel API, React
Простой
~2-3 дня
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1362
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1253
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    958
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1190
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    931
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    949

Многие владельцы контентных сайтов сталкиваются с ситуацией: пользователи активно читают материалы, но не могут их сохранить для последующего просмотра. Отсутствие системы закладок снижает возвращаемость и время на сайте. При этом простая реализация часто приводит к дубликатам, медленным запросам и неудобному UX. Мы внедрили десятки таких систем — от базового toggle до сложных коллекций с синхронизацией между устройствами. Предлагаем проверенное решение на основе polymorphic связи, которое подходит для любых сущностей: статей, продуктов, вакансий, видео.

Как работает polymorphic связь в базе данных?

Ключевая задача — спроектировать базу данных так, чтобы не плодить отдельные таблицы под каждый тип контента. Polymorphic связь решает это одной универсальной таблицей bookmarks:

CREATE TABLE bookmarks (
    id            SERIAL PRIMARY KEY,
    user_id       INTEGER  NOT NULL REFERENCES users(id) ON DELETE CASCADE,
    bookmarkable_id   INTEGER  NOT NULL,
    bookmarkable_type VARCHAR(50) NOT NULL,
    created_at    TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    UNIQUE (user_id, bookmarkable_id, bookmarkable_type)
);

CREATE INDEX ON bookmarks(user_id, bookmarkable_type, created_at DESC);

Такой подход гарантирует уникальность закладки для каждого пользователя и сущности, а индекс позволяет быстро получать закладки пользователя с сортировкой по времени. В реальном проекте мы столкнулись с кейсом, когда без индекса запрос на 10000 закладок выполнялся 2 секунды — после добавления индекса время упало до 10 миллисекунд. Laravel документация: Polymorphic relations allow a model to belong to more than one other model on a single association.

Почему polymorphic связь лучше отдельных таблиц?

Критерий Polymorphic Отдельные таблицы
Количество таблиц 1 N (по числу типов)
Сложность запросов Один контроллер N контроллеров
Расширяемость Добавить тип — одна строка Новая таблица + код
Производительность Один индекс N индексов

Polymorphic подход сокращает объём кода в 3–5 раз и упрощает поддержку. При появлении нового типа контента (например, видео) достаточно добавить запись в bookmarkable_type — без миграций БД.

Пошаговый план внедрения

  1. Анализ и проектирование БД — 0.5 дня. Определяем типы сущностей, создаём миграцию.
  2. Реализация Laravel API — 0.5–1 день. Контроллер toggle, валидация, документация.
  3. Создание React компонента — 0.5–1 день. Оптимистичный UI, доступность.
  4. Интеграция и тестирование — 0.5 дня. Юнит-тесты, ручное тестирование.
  5. Деплой и документация — 0.5 дня. Инструкция для разработчика, деплой на сервер.

Как реализован toggle API на Laravel?

API построен на одном эндпоинте, который переключает состояние закладки. Используем контроллер с методами toggle и index:

class BookmarkController extends Controller
{
    public function toggle(Request $request, string $type, int $id): JsonResponse
    {
        $existing = Bookmark::where([
            'user_id'             => auth()->id(),
            'bookmarkable_type'   => $type,
            'bookmarkable_id'     => $id,
        ])->first();

        if ($existing) {
            $existing->delete();
            return response()->json(['bookmarked' => false]);
        }

        Bookmark::create([
            'user_id'           => auth()->id(),
            'bookmarkable_type' => $type,
            'bookmarkable_id'   => $id,
        ]);

        return response()->json(['bookmarked' => true], 201);
    }

    public function index(Request $request): JsonResponse
    {
        $bookmarks = Bookmark::where('user_id', auth()->id())
            ->when($request->type, fn($q) => $q->where('bookmarkable_type', $request->type))
            ->with('bookmarkable')
            ->latest()
            ->paginate(20);

        return response()->json($bookmarks);
    }
}

Обратите внимание: метод index поддерживает фильтрацию по типу и пагинацию — это важно для страницы «Мои закладки». Без with('bookmarkable') вы получите N+1 запросов, что неприемлемо при высокой нагрузке.

Если вам нужна такая система — закажите реализацию под ключ.

Пример React компонента с оптимистичным UI
function BookmarkButton({ type, id, initialBookmarked }: BookmarkProps) {
  const [bookmarked, setBookmarked] = useState(initialBookmarked);

  const toggle = async () => {
    setBookmarked(!bookmarked);
    try {
      await api.post(`/api/bookmarks/${type}/${id}/toggle`);
    } catch {
      setBookmarked(bookmarked);
    }
  };

  return (
    <button
      onClick={toggle}
      aria-label={bookmarked ? 'Удалить из закладок' : 'Добавить в закладки'}
      aria-pressed={bookmarked}
      className={`bookmark-btn ${bookmarked ? 'bookmark-btn--active' : ''}`}
    >
      {bookmarked ? '🔖' : '🏷️'}
    </button>
  );
}

Оптимистичный UI: как избежать задержек?

Оптимистичный update даёт отклик за 0 мс, но требует обработки ошибок. В проекте для интернет-магазина мы реализовали 5 кнопок закладок на странице — пользователи отмечали, что сайт стал «летать» после внедрения такого подхода. Альтернатива — пессимистичный UI с loader, но на мобильных устройствах он увеличивает perceived latency на 300–500 мс. Используйте AbortController для предотвращения гонки запросов при быстрых кликах.

Процесс работы и сроки

Этап Длительность
Анализ и проектирование БД 0.5 дня
Разработка API (Laravel) 0.5–1 день
React-компонент и интеграция 0.5–1 день
Страница «Мои закладки» с фильтрацией 0.5 дня
Тестирование и деплой 0.5 дня

Итого: от 1 до 2 дней на базовую реализацию. Срок может увеличиться при необходимости синхронизации между устройствами или экспорта закладок. В одном из проектов потребовалось добавить поддержку WebSocket для мгновенной синхронизации между вкладками — это заняло дополнительный день.

Что входит в работу

  • Документация API (OpenAPI/Swagger)
  • Исходный код с комментариями (Laravel + React)
  • Инструкция по развёртыванию (Docker + CI/CD)
  • Гарантия работоспособности на выбранном хостинге
  • 2 недели поддержки после внедрения

Типичные ошибки при реализации закладок

  • Отсутствие уникального ограничения — пользователь может добавить одну страницу несколько раз, что ломает логику toggle.
  • Игнорирование оптимистичного UI — задержка 0.5–1 секунды убивает ощущение отклика.
  • N+1 запрос при получении bookmarkable — обязательно используйте with().
  • Неправильный выбор типа поля bookmarkable_type — используйте VARCHAR(50) с константами, чтобы избежать опечаток.

Получите консультацию по внедрению закладок на ваш сайт — оценим ваш проект за один день и предложим оптимальную архитектуру. Свяжитесь с нами для расчёта стоимости проекта. Наша команда имеет более 5 лет опыта в разработке веб-приложений и выполнила свыше 50 проектов с системами закладок и коллекций.

Аутентификация и авторизация: OAuth, JWT, сессии, RBAC, 2FA

На одном проекте токен JWT с ролью admin: false мог быть изменён клиентом на admin: true — сервер принимал его без верификации подписи. Это не гипотетическая атака: несколько файлов в npm-экосистеме имели уязвимость jwt библиотеки, которая игнорировала алгоритм none. Последствия — полный доступ к административным функциям для любого зарегистрированного пользователя.

JWT: что реально нужно знать

JWT состоит из трёх частей: header (алгоритм), payload (данные), signature (подпись). Подпись верифицирует, что payload не изменён. Без проверки подписи — это просто base64-encoded JSON, который любой может подделать.

Ошибки, которые видим в коде регулярно:

Хранение в localStorage. localStorage доступен любому JS на странице — XSS атака читает токен и отправляет на сервер злоумышленника. Access token в памяти (переменная модуля), refresh token в httpOnly cookie — правильная схема.

Долгоживущие access-токены. Access token на 7 дней без возможности отзыва. Утёк — 7 дней доступа. Стандарт: 15 минут для access token, 30 дней для refresh token с ротацией. При каждом использовании refresh token выдаётся новый, старый инвалидируется — если старый кто-то использует повторно, это детектируется как Token Reuse Attack, вся семья токенов отзывается.

Хранение секретных данных в payload. JWT payload не зашифрован, только подписан — его видно в base64. Пароли, платёжные данные, личная информация — не в JWT.

Алгоритм RS256 (асимметричный) предпочтительнее HS256 (симметричный) в микросервисной архитектуре: сервисы могут верифицировать токен публичным ключом, не имея доступа к секрету для его создания.

OAuth 2.0 и OpenID Connect

OAuth 2.0 — протокол делегированной авторизации, не аутентификации. «Войти через Google» — это OpenID Connect поверх OAuth 2.0, который добавляет id_token с данными пользователя.

Authorization Code Flow с PKCE — единственный правильный flow для браузерных SPA и мобильных приложений. Implicit Flow устарел и небезопасен. PKCE (Proof Key for Code Exchange) защищает от перехвата authorization code.

Реализация OAuth сервера: не пишем с нуля. Keycloak (open source, self-hosted), Auth0, Okta — готовые решения. Laravel Passport или Laravel Sanctum для серверных приложений. NextAuth.js для Next.js — поддерживает 50+ провайдеров из коробки.

Для B2B продуктов с корпоративными клиентами — SAML 2.0 SSO. Корпоративные IT-отделы часто требуют его вместо OAuth. @boxyhq/saml-jackson — node.js библиотека для SAML → OAuth2 адаптера.

Сессии vs токены

Сессии хранят состояние на сервере (Redis, database) — сервер может мгновенно отозвать сессию. При масштабировании на несколько инстансов нужен общий store (Redis Cluster). Cookie с session ID — httpOnly, Secure, SameSite=Strict.

Stateless JWT не требуют server-side storage, масштабируются горизонтально. Но отзыв токена до истечения срока — только через blacklist (Redis), что частично убирает преимущество stateless.

Для большинства веб-приложений сессии проще и безопаснее. JWT имеет смысл для API, потребляемых из мобильного приложения, и для микросервисной архитектуры.

RBAC и политики доступа

Role-Based Access Control — у пользователя есть роли, у ролей — права. Простая реализация: user → roles → permissions. Но как только появляется ресурсная авторизация («пользователь может редактировать только свои посты»), RBAC усложняется.

Spatie Laravel Permission — стандарт для Laravel: полиморфные роли и права, кэширование, super-admin через gate. Интеграция с Eloquent: $user->can('edit posts'), $user->hasRole('editor').

ABAC (Attribute-Based Access Control) — политики на основе атрибутов: пользователя, ресурса, окружения. Нужен когда правила доступа сложные: «менеджер может просматривать заказы своего региона, если заказ создан более 24 часов назад». Casbin — популярная cross-language библиотека для ABAC.

ReBAC (Relationship-Based Access Control) — Google Zanzibar model. Доступ определяется графом отношений: «пользователь X является участником команды Y, которая имеет доступ к проекту Z». OpenFGA — open source реализация от Okta.

Двухфакторная аутентификация

TOTP (Time-based One-Time Password, Google Authenticator, Authy) — стандарт. Библиотеки: otplib (Node.js), pragmarx/google2fa (Laravel). QR-код при подключении — base32-encoded secret, которого достаточно для воспроизведения кода при компрометации. Хранить secret в зашифрованном виде.

SMS-верификация — слабее TOTP из-за SIM-swapping атак и ненадёжности доставки SMS. Но пользователи активируют её охотнее. Email OTP — компромисс между безопасностью и UX.

WebAuthn (Passkeys) — биометрия или аппаратный ключ вместо пароля. Хранится private key на устройстве, публичный — на сервере. Нет пароля — нет его утечки. iOS 16+, Android 9+, все современные браузеры поддерживают. @simplewebauthn/server + @simplewebauthn/browser — хорошая библиотека для Node.js реализации.

Backup-коды при подключении 2FA: 10 одноразовых кодов для восстановления доступа если телефон потерян. Хранить хешированными (bcrypt), показывать только один раз при генерации.

Типичные уязвимости

Broken Object Level Authorization (BOLA/IDOR): /api/orders/12345 возвращает заказ без проверки, принадлежит ли он текущему пользователю. Самая распространённая уязвимость API по OWASP. Каждый запрос к ресурсу — проверка через $user->can('view', $order).

Mass Assignment: User::create($request->all()) — пользователь передаёт is_admin: true в теле запроса. Laravel решает через $fillable / $guarded, но часто забывают.

Небезопасный CORS: Access-Control-Allow-Origin: * на API с авторизацией по cookie — credentials не передаются с wildcard origin, но если кто-то сделал Allow-Credentials: true + Allow-Origin: * — это дыра.

Процесс работы

Архитектура авторизации проектируется до начала разработки, не добавляется потом. Выбор между сессиями и JWT, структура ролей и прав, flow для OAuth-провайдеров, план для 2FA. Penetration testing обязателен для продуктов с финансовыми данными или персональными данными пользователей.

Сроки

Базовая аутентификация (email/password + OAuth + JWT/сессии): 1–3 недели. RBAC с детальными политиками доступа: 2–4 недели. 2FA (TOTP + SMS): 1–2 недели. WebAuthn/Passkeys: 2–3 недели. Полная система аутентификации для SaaS с multi-tenancy: 4–8 недель.