Передача данных после Header ("Location: ");

AmdY

Пью пиво
Команда форума
по хорошему, в гете вообще не нужно передавать error
а после успешной операции по f5 он не должен вводиться в заблуждение, что операция повторно прошла.
 

fixxxer

К.О.
Партнер клуба
Генерировать идентификатор, класть данные в сессию, а в урле передавать идентификатор?
Решает вроде все проблемы озвученные.
 

флоппик

promotor fidei
Команда форума
Партнер клуба
Генерировать идентификатор, класть данные в сессию, а в урле передавать идентификатор?
Решает вроде все проблемы озвученные.
Я тебе дам маленькую подсказку... этот идентификатор и так генерируется... называется - session_id ) зачем его генерировать еще раз?
Положил данные в сессию, на следующей странице вынул и показал, и почистил сессию. Сюрприииз! Все работает.
 

Духовность™

Продвинутый новичок
triumvirat
1. Использование сессий здесь - не уместно, потому как - сессии не всегда есть (поддержка кукиес), сесси - это процессорное время и нагрузка на диск.
2. Использовать БД - это вообще "дурдом" чистой воды.
3. Использовать это все вместе - еще худший дурдом.
ололо. "Сессии не всегда есть". Интернет тоже отсутствует в Сибири? ) Если какой-то шизофреник куки себе отключил, то это его сугубо личные проблемы. Так же как и с IE6.

На форуме двойные стандарты. Иного бы заклевали за слова о "нагрузке на диск".
Поглядим давайте на нагрузку:
Код:
SELECT *
FROM `notifications`
WHERE id_notification =231
LIMIT 0 , 1
на моей старой машине:
Код:
1 total, Query took 0.0006 sec
на виртуальном сервере:
Код:
Отображает строки 0 - 1 (1 всего, запрос занял 0.0004 сек.)
Простите, это не говоно код.

А про количество if в этом случае врать не надо.
PHP:
$errors = array("auth" => "Ошибка авторизации", "old" => "Пароль устарел");
if (isset($_GET['error']) && isset($errors[$_GET['error'])) {
echo $errors[$_GET['error']];
}
Простите, это именно говоно код. На каждой странице прикажете объявлять говномассив этот?) Взамен чрезвычайно удобной и гибкой конструкции вы приводите корявое решение, с какими-то ключами и проверками.

Подобные Error Messages (например http://domian.tld/auth.php?errcode=passdismatch) применяются довольно часто, особенно в различных системах централизованной авторизации (Open ID, Live ID, Site API), нужно отметить, что применяются успешно.
И что дальше? Это догма и данное решение нельзя критиковать? Мы в КНДР живем?


Теперь как у меня сделано покажу (ещё раз):

PHP:
$redirect = new Base_Redirect();
// строка с html показана для наглядности
$redirect->setMessage('Пользователь <a href="/user/{user_id}">{user_name}</a> сохранен. 
Спасибо, администратор {admin_name}')
         ->addParam('user_name', $user->getName())
         ->addParam('user_id', $user->getId())
         ->addParam('admin_name', $administrator->getName())
         ->setRedirectUrl('/admin/users/')->run();
теперь мне больше НИЧЕГО не нужно делать - на странице /admin/users/ текст сообщения будет гарантированно показан. ВСЕ.

Такое с конструкцией вида /auth.php?errcode=passdismatch вы никогда не сделаете.
 

Mols

Новичок
хз...В самопльном движке для ошибок делал так.
$engine->addError()
который их писал (добавлял в массив) в сессии.
Добавлял навалом без каких-то уникальных ключей.
Если дело доходило до отображения,( точнее не если а КОГДА) ошибки доставались через метод ->getErrors() который чистил их из сессии...
Если же выполнялся редирект, то до выполнения ->getErrors() не доходило.
Собсно всё.
Пофигу какие-то уникальные ключи и прочие "сложности"
Место и стиль для отображения ошибок - одинаковые по всему сайту и включены в общую часть шаблонов.
Очень удобно.
 

fixxxer

К.О.
Партнер клуба
Я тебе дам маленькую подсказку... этот идентификатор и так генерируется... называется - session_id ) зачем его генерировать еще раз?
Положил данные в сессию, на следующей странице вынул и показал, и почистил сессию. Сюрприииз! Все работает.
Спасибо, капитан!

Я про ситуацию с двумя окнами.

Хотя сам я ее не считаю важной и забиваю, но если уж вопрос возник...
 

Активист

Активист
Команда форума
> зачем его генерировать еще раз?
Я применял такую штуку. В сессию ложил следующие данные.
$this->setReturnPath("/ru/admin/catalog/section-12/page-3/list.html");
То есть ложил в сессию данные о том, куда возвратится пользователю после нажатия, например, на сохранить в редактировании объекта.
Сначала, просто использовал ключ returnPath - но тут вдруг выяснилось, что если я открыл два окна - для редактирования двух разных объектов и по кнопке "сохранить" я попаду в одном окне не туда. куда ожидал,
это называется bug, все же я оставил сессию для этого, но добавил название модуля в ключ, это практически решило проблему, но факт наличия бага остался, использование, например returnPath в ГЕТ запросе решила бы эту проблему и исключило баг.

> Простите, это именно говоно код.
Говнокод - это использвание бд ряди ее использования.

> На каждой странице прикажете объявлять говномассив этот?)
Нет, это не говномасив, это массив, очень удобная штука, причем в контексте архитекруты может находится в объекте или конфигурационном / языковом файле, о подключении которого кодер задумываться не будет.

