Чтобы они не мучался не понимая почему не проходят валидацию данные. Регулярки для проверки соотвествию шаблону.
Какую валидацию? Снова повторяю вопрос - зачем проверять, какие символы использует пользователь? Особенно в пароле. Какая в этом смысловая нагрузка и польза?
Чтобы он хрень какую-нибудь не передал туда. --- Добавлено --- В интернете видел видосы всякие про sql иньекции и т.п.
Какую? Давай, развивай мысль. Это программирование. Ты или знаешь что делаешь, или нет. Какую хрень может передать человек в логине? И тем более пароле, который, в итоге, один фиг пойдет под хэш? Важно, чтобы ты сам понял, почему у тебя там проблема, а не просто поверил наслово дяде с форума. А то так вот, на вере дядям можно далеко уехать. В овраг, например.
Я скорее не знаю что сделал) --- Добавлено --- удалил эти методы для пароля и логина --- Добавлено --- Убрал проверку и вот поставил для защиты trim(htmlspecialchars($_POST['password']));
Пароль не должен храниться открытым. Поэтому вообще всё равно, что туда передадут. https://secure.php.net/password_hash Что передадут в логин тоже всё равно, если при обращении к БД использовать подготовленные запросы, а при выводе в браузер - пропускать через htmlspecialchars
И как эта защита должна помочь? Что она делает? Как это обеспечивает безопасность? Безопасность от чего именно? Как можно эксплуатировать уязвимости, от которых ты пытаешься закрыться?
Теги всякие php передать и тп. символы которые могут ошибки вызвать разные. trim пробелы, в книге php 7 в подлиннике читал что всегда надо строку от пробелов очищать, а htmlspecialchars чтобы теги специальные приобразовывать в html-сущность, чтобы всякие гадости не могли передать, примеров не знаю, посветите меня, я нихрена не понимаю, что почему и как надо.
mysql --- Добавлено --- ТОЧНО! нельзя в mysql вызвать php скрипт получается) И при выборке данных потом из бд возращается строка, так что это бесмысленно. --- Добавлено --- Или неТ? --- Добавлено --- Неужели я опять чушь несу?
А зачем вообще тогда htmlspecialchars делать, и в каких случаях он уместен? Трим думаю оставить нужно, потому что пользователь получается пробелы может одни передать и все.
Конкретика, конкретика. Больше конкретики. Какие всякие php-теги? Какие символы, способные вызвать ошибки разные. У тебя есть их список? Поделись. Как это все может навредить БД? Не ломай голову. Никак. Бд вообще невозможно навредить информацией. Но можно запулить SQL_инъекцию в запрос через принимаемые данные. И твои супер-фильтры, вот ни один ни разу не помогают от SQL_инъекции. Ни разу. Ни один. Там должно быть написано, зачем. Не надо ничего делать на всякий случай. У всего должен быть смысл. Пробелы не являются вредным символом. Другое дело, что они не всегда желательны, да. Это вот именно тот случай. Теперь ты уже не вслепую функции тыкаешь, а обосновываешь. Это правильно. Гляди, не важно что ты передал в базу. HTML, JS, байты, содержащие картинку. Ей побоку. Она - коробка. Другое дело то, как эти данные будут использоваться. И тут вот самое важное - изменять данные перед записью в базу нельзя. Это вандализм. Ты их портишь. Введено было не то, что ты сохранил. А исходник не вернуть. Если тебе надо вывести какие-то данные на страницу, но не нужно, чтобы они интерпретировались браузером как HTML и JS, или просто в тексте могут быть угловые скобочки, на раз ломающие верстку, то надо прогонять данные через htmlspecialchars непосредственно при выводе. Забрали из бд исходник, модифицировали, отдали. В любом случае всегда важен контекст использования данных. Всегда на это это учитывать. Под одну единую гребенку нельзя все чесать. И почитай про SQL-инъекции.
Я понял передав в базу htmlspecialchars ну то есть перед отправкой в базу пропустил этой функции я уничтожил данные, теперь туда сохранились html-сущности и их не восстоновить. --- Добавлено --- Я убрал в данном случае htmlspecialchars вообще он мне не нужен, т.к. пароль будет хэшированный и т.д. --- Добавлено --- Как правильно "Солить данные"? Я вот так сделал $this->password = crypt($this->password, 'InEnEfRvTlER');
Ну..в данном случае - восстановить, в PHP есть обратная операция. Но смысл ты понял верно. Просто есть более вандальные функции, типа striptags. Вот после нее уже ничего не вернуть. Так или иначе, в базу пишем "как есть", из базы читаем "как надо". https://php.net/manual/ru/faq.passwords
Я уже третий раз пишу про бинд --- Добавлено --- А в php 7, придумали какую-то новую функцию для хеширования, только не помню какую --- Добавлено --- Нашёл, это Argon2
Вижу прям дикое обучения человека идет) Кнутом и ремнем. Не забывай у пользователя может быть и уникальный email. А там уже восстановление пароля, авторизация по емаилу и паролю одновременно.
Не не, почта, восстановления, одноразовые ссылки, это вот все отдельный феншуй и пока рано. --- Добавлено --- Человек лучше всего учится на своих ошибках, когда самостоятельно их осознает и понимает причину, пусть даже через наводящие вопросы, но главное расшевелить. У парня это явно получается. Параллельно это развивает правильный подход к решению задач - исходить всегда от необходимого, а не наугад, отдавать себе отчет в том, что делаешь, спрашивать себя "а не занимаюсь ли я сейчас какой-то хренью бесполезной?". Оч полезные вещи.
Да понимаю сам в начале какой только фигней не занимался. Хотя до этого помогло то что учил логику, раньше удалось понять что творю фигню. Да и без наставника, не-не. Правильно наставника! тяжело разобраться, куча ошибок совершать будет, у самого не было и досихпор тврою фигню бывает. Да что мелочу, часто бывает.