vitaliy_mad
ЧТо Вы так схватились за сессию, отпустите ее. Картинка следующая:
1) ПРи открытии любой страницы авторизованым пользователем - оставляем уникальный код (пусть это будут любые данные, например: base64((рандомный код заносящийся каждому юзеру)+idсесии .т.к она уникальна)) и еще из всего этого вычисляем хэш).
2) Если пользователь входит, но его сессия оборвана и нужно авторизоватся, обращаемся к БД, если конечно у нас есть наif кука.
3) Если это настоящий пользователь, то он авторизуется автоматом, если же нет - это украденый код, то злоумышленник войдет только под одним условием:
---- Если пользователь, после передачи данного кода, НЕ открывал страницы сайта ------
Если он открывал, то пароль в БД не будет найден и выскачит форма аторизации, как и в случае простого отсутствия кука.
Парится и воравать номер сессии я бы не стал, может быстро стать не актульным. Думаю разработчики PHP по этому поводу придумали еще свои интриги, я просто еще в это не лез. А вот, когда работаем с Cookies то, прийдется работать с БД, чтоб защитится. В куках не нужно передавать только пароль и логин, нужно передавать независимые данные, т.к. будет единственны шанс у злоумышленника пройти между сразу после последнего посещением, т.к. после открытия новой страницы рандом и данные в куки обновятся. Следовательно такая система сработает, только если после передачи cookies злоумышленнику, пользовтель не должен открыть страницу сайта, только в этом случае данные с куков будут актуальны.
P.S. вытяните с этого мусора истину и поймите, что данный случай удобней всего. А так вообще заметте, что защита существует только для увеличения веса кода и никакого хакера она не остановит, только хакеры-делитанты ее пугаются.
В БД записываем все, что получится вытащить о пользователе. Например используем AJAX и тянем тип браузера, операционки и т.д. - записываем все в браузер в куке даем чисто наш уникальный код - например записаный в туже БД номер сессии. Потом при входе, если пользователь не авторизован и не имеет сессии - берем у него все данные и проверяем. Т.е. даже если злоумышлник скопирует номер куки, то ему еще прийдется использовать все-то же что и настоящего пользователя. Т.е. немного еще усложняется задача для взлома.
Serga
Хотя знаеш я листал сейчас немного и мне кажется - это на сервере, что-то - нужно читать как минимум htaccess (Добавление)
А кодировка на самой странице не имеет значения
Serga
Т.е. тут чисто принципиально русский текст. Тогда нужно углублятся ниже нежели сервер, т.к. если у Вас уже в некоторых браузерах все ок, то нужно смотреть проблему браузеров и т.д.
Serga пишет:
1. Гугл с яндексом понимают транслит, но не всегда.
Скорей русский текст не всегда, а вот транслит - это чисто из a-z делать запросы (ну и еще некотрые символы) - его он всегда будет отлично читать.
Champion
В том случае да, но мне нужен общий случай. Я не знаю как пользователям взбрендит вводить данные. А то чисто пример решения проблемы. Да и вобще, когда знаешь колличество всего можно подогнать все. Но это тормознет обработку, чего я не желаю. Нужен более простой вариант.
Я вообще пару раз прохожу, выбираю ответ - нажимою. После чего ничего не происходит, таймаут идет дальше, доходит до 3 секунд, нажимая повторно и меня перекидывает на несколько вопросов вперед, после чего в результате именно то колличество неправильных ответов, которое проскакивает. Просто в шоке.