> И что дальше? Это догма и данное решение нельзя критиковать?
Я хотел бы посмотреть на вас, как вы будете сессии создавать на разных серверах, например - сервере авторизации и сайте клиенте.

> Теперь как у меня сделано покажу
....
> - на странице /admin/users/ текст сообщения будет гарантированно показан. ВСЕ.
Научитесь различать задачи, показать текст на этой же странице или через редирект location.

Офтоп про проверки:
> корявое решение, с какими-то ключами и проверками.
Чем оно кривое? Аргументы пожалуйста, про сессии я привел аргументы.
И про проверки - проверки должны выполняться всегда, даже тогда, когда мы как бы уверены, что переменная была. В паблике все проекты работают на E_ALL + display_errors = on, и в паблик проект попадает только тогда, когда после стрессоустойчивого тестирования не выявлено ни одного notice (если в результате работы сайта выпадет хоть один нотис - тестер получает)
Любой notice - есть потенциальная уязвимость. Кроме того, после программирования спец. демона для передачи большого объема данных между тысячами он-лайн пользователей, написанном на TCL - приходится задумываться о том, есть ли переменная, поскольку в forever если в процедуре будет ошибка доступа к перменной - система откажет работы, кроме того, демон мог работать месецами - без утечек памяти, а утечки памяти - это и есть неправильное (нетепичное) для программирования надежда на интерпретатор.
 

zerkms

TDD infected
Команда форума
"Я хотел бы посмотреть на вас, как вы будете сессии создавать на разных серверах, например - сервере авторизации и сайте клиенте."

В зависимости от реализации, сервер авторизации либо возвращает возникшую ошибку, которую сайт-клиент показывает безо всяких вообще промежуточных сохранений (без сессий, гетов и прочего), либо вообще не уходит со своего домена и сам показывает ошибку.

Так что про сессии на разных серверах - мимо кассы.
 

Активист

Активист
Команда форума
zerkms
Ну дк, давай доводить до людей, о заранее правильных решениях, а не "ну в этом контексте пойдет", ведь научиться программировать правильно - сложно и главное очень долго, и не будем уподобляться Евгению Попову.
 

zerkms

TDD infected
Команда форума
Активист: ну вообще говоря я как бы своё "правильное" решение высказал. Для меня наиболее приемлемым считается вариант с сессиями (flash message). Варианты с гетом я считаю как минимум кривыми, как максимум - непрофессиональными.

Приводить в пример "крупных" игроков рынка не нужно, а то я тоже вспомню, что много где используется global и при этом не является той практикой, которую стоит перенимать.
 

Активист

Активист
Команда форума
Хорошо, аргументы приведены, пусть читатели приминают решения на основании них.
 

iceman

говнокодер
сообщения стандартные?

штук там 3-10?

делай редирект, на script.php?error=ID(int)
а в скрипте ставь
PHP:
switch($_REQUEST['error']) { case 1: ... case N: ...; break;}
 

zerkms

TDD infected
Команда форума
Активист:

1. хомяки... сам-то наверное не хомяк, ага
2. зачем делать так, если можно сделать нормально?
3. вы бы лучше скорострельность свою с контактовской сравнивали, а не то, как они ошибки выводят.
 

Ragazzo

TDD interested
zerkms
ну у них там для скорострельности наверное куча своих плюшек, а ни один голый php, очевидно же...) я хомяк ((
 

Духовность™

Продвинутый новичок
Я хотел бы посмотреть на вас, как вы будете сессии создавать на разных серверах, например - сервере авторизации и сайте клиенте.
Мне не интересны из пальца высосанные задачи.

Научитесь различать задачи, показать текст на этой же странице или через редирект location.
Так мы и говорим про loaction если ты не заметил.

Чем оно кривое? Аргументы пожалуйста, про сессии я привел аргументы.
Аргумент, что базу нельзя использовать - это просто смешно. Запрос к базе по PK к практически пустой таблице выполняется меньше мгновения. Четыре тысячных секунды. И ты к этому привязываешься, рассказывая о "использовании бд ряди ее использования". Это смешно просто.

Аргументы наглядно, с кодом я привел в предыдущем посте. Твое решение не может выводить пользователю при редиректе какие-то уникальные данные. Оно заставляет привязываться к каким-то ключам и по сути, довольно уныло с точки зрения юзабилити и реализации.
 

zerkms

TDD infected
Команда форума
triumvirat: тут дело в другом, зачем в базу в принципе ложить что-то на 1 раз?
Почему не положить в сессию, которая для таких временных данных и нужна.
 

Духовность™

Продвинутый новичок
triumvirat: тут дело в другом, зачем в базу в принципе ложить что-то на 1 раз?
Почему не положить в сессию, которая для таких временных данных и нужна.
делайте как хотите.
Я сессии не использую только потому, что я их не использую. Ну и за БД я привел аргумент - долгосрочное хранение сообщения.
 
Сверху