Я проверяю в скрипте: если pid != "", то проверяем: есть ли такая запись в БД. Если нету такой, то переадресовываем на http://site[dot]ru/?id=1
Но проблема в том, что если юзер введет такую строку: http://site[dot]ru/?id=1&pid= то ничего не происходит. А нужна переадресация, потому что строка некорректна. Я не могу сделать проверку isset, т.к. pid необязательно указывать в адресе, он может быть, а может и не быть. Конструкция вида
Здравствуйте! Может ли юзер как-то подделать сессии? Может вопрос глупый, т.к. сессии хранятся на сервере, но все равно, есть вероятность? Я где-то слышал, что можно подделать идентификатор сессии, но я его не использую.
Просто на сайте суть такая: юзер может редактировать свои данные. При аутентификации, в сессию записывается его id. Просто если юзер как-то подставит в сессию чужой id, то сможет редактировать чужие данные, что недопустимо. В данном случае, хранить id в сессии безопасно?
то продолжаем авторизацию, показываем *секретное* содержимое
}else{
запрет на просмотр содержимого, переадресация на логин форму
}
}else{
#Если сессия пустая
Подключаемся к базе, берем хэш пароля
Если хэш из куков совпадает с хэшом в базе, то
устанавливаем сессию с хэшем пароля
}
Как думаете, такая защита сойдет для аутентификации? (Добавление)
Таким образом, если хакер взломает базу, то подставить хэш не сможет, потому что не знает, как он получился. (Правда, он может испортить мою базу, но это ругая тема.)
А от стыривания куков можно сделать привязку к IP - мне все равно нужна авторизация только на 15 минут.
генерировать случайную строку, и каждый раз записывать ее в базу и в куки
Не пойдет. А если 2 человека зайдут по одним логином с разных компьютеров? например, на корпоративную почту. У того, кто первый зашел сравнение строк из кук и базы будет давать false === кик. Так не надо.
Цитата:
не проще ли записать все данные о юзере в сессию
Разве сессии не закрываются после закрытия браузера? Мне нужно, чтобы человек мог находиться под своим логином только 15 минут, а потом ре-логин.
Дак как-то не хочется передавать хэш пароля в куки. А такая схема как?:
Таблица в БД:
id | login | password | hash | string
Файл salt.php содержит какую-то определенную строку, сделанную заранее.
При регистрации юзера генерируем случайную строку и записываем в string.
Затем после успешной аутентификации подключаем salt.php и делаем хэш(string.salt). И записываем этот хэш в базу в столбец hash. И в куки отправляем хэш.
И на странице, где нужна проверка авторизации делаем так:
подключаем salt.php
берем из базы hash и string.
если хэш(string.salt) != хэшу из кук, то чистим куки и пересылаем юзера на форму логина, иначе показываем нужную инфу.
Я вот вроде все понял, как это работает.
Только непонятно, как реализовать авторизацию, если два юзера используют один аккаунт, например, корпоративный почтовый ящик. В инете не смог найти.
Например человек А залогинился на сайте. Ему в куки ушла строка случайного хэша; эта же строка ушла в базу, чтобы потом был "автологин".
Но если после авторизации человека А, с другого компьютера авторизуется человек Б, то хэш в базе будет перезаписан на новый и отправится ему в куки.
После этого челоек А при переходе на другую страницу автоматически кикается, т.к. у него не совпадает хеш в куках с хешом в базе.
Да везде по-разному. У меня в одной книге вообще без соли, во второй непонятно. В инете искал, в одном примере постоянная строка хэшируется вместе с логином, во втором - генерируется каждый раз.
Здравствуйте! Я немного не понимаю, как работает авторизация с куками.
Вот как я вижу: юзер зашел на сайт, залогинился. Если логин и хэш пароля совпадают с данными базы, то установить ему куку, а потом на всех сценариях писать session_start и проверять, совпадает ли хеш из куки с хешом в базе.
Только я не пойму какой кеш надо вписывать в куку и в базу для сравнения. Там нужна какая-то "соль" - её нужно отдельно хранить или генерировать после каждой успешной авторизации и перезаписывать в куку и в базу? И как это вообще работает? Объясните попроще, пожалста.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 199
