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

[zerkms]

к базе полюбому коннектиться. один запрос по PK к полупустой таблице выполняется моментально.

Запрос к таблице (которая не факт, что полупустая) всегда будет дольше обращения к переменной в сессии, которая так и так поднимается на каждом запросе.

 

[Духовность™]

которая так и так поднимается на каждом запросе

да ну, с чего бы это вдруг?

 

[zerkms]

triumvirat: а как вы пользователя иначе отслеживаете, которому пароль поменяли?

 

[Духовность™]

triumvirat: а как вы пользователя иначе отслеживаете, которому пароль поменяли?

зачем его отслеживать? я не понял вопроса

 

[zerkms]

Не тупи. Где у тебя хранится user_id?

 

[Духовность™]

В куки.

 

[zerkms]

Это не шутка? Т.е. шифрование и помещение в куки?

И с потерей всех приватных данных в случае утери соли/алгоритма шифрования?

 

[Духовность™]

$this->getResponse()->setcookie('auth_id', $user->getId(), $time, '/');
$this->getResponse()->setcookie('auth_hash', md5($user->getLogin() . $user->getPassword().
                                                                     Base_Registry::getInstance()->config['user_cookie_salt']) , $time ,  '/');

 

[zerkms]

Как у вас всё сложно %)

 

[Духовность™]

Как у вас всё сложно %)

а как надо?

 

[zerkms]

Я не вижу причин отказываться от сессий.

 

[craz]

Я не вижу причин отказываться от сессий.

на лицо применение базы ради ее применения

 

[zerkms]

При чём тут вообще база?

Сессии по умолчанию лежат в файлах.

Это применение сессий ради хранения сессионных данных, а не ради того, что ты мне пытаешься навязать.

Сессии - встроенный механизм, позволяющий без всяких солей-шифрований получить достаточно безопасный способ хранить клиентские данные.

До сих пор не вижу ни одной причины (как и аргумента) против этого встроенного дешёвого и быстрого решения.

 

[AmdY]

zerkms
не касается твоего варианта, здесь всё верно. у меня на проекте кэшировали в сессию, всё бы ничего, если бы только там не было выборок типа топ 100, что больно бьёт с учётом сериализации сессий, к тому же это делается для каждого пользователя, хотя можно было сделать единожды для всех.

 

[prolis]

Ну и зачем сообщение в стиле "Старый пароль введён неверно" будет висеть в адресной строке?

в адресной строке ничего плохого не висит: (script.php?result=passerror)
в script.php:

if ($_GET('result')=='passerror') echo 'Старый пароль введён неверно';

 

[Духовность™]

в адресной строке ничего плохого не висит: (script.php?result=passerror)
в script.php:

if ($_GET('result')=='passerror') echo 'Старый пароль введён неверно';

Это говнокод. Не надо засарять разными GET-параметрами сценарий. Нотификейшен чрезвычайно удобно написать, написать, на какой странице он должен быть показан и все - больше никакой головной боли. А с твои вариантом надо делать кучу if-ов. Ну и про уникальные данные я уже сказал выше...

До сих пор не вижу ни одной причины (как и аргумента) против этого встроенного дешёвого и быстрого решения.

в контексте этой задачи - я описал. хранение записи до востребования.

нравятся сессии - используйте. мне нравится делать 1 запрос по первичному ключу к базе.

 

[флоппик]

в адресной строке ничего плохого не висит: (script.php?result=passerror)
в script.php:

if ($_GET('result')=='passerror') echo 'Старый пароль введён неверно';

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

 

[Активист]

triumvirat
Простите, это не говоно код.

> Основная проблема этого кода в том, что после рефреша страницы сообщение будет показано снова, не зависимо от того, изменились ли условия или нет.
Это не проблем.

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

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

Никогда не понимал людей, которые вместо того, что бы использовать простое решение, возьмут и придумают что-то свое, да причем так криво, зато без $_GET.

А про количество if в этом случае врать не надо.

$errors = array("auth" => "Ошибка авторизации", "old" => "Пароль устарел");
if (isset($_GET['error']) && isset($errors[$_GET['error'])) {
echo $errors[$_GET['error']];
}

 

[AmdY]

Активист
там смена пароля, сессия стартанута по любому.

 

[Активист]

Зачем учиться плохому изначально? А если задача измениться? Помимо смены пароля добавиться - добавление информации, например. Применять нужно всегда правильные решение, и использовать типизацию кода.

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