- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Куки гораздо "дырявее" сессий, если уж на то пошло. И сессии позволяют полностью обходиться без кук.
Lor, куки и сессии близнецы братья.
Сессия пишется в виде идентификатора в куки, разница лишь в том, что сами данные по сессии храняться на сервере.
Сессии без кук могут работать только если идентификатор в урле передавать.
А что такое куки? вот блин, сегодня же четверг только ))
Видимо ТС немного попутал сессии , куки и веб3 ))))
2. в базе
А как вы при этом идентифицировать пользователя будете, чтобы взять нужную сессию из базы?
А как вы при этом идентифицировать пользователя будете, чтобы взять нужную сессию из базы?
А это вариант самоделкиных они всякие id или key передают, где значение номер поля пользователя в базе.
С помощью чего передают? В урле? Так это третий вариант получается.
Да к чему такие сложности? Что там такого смертельного в этих куках то?
Если юзер параноик пусть идет лесом вообще, засядет в туалете, выключит свет и не подходит к компу.
ТС скорее всего возмущался хранением "долгих" настроек в куках, здесь я согласен эти данные логичнее хранить в базе. А ид сессии несомненно в куках, да и пхп сам определит если невозможно передать ид в куках и сделает это через урл :)
Segey, я немного неверно выразился. Сам массив сессии можно хранить как в файлах, так и в базе, я дополнительно на время сессии еще и проверку по ip включаю, но идентификатор либо в куки, либо в урл - других вариантов нет.
Если юзер параноик пусть идет лесом вообще, засядет в туалете, выключит свет и не подходит к компу.
Лучше полем, но все равно идет. Это равносильно тому, когда покупатели Интернет-магазинов отказываются писать адрес доставки или свое имя и фамилию, а потом удивляются почему это никто ничего не везет?
А, например, во фреймворке Django идентификаторы сессий намерено хранятся только в куках, и не используется передача ID в URL, даже если куки отключены. Для безопасности (http://docs.djangoproject.com/en/dev/topics/http/sessions/#session-ids-in-urls):
The Django sessions framework is entirely, and solely, cookie-based. It does not fall back to putting session IDs in URLs as a last resort, as PHP does. This is an intentional design decision. Not only does that behavior make URLs ugly, it makes your site vulnerable to session-ID theft via the "Referer" header.
С помощью чего передают? В урле? Так это третий вариант получается.
Имеется ввиду, что сам идентификатор хранится в базе, а передается если можно так сказать идентификатор идентификатора :) Типа свой обработчик сессий. Типа md5(md5()) :)