https://github.com/SamyRed/surikat-project/blob/master/index.php#L10 PHP: $pass = $db->real_escape_string ($_POST["auth-pass"]); ты зачем его эскейпишь, если не используешь в запросе? --- Добавлено --- ещё ты не проверяешь, нужно ли его перехешить =) https://php.ru/manual/function.password-needs-rehash.html
Ну понятно что можно ещё много чего правильно сделать, я это прочитал. Просто не стал заморачиваться, т.к. это всё равно никому не нужно) --- Добавлено --- А эскейпил я до того как начал API использовать. Он же у меня через двойной md5 прямо в запросе стоял. Щас уберу. --- Добавлено --- Давайте кто больше наклацает Я таблицу рекордов сделал) А кому не нравится мой способ хеширования - пусть взламывает, и читерит себе значение)))
Даже если он прямо в запросе стоял с md5, эскейпить не зачем. md5 - это набор шестнадцатиричных цифр, там не может быть sql-инъекции. Если бы ты применял md5 из SQL, был бы смысл, но ты в запрос подставлял уже от md5-ченный через php
Это норма. Везде так. Полученную дату конвертишь в date, если на выходе получается ошибка, значит пользователь ввел хрень типа 31 февраля.
Далее. 1) ты объявил переменную $errors; Просто раз и объявил. Правило хорошего тона - сразу инициализировать переменную. Во-первых, с инициализированными переменными не бывает проблем типа undefined value. Во-вторых, переменная еще не использвалась ни разу, но мы сразу явно показываем, что это такое, строка, число, булева переменная или массив. По этому, правильно сделать так: PHP: $errors = []; 2) Ошибки аутентификации ты все равно оставил в виде переменных. $authErr = false; $authErr1 = false; Причем их названия нам не дают вообще ничего, кроме того, что может быть ошибка и ошибка1. Правильные названия - основа самодокументируемого кода. Первый пункт, кстати, тоже к самодокументированности относится. 3) Обработка ответа БД ("SELECT * FROM `users` WHERE `login` = '$login'") or die ($db->error) Не надо так делать. Пользователю эти вот жалобы БД ну совсем не вперлись. Лучше выведи ему что-то человекопонятное, типа "Извините, у нас техническая неполадка". Это ему гораздо нужнее. А настоящую ошибку складывай в лог. Кроме того, сообщениями об ошибке ты, до кучи, палишь структуру БД злоумышленнику, в случае чего. 4) Доктайп так и не добавил --- Добавлено --- 5) Если нажать "обновить" на странице с кликалкой, получим вот это: Ну ты понял.
Исправил Это просто не заметил. Уже исправил. Исправил Добавил --- Добавлено --- А насчёт этого, как это можно исправить, помимо редиректов? Или использовать их?
Именно. Всегда, после получения пост-запроса, делай перенаправление на ту же страницу, с которой пришел запрос. Ну или на какую-нибудь еще. От конкретного проекта зависит.
А как тогда быть если нужно вывести какую либо информацию, например ошибку? Не создавать же печеньки с массивом ошибок?
Зачем куки? У тебя разве нет сессий? У тебя разве нет GET-параметров, которые ты можешь вписать в переадресацию? Всякие мейлору и гуглы не стесняются в URL-ы пихать GET-параметры типа "loginerror=true", сдобренные одноразовыми токенами, чтобы повторно ссылка отработала как обычная, а не выводящая ошибки. Плюс, всегда надо включать здравый смысл. Если перенаправление скорее не нужно, чем нужно, то тогда не делай его. Но в случае с кликером перенаправление должно быть. Кликер не должен расти при обновлении страницы, а он растет.
генерируешь некую последовательность символов, дописываешь ее как гет-параметр. И кладешь в сессию. Подразумевается, что в следующем запросе: 1) Есть этот токен. Тогда остальные гет-параметры обрабтываем по полной, генерим тексты ошибок, все оке. Сам токен убираем из сессии. В следующий раз, при обращении по той же ссылке смотрим, что в ссылке токен есть, а в сессии нет, ага...ну значит юзер второй раз по той же ссылке прошел. Не показываем ему сообщения об ошибках и тд, пусть это будет обработано как обычная ссылка. 2) Нет этого токена. Странно. Бывает, чо. Откидываем гет-параметры, обрабатываем как простую ссылку.
Ок. Спс. Завтра сделаю. --- Добавлено --- Стоп, а зачем тогда гет, если можно в сессию записать, и просто убрать после вывода ошибок?
чтобы сравнить, проверить и потратить --- Добавлено --- не, на самом деле есть способ токены никогда никуда не записывать, но тебе рано пока о таком думать, там свои минусы и их надо понимать, т.к. у них далекоидущие последствия.
Как хочешь, так и делай. Я же не знаю точно, что под капотом у того же мылору. Но знаю вот что: им сейчас пофигу на токены и одноразовость ссылок. Просто дописываешь fail=1, и получаешь текст ошибки над формой В общем, решения есть. И любое будет лучше, чем хранение ошибок в кукисах.
Что-то я не понял прикола. Я сделал так, что при нажатии кнопки "Регистрация", в конце проверяется, есть ли ошибки, если есть - создание сессии "errors" и редирект на эту же страницу. Сессия создаётся, редирект происходит, затем я проверяю, существует ли сессия с таким именем. Если да - то пишу в массив $errors всё содержимое сессии "errors". Далее загвоздка. Если оставить всё так, то ошибки выводятся правильно, но при перезагрузке, сессия, естественно остаётся и всегда отображаются ошибки. Если после присвоения переменной $errors удаляю сессию "errors" - просто ничего не отображается, причём пустым оказывается даже массив "errors", хотя ему я присвоил данные до того как удалил сессию. Почему так? Проблема только в том, как правильно удалить сессию. --- Добавлено --- Весь код тут: https://github.com/SamyRed/surikat-project/
1)Конструкция if (isset ($_SESSION["errors"]) && !empty ($_SESSION["errors"]) Избыточна, так как empty автоматически проверяет существование переменной. 2) Потому что после каждого выставления хедера с перенаправлением надо по-хорошему, выставить die или exit. Программа дошла до точки, когда она говорит "нахрен это все, делайте перенаправление". Значит, уже можно прекратить ее работу. В противном случае у тебя скрипт продолжает исполняться,в процессе этого у тебя сносится сессионный массив с ошибками, а потом, при отработке перенаправления оказывается, что этот массив уже снесен и ошибки забирать неоткуда. Либо просто юзай гет-параметры. --- Добавлено --- Ну и да, осваивай дебаг, чтобы видеть, что происходит в коде.
Этого не знал. Спасибо. Сейчас всё работает. А гетами не хочу закакивать строку) Если их там пару штук - норм, но если там какая-то неразбериха, то мне это начинает автоматически не нравиться, тем более, как я считаю, геты - это лишние уязвимости. Хоть и небольшие, а иногда и большие...
Я тебе открою, возможно, глаза на очевидную вещь, но ты, как и многие веб-разработчики, забыл, что пользователи смотрят совсем на другие вещи. Так вот, секрет в том, что пользователю вообще плевать на строку. Закакана она или нет. Пользователь не оценит ее красоту и минималистичность. Пользователь вообще боится адресной строки. Это для него всегда была и будет непонятной магической хренью для вставки ссылок. О том, что в ссылках есть какая-то логика, запросы, или там, красивости, пользователь даже не думает. Пользователь вообще не читает ссылки. Он на них не смотрит как на осмысленный объект. Скорее как на заклинание. Разработчики же придумали себе проблему ЧПУ\неЧПУ ссылок, возвели ее в самоцель, но смех в том, что эти ЧПУ разработчики делают для себя. И для других разработчиков. Попутно сеошники понапридумали, что ЧПУ-ссылки увеличивают пипиську. Но всем пофиг. Всем. Всем настолько пофиг, что даже Гугл совершенно не заморачивается на эту тему. Обрати как-нибудь внимание на адреса, которые он генерирует. Он их вообщ чуть ли не вместо сессии использует целиком и полностью. Потому что всем пофиг, никто не смотрит туда. Уязвимости - это уязвимости. А геты - это метод запроса. Если ты думаешь, что POST-запросы, в отличие от GET-запросов какие-то особо защищенные, я тебя разочарую. POST-запрос можно подделать так же как и GET. Написать туда можно что угодно так же как в GET. Даже больше. А теперь вишенка - сформированный POST-запрос имеет даже синтаксис тот же, что у GET-а. Те же var=val&var2=val2. Уязвимость в коде, а не в методе запроса.
Я бы вообще там сделал какой-нибудь роутинг, если бы взялся эту задачу пилить, хоть бы даже и на одном файле. А то от такого файла index.php у меня мозги закипают
Не знаю как все, а я всегда обращаю внимание на читабельность ссылки. --- Добавлено --- Но на php.ru, ведь, тоже ЧПУ. Зачем тогда, если всем пофиг? Тем более, что, на сколько я знаю, ЧПУ жрёт ресурс. Это я не о том что ЧПУ - круто. Я сам никогда не заморачивался, меня устраивает вполне site.com/?page=profile
Ох...перечитывай мой предыдущий пост, там все ответы. Перечитывай снова и снова. --- Добавлено --- ЗЫ. php.ru поднят на готовом движке, к слову. И написан он не мною. Я хз, почему я должен быть в ответе за разработчиков форума xenforo. Почему ЧПУ как самоцель везде и всюду - я тебе описал выше.
Ещё 1 аргумент, почему я не хочу использовать гет, скорее даже, почему я предпочитаю использовать сессию вместо гет. Если есть возможность не выводить это в гет, и оставить в тайне, то почему бы так не сделать. Даже если туда никто не смотрит, в любом случае, это будет лучше.