Какие плюсы и минусы хранения состояния на серверной части?

Плюсы и минусы хранения состояния на серверной части

Хранение состояния на сервере (server-side state) — когда информация о пользователе, сессии, взаимодействии сохраняется на стороне сервера. Это противопоставляется хранению на клиенте (JWT токены, localStorage) и бессерверной архитектуре (stateless).

Основные плюсы

1. Безопасность и контроль

Состояние хранится на надежном сервере, недоступном клиенту. Нельзя подделать или манипулировать данными с клиента.

// Server-side: сессия содержит данные пользователя
@RestController
public class AuthController {
    @PostMapping("/login")
    public ResponseEntity<?> login(@RequestBody LoginRequest request, HttpSession session) {
        User user = authenticate(request.getUsername(), request.getPassword());
        if (user != null) {
            session.setAttribute("user", user);
            session.setAttribute("loginTime", LocalDateTime.now());
            return ResponseEntity.ok("Login successful");
        }
        return ResponseEntity.status(401).body("Invalid credentials");
    }
    
    @GetMapping("/profile")
    public ResponseEntity<User> getProfile(HttpSession session) {
        User user = (User) session.getAttribute("user");
        if (user == null) {
            return ResponseEntity.status(401).build();
        }
        return ResponseEntity.ok(user);
    }
}

// Клиент НЕ может изменить данные пользователя
// (sessionId зашифрован в JSESSIONID cookie)

2. Немедленный контроль доступа

Можно мгновенно отозвать доступ, заблокировав сессию на сервере.

@RestController
public class AdminController {
    @PostMapping("/logout")
    public ResponseEntity<?> logout(HttpSession session) {
        session.invalidate(); // мгновенное удаление сессии
        return ResponseEntity.ok("Logged out");
    }
    
    @PostMapping("/admin/block-user/{userId}")
    public ResponseEntity<?> blockUser(@PathVariable Long userId) {
        // Все сессии пользователя становятся невалидными
        sessionManager.invalidateAllSessions(userId);
        return ResponseEntity.ok("User blocked");
    }
}

// Контраст с JWT: токен действует до истечения срока
// даже если пользователя заблокировали

3. Непрозрачность для клиента

Клиент не знает, какие данные хранит сервер. Это позволяет менять логику на сервере без изменения клиента.

// Сервер хранит: пользователя, время входа, IP адрес, браузер
// Клиент только знает, что авторизован (через cookie)
Session session = new Session();
session.setUserId(user.getId());
session.setLoginTime(LocalDateTime.now());
session.setIpAddress(getClientIp());
session.setUserAgent(request.getHeader("User-Agent"));
sessionRepository.save(session);

// Завтра добавим проверку на попытки перехвата:
if (!session.getIpAddress().equals(currentIp) || !session.getUserAgent().equals(currentAgent)) {
    session.invalidate(); // подозрительная активность
}
// Клиент об этом не знает, просто переавторизуется

4. Сложные проверки в реальном времени

Можно проверять сложные условия при каждом запросе: роли, разрешения, состояние учёта.

@RestController
public class OrderController {
    @PostMapping("/orders")
    public ResponseEntity<?> createOrder(@RequestBody OrderRequest request, HttpSession session) {
        User user = (User) session.getAttribute("user");
        
        // Сложные проверки на сервере
        if (!user.isVerified()) {
            return ResponseEntity.status(403).body("Email not verified");
        }
        if (user.getBalance() < request.getTotalPrice()) {
            return ResponseEntity.status(402).body("Insufficient funds");
        }
        if (user.hasActiveOrder()) {
            return ResponseEntity.status(409).body("Already processing order");
        }
        
        Order order = orderService.create(user, request);
        return ResponseEntity.ok(order);
    }
}

5. Обновление состояния без переавторизации

Можно менять разрешения пользователя, и он сразу получит доступ к новым функциям.

@RestController
public class AdminController {
    @PostMapping("/admin/grant-role/{userId}")
    public ResponseEntity<?> grantRole(@PathVariable Long userId, 
                                       @RequestParam String role) {
        User user = userRepository.findById(userId);
        user.addRole(role);
        userRepository.save(user);
        
        // Сессия обновится при следующем запросе
        // Если кэширована, нужна инвалидация
        sessionManager.updateSession(userId);
        return ResponseEntity.ok("Role granted");
    }
}

Основные минусы

1. Масштабируемость и память на сервере

Каждая сессия занимает память. С миллионами пользователей может быть проблема.

// Типичная сессия: 1-5 KB
// 1 миллион активных сессий = 1-5 GB памяти
// 100 миллионов активных сессий = 100-500 GB памяти

