Альтернатива HTTP-куки?

Question

Говорят, что файлы cookie плохие . Лично я считаю, что должен быть «более разумный» способ определения состояния пользователя в веб-приложении.

Скажем, в настоящее время это работает в распределенной среде, где xyz.com имеет много пулов и серверов (о которых я знаю):

1. Пользователь входит в систему xyz.com
2. Модуль входа в систему xyz.com оставляет куки на локальном компьютере клиента.
3. Теперь, когда клиент заходит на Feature1 на xyz.com, пул feature1 проверяет наличие локального куки-файла, находит ли он его и не истек ли он, Feature1 предполагает, что клиент исправен, и впускает его.

Итак, feature1 слепо доверяет клиенту из-за cookie, сброшенного модулем входа в систему.

Но я чувствую фундаментальный недостаток здесь на этапе 3. Что если хакер клонирует печенье и пытается что-то сделать? (это первое очевидное, что хакер попытается сделать, нюхает куки)

Итак, есть ли альтернатива этому? - как будет в будущем работать веб-хранилище, флеш-объекты? или куки будут править?

Не ищу очевидного ответа, потому что его нет. Меня интересуют разные точки зрения приближения к этой проблеме.

Спасибо

Answer 1

Я считаю, что информация в этом ресурсе от Google и / или по этой ссылке поможет вам найти альтернативы для сохранения информации на стороне клиента.

В основном ... существует 4 различных способа хранения данных на стороне клиента без использования файлов cookie:

1. Web SQL (мой любимый, и НЕ устарел )
2. IndexedDB (еще одна база данных с другой структурой и приемлемостью)
3. Веб-хранилище (Пары сеанса и локальный ключ / значение)
4. Кэш приложения (файлы для WebApps)

Я считаю, что для ваших конкретных потребностей правильное решение - локальные пары веб-хранилища.

Answer 2

Один из фундаментальных принципов REST , и я имею в виду real REST - не сохранять состояние на сервере, если на сервере нет состояния, то нет нужен файл cookie, который будет использоваться в качестве ключа для поиска этого состояния.