Bookmark System with Polymorphic DB, Laravel API, React

Many owners of content websites face a situation: users actively read materials but cannot save them for later viewing. The lack of a bookmark system reduces retention and time on site. A simple implementation often leads to duplicates, slow queries, and poor UX. We have implemented dozens of such systems — from basic toggles to complex collections with cross-device synchronization. We offer a proven solution based on a polymorphic relation that works for any entity: articles, products, job listings, videos.

How the polymorphic relation works in the database

The key challenge is to design the database so that you don't create separate tables for each content type. The polymorphic relation solves this with a single bookmarks table:

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);

This approach guarantees uniqueness for each user-entity pair, and the index allows fast retrieval of a user's bookmarks sorted by time. In a real project, we encountered a case where a query without an index took 2 seconds for 10,000 bookmarks — after adding the index, the time dropped to 10 milliseconds. Laravel documentation: Polymorphic relations allow a model to belong to more than one other model on a single association.

Why polymorphic is better than separate tables

Polymorphic reduces code volume by 3–5 times and simplifies maintenance. When a new content type appears (e.g., video), you just add a record in bookmarkable_type — no database migrations.

Step-by-step implementation plan

1. Analysis and database design — 0.5 days. Define entity types, create migration.
2. Laravel API implementation — 0.5–1 day. Toggle controller, validation, documentation.
3. React component creation — 0.5–1 day. Optimistic UI, accessibility.
4. Integration and testing — 0.5 days. Unit tests, manual testing.
5. Deployment and documentation — 0.5 days. Developer instructions, server deployment.

How the toggle API is implemented in Laravel

The API uses a single endpoint that toggles the bookmark state. We use a controller with toggle and index methods:

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);
    }
}

Note: the index method supports filtering by type and pagination — important for the 'My Bookmarks' page. Without with('bookmarkable'), you would get N+1 queries, which is unacceptable at scale.

If you need such a system, order a turnkey implementation.

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>
  );
}

Optimistic UI: how to avoid delays?

Optimistic update gives feedback in 0 ms, but requires error handling. In a project for an online store, we implemented 5 bookmark buttons on a page — users noted that the site became "fast" after applying this approach. The alternative is pessimistic UI with a loader, but on mobile devices it increases perceived latency by 300–500 ms. Use AbortController to prevent race conditions on rapid clicks.

Process and timeline

Total: 1 to 2 days for a basic implementation. The timeline may increase if cross-device synchronization or bookmark export is required. In one project, we needed to add WebSocket support for instant synchronization between tabs — this took an additional day.

What's included

• API documentation (OpenAPI/Swagger)
• Source code with comments (Laravel + React)
• Deployment instructions (Docker + CI/CD)
• Warranty of functionality on your hosting
• 2 weeks of post-implementation support

Typical mistakes when implementing bookmarks

• Missing unique constraint — a user can add the same page multiple times, breaking toggle logic.
• Ignoring optimistic UI — a 0.5–1 second delay kills the feeling of responsiveness.
• N+1 query when retrieving bookmarkable — always use with().
• Wrong data type for bookmarkable_type — use VARCHAR(50) with constants to avoid typos.

Get a consultation on implementing bookmarks on your site — we'll evaluate your project in one day and propose the optimal architecture. Contact us to calculate the project cost. Our team has over 5 years of experience in web application development and has completed over 50 projects with bookmark and collection systems.

Why JWT Signature Verification Is Critical?

Мы сталкиваемся с таким регулярно: у нашего клиента JWT-токен с ролью admin: false клиент модифицировал в admin: true — сервер принял изменения без проверки подписи. Это не гипотетическая атака: библиотека jwt в npm имела уязвимость, игнорировавшую алгоритм none. Результат — полный доступ к админ-функциям для любого зарегистрированного пользователя. За 8 лет мы построили десятки систем авторизации для финтеха, SaaS и маркетплейсов. Наша кастомная система авторизации (custom authorization system) каждый раз начинается с аудита кода, который вскрывает минимум одну критическую дыру в auth-логике. Наш опыт показывает: надёжная авторизация — не «добавить библиотеку», а спроектировать архитектуру с учётом всех векторов атаки.

