Ипользую $_SESSION['имя_сессии']; для передачи массива между страничками PHP. Вопрос такой: Пользователь в своем браузере может запретить использовать КУКИ. А может быть такой же запрет на работу $_SESSION['имя_сессии']; ? Если есть такой риск, похоже, придется все переделывать на GET...
Если куки запрещены, то по умолчанию ключ сессии будет передаваться через параметр PHPSESSID в ссылке. Передачу PHPSESSID в ссылке можно запретить только настройками твоего веб-сервера
Тебе ведь ответили на вопрос полностью. Куки можно отключить, а сессии используют куки для хранения индификатора. Поэтому если куки отключены, а на веб сервере запрещена передача PHPSESSID, то передача твоего массива будет невозможна в данном контексте!
Легион, ты судя по всему на Тостере переобщался?)) Он же тебе ответил что сессии работают через куки Следовательно - если отключить куки - отключатся и сессии Логично? На самом деле в современных браузерах у тебя весьма широкий выбор по хранению данных на стороне пользователя - и веб-хранилище, и всякое другое В общем, это большая тема))
Другой момент - почему выбраны сессии, а не куки? Как правило это используют для того, чтоб не показывать те данные которые не нужно показывать, тавтология вышла, но это так, пища для размышления. Если ты хотел использовать сессии, то значит данные которые будут передаваться, должны быть скрыты, а GET покажет их в строке браузера. Как вариант, сделать некий кеш на файлах, с ограниченным временем хранения. Т.е. свой же массив можно записать в JSON формате в текстовый файл, а потом его читать по мере надобности в тех местах, где это требуется. Как пример - имя для файла кеша использовать некий симбиоз md5(user_agent+language) для уникализации имени файла.
Прога моя представляет собой тест, состоящий из 5 вопросов (5 страниц) с 5 ответами на каждый (чекбуксы). массив с ответами юзака должен накопиться и передаться на последнюю страницу. Сессию использую, потому что другого транспорта не нашел. Но если запрет куков не заблокирует этот механизм то "все под контролем" )))
Задача из разряда тех, которые не надо решать программисту. Достаточно нового пользователя встречать банером, что для работы данного сайта необходимы куки. Если кто-то не хочет ими пользоваться — это его выбор. Он теперь в курсе, что что-то станет недоступно. тчк --- Добавлено --- P.S. Видишь ли, куки могут запретить те, кто не хочет чтобы его отслеживали. А ты, фактически, ищешь альтернативный способ отслеживать того, кто не хочет чтобы его отслеживали. Это блин как-то аморально и, возможно, даже противозаконно.
дадада, Сысоев и Дуров осуждают такие методы ...но если серьезно, ТС никого не хочет отслеживать, он просто хочет сделать свой скрипт универсальным и да, в этом случае нужно просто в GET передавать данные со страницы на страницу да и всё и, коль уж речь идет о чекбоксах, то и через POST можно тож нормас, даже удобнее
Если ТС хочет чинить то, что не сломано, это его право --- Добавлено --- Костыли порождают нужду в новых костылях. Скоро ТС будет спрашивать "а как запретить поисковикам проходить мой опросник". Потому что блин get запросы без куков - это то, что делают поисковые краулеры.
Ну так а разве Ajax и POST не решает эту задачу? Либо просто на JavaScript сделать опрос, когда просто каждый вопрос будет обновляться по типу слайдера и в конечном варианте когда будет массив ответов, отправить его через POST.
Чтобы разрешить передачу PHPSESSID в get-параметрах надо тоже специально настроить веб-сервер. И это кажется безумием. https://www.php.net/manual/ru/session.configuration.php#ini.session.use-trans-sid То есть вот это вот неверно: > то по умолчанию ключ сессии будет передаваться через параметр PHPSESSID в ссылке. Нет, не будет. И не надо. --- Добавлено --- Руки чешутся закрыть тему, как источник ереси и борьбы с ветряными мельницами. --- Добавлено --- Нет. Запрет на куки влечёт за собой также запрет сессии. И это проблема конкретного пользователя, его право и его боль. Не надо автоматизировать бардак. --- Добавлено --- В вебе есть два способа идентификации и авторизации пользователя: - с сохранением состояния — идентификация через куки и/или сессию - без сохранения состояния — идентификация через токен доступа. так работают RESTful приложения. необходимая информация хранится локально на клиенте и по необходимости шлётся на сервер. @Legion5 почитай stateless API и, я уверен, начальный вопрос отпадёт сам.