// Решение: Redis
@Configuration
public class SessionConfig {
    @Bean
    public LettuceConnectionFactory connectionFactory() {
        return new LettuceConnectionFactory();
    }
}

// Но даже Redis имеет лимиты

2. Сложность масштабирования в распределённой системе

В микросервисной архитектуре каждый сервис должен иметь доступ к сессии. Нужна общая хранилище (Redis, Memcached).

// Проблема: сессия на Server1, запрос попал на Server2
Server 1 (load balancer) ← Client
  Сессия создана
Server 2 ← Client (новый запрос)
  Сессия не найдена! LazyInitializationException

// Решение: sticky sessions или распределённое хранилище
@Configuration
public class SessionConfig {
    @Bean
    public SessionRepository sessionRepository(LettuceConnectionFactory factory) {
        return new RedisIndexedSessionRepository(factory);
    }
}

// Но это усложняет архитектуру

3. Зависимость от сессионного хранилища

Если Redis упадёт, все сессии потеряются, все пользователи разлогинятся.

// Сценарий катастрофы
Redis падает (сетевая ошибка, диск переполнен)
↓
Все сессии теряются
↓
Все пользователи разлогинены
↓
Массовая переавторизация (DDoS на сервер)

// С JWT:
Tokens продолжают работать (stored на клиенте)
Пока не истечёт срок действия

4. Мониторинг и отладка

Сложнее отследить, какие данные в какой сессии, как долго живёт сессия.

// Сложно отладить
рфг пользователя в сессии?
Можно ли просмотреть все сессии?
Сколько памяти занимает каждая сессия?

// Решение: инструменты мониторинга
@RestController
public class DebugController {
    @GetMapping("/debug/sessions")
    public ResponseEntity<?> listSessions() {
        // Опасно в продакшене!
        return sessionRepository.findAll();
    }
}

5. Невозможность использовать в микросервисах без общего хранилища

Микросервис1 не может проверить сессию, созданную на Микросервис2.

// API Gateway
@RestController
public class GatewayController {
    @GetMapping("/api/user/**")
    public ResponseEntity<?> handle(HttpSession session) {
        User user = (User) session.getAttribute("user");
        // Session может быть создана на другом микросервисе
        // Нужна共有 сессионного хранилища
    }
}

6. Синхронизация времени жизни сессии

Если сессия истекает на сервере, но cookie ещё живёт, получится ошибка.

// Проблема: расассинхрон
Server: session.setMaxInactiveInterval(1800); // 30 минут
Client: JSESSIONID cookie live 30 minutes

// Если синхронизация нарушена:
Sever удалил сессию в 30:05
Client ещё отправляет JSESSIONID
Server: "Invalid session"
Client: повторный запрос

7. CSRF атаки при неправильной конфигурации

Сессии по умолчанию уязвимы для CSRF, требуют дополнительной защиты (CSRF tokens).

// Уязвимо
@PostMapping("/transfer")
public ResponseEntity<?> transferMoney(@RequestBody TransferRequest request) {
    // Если пользователь посетит вредоносный сайт
    // а тот отправит POST к нашему API
    // и браузер отправит JSESSIONID в cookie
    // Атака успешна!
}

// Защита
@PostMapping("/transfer")
@CrossOrigin(origins = "https://my-domain.com")
public ResponseEntity<?> transferMoney(
    @RequestBody TransferRequest request,
    @RequestParam String csrfToken) {
    // Токен нельзя получить через cookie
    if (!validateCsrfToken(csrfToken)) {
        return ResponseEntity.status(403).build();
    }
    // OK
}

Сравнение подходов

Когда использовать server-side state

• Высокие требования к безопасности (финансы, медицина)
• Нужна мгновенная отозваемость доступа (блокировка аккаунта)
• Монолитная архитектура (один сервер или кластер с общей памятью)
• Сессии короткие (администраторы, внутренние системы)
• Отсутствуют требования к масштабированию на миллионы пользователей

Лучшие практики

• Используйте Redis для хранения сессий в распределённой системе
• Установите правильное время жизни сессии (не слишком долго)
• Используйте HTTPS и Secure/HttpOnly cookies
• Защитите от CSRF с помощью токенов
• Мониторьте утечки сессий (memory leaks)
• Рассмотрите JWT для микросервисов
• Регулярно удаляйте истёкшие сессии

Заключение

Server-side state предоставляет лучший контроль и безопасность, но имеет проблемы с масштабируемостью. Выбор между server-side, JWT и stateless зависит от требований: для интранета и финансовых систем — server-side; для публичных API и микросервисов — JWT; для очень простых случаев — stateless.