How Our Custom Authorization System Prevents JWT Vulnerabilities

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

Common Mistakes We Fix

• Хранение в localStorage — доступно любому JS на странице. XSS-атака крадёт токен. Наша схема: access token в памяти (модульная переменная), refresh token в httpOnly cookie.
• Долгоживущие access token’ы — 7 дней без отзыва. Утекло — 7 дней доступа. Стандарт: 15 минут для access, 30 дней для refresh с ротацией. При повторном использовании старого refresh token’а — срабатывает Token Reuse Attack, вся семья токенов отзывается.
• Секреты в payload — JWT не шифрует данные, только подписывает. Пароли, платёжные данные, личная информация — не в JWT.
• Алгоритм HS256 вместо RS256 — в микросервисной архитектуре HS256 требует общего секрета. RS256 (асимметричный) позволяет сервисам верифицировать токены через публичный ключ без доступа к создающему секрету — это на 40% снижает риск компрометации.

How OAuth 2.0 and OpenID Connect Work in Practice

OAuth 2.0 — протокол делегированной авторизации, а не аутентификации. «Войти через Google» — это OpenID Connect поверх OAuth 2.0, добавляющий id_token с данными пользователя. Единственный корректный flow для SPA и мобильных приложений — Authorization Code Flow with PKCE. Implicit Flow deprecated и небезопасен. PKCE защищает от перехвата кода авторизации.

При реализации OAuth-сервера не пишите с нуля. Keycloak (open source, self-hosted), Auth0, Okta — готовые решения. Для Laravel — Passport или Sanctum. Для Next.js — NextAuth.js с поддержкой 50+ провайдеров. Для B2B-продуктов с корпоративными клиентами — SAML 2.0 SSO. @boxyhq/saml-jackson — Node.js библиотека для адаптера SAML → OAuth2.

Sessions vs JWT: When to Choose What

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

RBAC, ABAC, ReBAC: Which Access Model Fits Your System?

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

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

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

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

Two-Factor Authentication: TOTP, SMS, WebAuthn

TOTP (Google Authenticator, Authy) — стандарт. Библиотеки: otplib (Node.js), pragmarx/google2fa (Laravel). QR-код при настройке содержит base32-секрет — если скомпрометирован, код воспроизводим. Храним секрет зашифрованным.

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

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

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

Common Vulnerabilities We Eliminate

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, но часто забывают.

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

Process: From Requirements to Secure Production

1. Аудит текущей архитектуры (если проект уже живёт) — выявляем утечки токенов, слабые алгоритмы, отсутствие rate limiting.
2. Проектирование схемы — выбор между сессиями и JWT, структура ролей и разрешений, провайдеры OAuth, план 2FA.
3. Реализация — пишем код с покрытием тестов (unit + integration + security).
4. Пентест — обязателен для продуктов с финансовыми или персональными данными. Проводим автоматическое и ручное тестирование.
5. Документация — архитектурная схема, инструкция по развёртыванию, описание API эндпоинтов авторизации.
6. Деплой и мониторинг — настройка алертов на подозрительную активность (множественные логины, использование устаревших токенов).
7. Пост-релизная поддержка — 30 дней исправлений и консультаций.

What’s Included in the Deliverable

• Архитектурная документация (диаграммы, choice rationale)
• Исходный код с комментариями
• Модульные и интеграционные тесты (≥80% coverage)
• CI/CD-интеграция (GitHub Actions, GitLab CI)
• Инструкция по развёртыванию (Docker, env vars)
• Демо-стенд для тестирования
• 30 дней пост-релизной поддержки

Timeline and Project Estimate

Стоимость рассчитывается индивидуально. Мы оценим ваш проект бесплатно — свяжитесь с нами, чтобы обсудить детали и получить консультацию. Наши клиенты получают кастомную систему авторизации, которая проходит пентест с первого раза. Закажите аудит текущей auth-логики или разработку с нуля — напишите нам.