размер куков
Нет. Нужно хранить меньше куков. В идеале одну - идентификатор сессии/пользователя.
Все временные данные связанные с конкретным пользователем нужно держать в сессии, а в куке ходит лишь id это сессии. Обратное есть ересь и подлежит изжить быть.
К id сессии так же стоит добавлять куку-токен. И ассоциировать определенного юзера только по паре сессия-токен.
К id сессии так же стоит добавлять куку-токен. И ассоциировать определенного юзера только по паре сессия-токен.
По-подробнее... Допустим, при авторизации (или так просто) я создал сессию и создал куку-токен...
Как вы предложите создать куку-токен (какое значение, МД5 даты и логина или что-то еще) И ведь если сессия закончится, то мне не с чем будет сопоставлять токен.
Или генерировать токен при авторизации и записывать его в базу в таблицу с логином\паролем?
Да и какой в этом смысл? бред...
Но я уже придумал, как сохранять состояние корзины..
Как вы предложите создать куку-токен (какое значение, МД5 даты и логина или что-то еще) И ведь если сессия закончится, то мне не с чем будет сопоставлять токен.
Или генерировать токен при авторизации и записывать его в базу в таблицу с логином\паролем?
Да и какой в этом смысл? бред...
Но я уже придумал, как сохранять состояние корзины..
Сессия может закончиться, её может снести сборщик мусора, файлы сессий могут быть просто потерты. Поэтому значащие данные всегда должны записываться в базу. Потому что сессия может быть утеряна, а данные нет.
Теперь касательно id-шника сессии записываемого в куки. Это просто тупо строка символов. И значит можно тупо перебором без всякого перехвата генерить эти id-шки и с шансом отличным от нуля можно будет получить доступ не к своей сессии. А в сессии у нас, к примеру, записан user_id и факт идентификации движок отслеживает именно по нему. Много ли народу мониторит access логи на факты брудфоста? О_о
Вот тут и нужна вторая кука-токен. Угадать пару из двух кук уже практически невозможно. И конечно же пишем эту куку в базу, ведь мы помним, что данные терять нельзя ;) Возражения про нагрузку на базу не принимаются, потому что а) база тюниться; б) кэш, кэш и еще раз кэш; в) зачастую обычно забывают, что сессия это вообще то по дефолту файл и нагрузка на ФС сервера больше, чем на сервер БД. Сверху все конечно же сдабривается https-ом.
В общем это совсем не бред, а тонкости из оперы "не фигачте переменные из $_GET напрямую в SQL запросы".
В общем это совсем не бред, а тонкости из оперы "не фигачте переменные из $_GET напрямую в SQL запросы".
Фу-фу-фу! ) Из гета прямо в скуль... фу-фу-фу... Всё не так плохо как вы говорите.
Опять же, вопрос рационализма.
Угадать пару токен-сессия... или айди сессии.. Проще логин с паролем подобрать )
При том что чуть менее чем на 100% ресурсов логин виден вполне отчетливо.
По сути задача где-то хранить временные данные корзины. id товара и его количество. Напомните пожалуйста и приведите пример, можно ли в Куку совать массив? насколько мне не изменяет память, только строку. А это печально.
Если хранить в сессии, то, по вашему утверждению, это доп. нагрузка на ФС сервера. тут уже зависит от коль-ва пользователей в сутки. И не забываем что БД это тоже файл на сервере. Только бОльшего размера.
Как вариант, сделать таблицу cart, и забивать её данными user_id, sku_id, quantity... И иметь возможность хранить все корзины в БД, не заморачиваясь с сессиями и куками. Но что тогда делать с юзерами, которые набили корзину не зарегистрировавшись, а потом ушли с сайта и забили болт... тогда толку от данных будет 0 и нужно периодически чистить таблицу от мусора.
Всё же думаю, правильно будет держать данные по корзине в сессии... Если юзер забил - его проблемы...
А вдруг я зайду с другого браузера или с другого компа? Тогда все данные сессии потеряются и мои покупки улетят в никуда.
А вообще я сам уже давно сессию храню в БД.
И что? Файл сессий тоже периодически чистятся. А чистить таблицу намного проще и удобнее.
Это концептуально, но выходит за рамки здравого смысла, чтобы не зарегистрировавшись (важно!) набивать корзину с одного браузера\компа, а потом бежать к другому... Вы никак не свяжете эти данные. НИКАК.