История изменений
Исправление Black_Roland, (текущая версия) :
Уточним:
Я делаю куку на 20 лет, в ней хранится уникальный uuid.
Дальше записываю в БД этот uuid и начинаю писать (ссылающеся на него) записи о посещённых страницах.
Хранить страницы удобно тем, что можно будет построить некие правила открытия/закрыти доступа после.
Сделай сессию на 20 лет. Только не понятно зачем 20 лет? Время жизни обновляется при каждом запросе, тут и месяца хватит. Основная задача отсеить пользователей, которые сильно много публикуют объявления, а значит они часто пользуются сервисом (несколько раз в месяц) и сессия будет каждый раз обновляться и никогда не умрет.
На сервере механизм сессий должен сам генерировать уникальные UUID и писать куки с этим UUID пользователю в браузер. На сервере сессии можно хранить где угодно (как настроишь). В сессию можно также записывать ID объявлений и даты. Через месяц неиспользования сервиса кука и сессия сами удалятся и не будут засирать БД. Можно сделать время жизни год, если за год пользователь не воспользуется сервисом, то данные удалятся. Думаю этого вполне достаточно для отсеивания спамеров. Сессии на сервере можно хранить в Redis (СУБД ключ-значение в памяти), тогда работать будет быстро (быстрее схемы с PostgreSQL). Но также сессии можно хранить и в PostgreSQL.
Исправление Black_Roland, :
Уточним:
Я делаю куку на 20 лет, в ней хранится уникальный uuid.
Дальше записываю в БД этот uuid и начинаю писать (ссылающеся на него) записи о посещённых страницах.
Хранить страницы удобно тем, что можно будет построить некие правила открытия/закрыти доступа после.
Сделай сессию на 20 лет. Только не понятно зачем 20 лет? Время жизни обновляется при каждом запросе, тут и месяца хватит. Основная задача отсеить пользователей, которые сильно много публикуют объявления, а значит они часто пользуются сервисом (несколько раз в месяц) и сессия будет каждый раз обновляться и никогда не умрет.
На сервере механизм сессий должен сам генерировать уникальные UUID и писать куки с этим UUID пользователю в браузер. На сервере сессии можно хранить где угодно (как настроишь). В сессию можно также записывать ID объявлений и даты. Через месяц неиспользования сервиса кука и сессия сами удалятся и не будут засирать БД. Можно сделать время жизни год, если за год пользователь не воспользуется сервисом, то данные удалятся. Думаю этого вполне достаточно для отсеивания спамеров. Сессии на сервере можно хранить в Redis (СУБД ключ-значение в памяти), тогда работать будет быстро (быстрее схемы с PostgreSQL). Но также сессии можно хранить и в PostgreSQL.
Исходная версия Black_Roland, :
Уточним:
Я делаю куку на 20 лет, в ней хранится уникальный uuid.
Дальше записываю в БД этот uuid и начинаю писать (ссылающеся на него) записи о посещённых страницах.
Хранить страницы удобно тем, что можно будет построить некие правила открытия/закрыти доступа после.
Сделай сессию на 20 лет. Только не понятно зачем 20 лет? Время жизни обновляется при каждом запросе, тут и месяца хватит. Основная задача отсеить пользователей, которые сильно много публикуют объявления, а значит они часто пользуются сервисом (несколько раз в месяц) и сессия будет каждый раз обновляться и никогда не умрет.
На сервере механизм сессий должен сам генерировать уникальные UUID и писать куки с этим UUID пользователю в браузер. На сервере сессии можно хранить где угодно (как настроишь). В сессию можно также записывать ID страниц и даты. Через месяц неиспользования сервиса кука и сессия сами удалятся и не будут засирать БД. Можно сделать время жизни год, если за год пользователь не воспользуется сервисом, то данные удалятся. Думаю этого вполне достаточно для отсеивания спамеров. Сессии на сервере можно хранить в Redis (СУБД ключ-значение в памяти), тогда работать будет быстро (быстрее схемы с PostgreSQL). Но также сессии можно хранить и в PostgreSQL.