Comments 113
$db->CheckLogin($_POST['login'],$_POST['password']);
// ...
function CheckLogin($login,$md5pass)
{
$STH=$this->db->query("select password from users where email='$login'");
}
и вы еще беспокоитесь о MITM? Как можно использовать PHP::PDO, но игнорировать preparedStatement? А что будет, если юзер в $_POST['login'] забьет нечто подобное:
script.php?login=0'+union+drop+table+users+--+
Ну и далее:
strcmp($md5pass,$pass)==0
почему сравнение используете без типа? Вроде как strcmp может вернуть -1 0 1 и только… Вы ожидаете false и '0'?
А что происходит тут? Зачем вы подключили целую jquery?
//Обновляем страницу
echo "<script src="js/jquery.min.js"></script>";
echo " <script>
$( document ).ready(function() {
location.reload();
});
</script> ";
window.location.reload() вызывается без всяких там $(document).ready(), это вполне себе стандартная javascript фу-ия еще со времен царя гороха… Да и вообще, если вы уже пишите обработчик на php, то почему не используете header(«Refresh:0»);…
И таких огрехов по коду достаточно. Вам следовало бы подготовится немного получше, перед публикацией подобной статьи, хабр все же не gist.github.com…
if(!isset($_SESSION['uniq'])||$_SESSION['uniq']=='')
$_SESSION['uniq']=uniqid();
Нет фигурных скобок. Минус балл.
require_once('engine.php');
Использование относительного пути — минус балл. Неиспользование composer — еще минус балл.
У вас уже «двойка», продолжаем.
$engine = new Template("tpl/");
Еще один относительный путь. Не говоря уж о том, что папка, где находятся шаблоны — не зависимость для шаблонизатора. Впрочем, вряд ли вы вообще понимаете слово «зависимость».
require_once('libs/mysql.php');
Господи, можно я не видел этого?
$db=new Database_Module();
...
$db->CheckLogin();
Полное наплевательство на стандарты стиля кода. Еще минус балл. У вас уже «кол».
function CheckLogin();
...
$STH=...
Ноль.
echo "<script src="js/jquery.min.js"></script>";
Вы это вообще серьезно?
P.S. Как там дела, в 2001 году?
по psr обязательны.
class A
{
}
if (true) {
}
вот эту клоунаду я никогда не пойму
После ключевого слова class и до фигурных скобок возможны еще ключевые слова: extends, implements. Поэтому скобку пишем сразу на новой строке, чтобы не дёргать ее потом туда-сюда.
После условия в if уже ничего не может быть, кроме фигурной скобки. Поэтому пишем ее на той же строке, чтобы случайно ничего не написать между условием и "}".
Всё логично.
После условия в if может быть и одно выражение на той же строке.
Вам уже прозрачно намекали, что в промышленном коде такое невозможно и обычно приводит к выпиливанию из команды, если вы будете продолжать настаивать на своём праве не соблюдать общепринятые стандарты.
Зачем вообще обсуждать скобки и пробелы? Не нравится подход PSR — не пишите на PHP публичный код, делайте свои домашние странички, где никто вас не упрекнёт за отсутствие скобок. Хотите выкладывать свой код в паблик — будьте любезны соблюдать публичные стандарты.
Вам не кажется такой подход логичным?
Проблема в том, что этот бред по каким-то причинам стал стандартом. Общепринятые — значит, что с ним согласны больше 50% программистов? Но что если больше 50% программистов — говнокодеры?Эти стандарты принимала довольно большая группа компетентных разработчиков, пишущих фреймворки и библиотеки.
Вам уже прозрачно намекали, что в промышленном коде такое невозможно и обычно приводит к выпиливанию из команды, если вы будете продолжать настаивать на своём праве не соблюдать общепринятые стандарты.
северокорейская компания?
все погибнут от:
if ($flag)
throw new Exception();
?
Не холивара ради, но код без скобок больше подвержен ошибкам при изменении. Надо всегда держать в голове "если там одно действие, то добавить скобки".
В моей практике было несколько случаев, когда при изменении кода, забывали добавить скобки. Отловить ошибку иногда бывает очень сложно.
Главный императив разработки ПО — управление сложностью. Я думаю, что в эту сложность можно вкладывать и сложность поддержки. Чем меньше лишних условий, не относящихся к цели модифицирования кода, требуется учесть, тем лучше. Если я меняю ветку if, я не хочу усложнять себе задачу, проверяя наличие скобок.
- Защита от выстрела в ногу. Сюда относится правило «всегда оборачивать тело условия в фигурные скобки, даже если там одно выражение». В худшем случае вы потратите в файле на две строки больше. Но файлы безразмерные, а строки в них бесплатные. Зато вы гарантированно избежите проблем в будущем, а в качестве бонуса получите более понятные дифы в коммитах.
- Вкусовщина. «Табы vs пробелы», «где и сколько пробелов ставить» и т.п. Она нужна, чтобы избавить нас от впадания в bikeshedding. Да, можно долго об этом спорить и что-то кому-то доказывать, но зачем? В конечном итоге никому пользы это не принесёт и никакого влияния на код не окажет. Я когда-то тоже часами настраивал пробелы, скобочки и переносы в редакторе для автоформатирования. А потом нажал там волшебную кнопочку «использовать PSR» и сэкономил себе кучу энергии и времени.
она просто занимает лишнюю строку.
Более того — неудобно сворачивается в редакторах.
if (true)
{
}
1. потому что так проще глазами читать код
2. потому что одинаково с class
Да и к тому же:
После условия в if уже ничего не может быть, кроме фигурной скобки. Поэтому пишем ее на той же строке, чтобы случайно ничего не написать между условием и "}".
Случайно можно написать все что что угодно и где угодно
$f = function () use ($a) {
}
function B
{
}
Почему везде по разному? Я тут ничего логического не вижу. Что можно случайно не написать или написать после объявления функции?
По этому пишу всегда и везде:
{
}
Я предпочитаю всегда писать открывающую фигурную скобку на той же строке, а закрывающую — всегда оставлять на строке в одиночестве. По простой причине — привычные мне редакторы показывают такую конструкцию в свёрнутом виде лучше, чем другие варианты оформления кода.
П.С. Я на PHP не пишу, может, пхпшники другие редакторы используют.
PHP, как и Go (ну и в Java уже исторически сложилось) — это те языки, где общественностью принят один единый стандарт. Ныне ещё JS потихоньку подбирается к этой стадии...
В любом случае, я хочу донести простую мысль: PHP — это не тот язык, где дозволяется/поощряется отсебятина на уровне опенсорсных или коммерческих проектов.
TL;DR; Если X является частью интерфейса — перенос скобочек нужен, если частью тела функции/метода — нет.
Подробнее:
1а) В одном случае декларация статической структуры (сборка на уровне компиляции)
1б) В другом динамической (на уровне рантайма)
2а) Методы реализуют интерфейс (подразумевается семантический, а не кейворд-структура) класса, содержат докблоки и визуально отделяются этой отбивкой.
2б) Анонимочки же не предоставляют интерфейс и визуально выглядят более "плотно", т.к. являются, либо аргументом другой функции/метода, либо частью тела функции/метода.
P.S. Код, который оформлен по PSR позволяет на порядки быстрее ориентироваться в интерфейсе структур. И это вполне логичное утверждение.
Кучка каких-то мутных личностей решила за весь мир кому как можно жить?
писать по PSR так же необязательно, как писать поддерживаемый, легко читаемый код или пользоваться лучшими практиками, придуманными какими-то мутными личностями.
Вы культ самолётников навязываете тут, а не практики применяете.
Последнее время развелась куча «диванных Системных архитекторов», недавно закончивших курсы/школы программирования, и минусующих только за несоблюдение каких-то стандартов )
Но, лично для меня, «карма на хабре», давно не является показателем компетентности разработчика.
Именно из-за таких ситуаций.
P.S. Хотя, что это я, вам там уже всё подробно объяснили.
А вот вы свои минуса заработали своим хамством, а не точкой зрения, отличной от большинства, тут у меня никаких сомнений.
<input id="hidpass" type=hidden name="password" value='' >
-1
В одной строке вариант написания атрибутов с одной кавычкой (value=''), с двумя (name=«password») и вообще без них (type=hidden)
Вы никак минусами не отмените того факта, что код в статье ужасен. Он не просто ужасен — он недопустим, даже начинающие студенты не имеют право делать такие грубые ошибки. И вам это уже сказали много раз десятки людей. Вы же не только себя на хабре уничтожили, вы всех php-программистов подводите, заставляя тех, кто читает вашу статью думать, что они все такие!
Правильно где-то выше написали — это диверсия какая-то.
Но по моему опыту: «Кто умеет делает — кто не умеет учит».
1. Изначально начали Вы, ставить «двойки и колы» за статью, в которой написано, что код просто для наглядности.
2. Да, главное что код работает. Это и отличает разработчика от кодера.
Кодеров пруд пруди, после таких вот «учителей». Они «винитки в машине» и не имеют никакой ценности. Так, Личинка разработчика…
Разработчик же понимает, что стоит за этими стандартами, из чего они следуют и почему так лучше в данной ситуации. И понимает он это исходя из собственного опыта, а не потому, что так написано в стандарте, принятом какими-то чуваками.
На счёт стандартов — это не больше, чем рекомендации.
То же самое относится и к «публичности кода», как писали ниже.
Грустно, когда люди, вместо обсуждения твоего подхода, фанатично кричат о соблюдении PSR.
Ну и избитая шутка на счёт «существуют 14 стандартов… нужно сделать один универсальный стандарт...» Тут тоже имеет место быть.
Я, как системный архитектор, большой международной компании, Вас бы на работу не взял)
Я не знаю, конечно, насколько вы хороший «учитель».
Дальше вы могли бы ничего не писать.
Но по существу, как я вижу, аргументов у Вас нет.
В вашем комментарии я просто не вижу ничего, что требовало бы обсуждения. Просто некий текст, набор слов и предложений. Я прочёл этот текст, спасибо вам большое.
Повода для дискуссии не вижу.
На счёт стандартов — это не больше, чем рекомендации.
В любом случае, в 2017ом году игнорирование этих рекомендаций говорит о том, что автор — совсем зелёный новичок и даже если это не так, я почти уверен, что большинство крайне скептически будут относиться к коду-отсебятине.
Всё же "рекомендации" они де-юре, а де-факто, нынче — "стандарт".
Рекомендации — это именно рекомендации, а не догма.
Это не «стандарт» или что-то ещё.
В любом году.
Это как говорить, что художник, который пишет картину, должен делать мазки только слева направо, не длиннее 2-х сантиметров. Ибо в 2017 году это «стандарт».
Впрочем, буду рад ошибаться.
Смотрите.
Первое: собираются разработчики популярных фреймворков, библиотек и самого PHP и признают, что околоязыка — полный бардак.
Спорить с этим бессмысленно — действительно, до php-fig бардак был такого количества и качества, что фактически мешал развитию и языка и экосистемы.
Кстати, надо отметить, что никто не мешает любому из нас войти в php-fig в любой момент. Это открытая организация (если ее можно вообще назвать таковой).
Второе: члены php-fig договариваются, что будут стараться личными и коллективными усилиями уменьшать энтропию в околоPHP. Что они начинают делать? Вырабатывать стандарты: предлагать черновики, обосновывать, дорабатывать, голосовать, принимать и реализовывать принятое в своих фреймворках и библиотеках.
И наконец многолетняя работа приводит к результатам: в мире профессионального программирования на PHP уходят в прошлое споры типа «табы vs. пробелы», закрывается дискуссия на тему «как делать автозагрузку», начинают работать по единому интерфейсу все приличные логгеры (SOLID, мать её, Лисков!) и библиотеки кэширование и так далее и тому подобное.
Всем от этого становится хорошо и приятно. Стандарты приводят к возможности пользоваться тем же composer, к появлению немонолитных фреймворков и множества полезных библиотек.
Вопрос лично вам: что вы видите плохого в этом процессе? Почему вы так резко против действительно общепринятых уже действительно стандартов?
P.S. Аргумент о том, что R — это Recommedations, слишком дешёвый. RFC — это тоже всего лишь Request, однако этот факт никого не заботит.
Это правильно и полезно.
Я против фанатичного навязывания «общепринятых» «стандартов» всем подряд.
С одной стороны программирование (а не кодинг) — это творчество. И если вы растите разработчиков — не нужно их ограничивать или стандартизировать.
А вот если вы растите «винтики» — тогда все правильно. Им не нужно понимание работы в целом. Главное, что бы при смене, новый винтик не нужно было переобучать.
С другой стороны, любой язык программирования — это инструмент, в первую очередь.
И скальпелем можно резать торт. Удобно ли это и целесообразно, вопрос второй.
Вопрос в том, что это делать можно.
А вы утверждаете, что по «общепринятым стандартам» скальпелем можно резать только человеков и только специально обученным для этого людям.
Это как говорить, что велосипеды должны быть только с одинакового размера колесами. Одинаковой шириной покрышек. Это «общепринятый стандарт». Все остальное «околовелосипедное»… что производители велосипедов собрались, и договорились о стандартах.
Да, это добавило универсальности, несомненно. Это хорошо для продукта, но не для инструмента.
И вы, как разработчик, вполне можете создать свой велосипед, который будет не хуже, а возможно и лучше серийных решений.
Программирование — это в первую очередь творчество. Если ты разработчик конечно)
Я не увидел в ваших аргументах, почему именно в этой статье, где код просто для наглядности, необходимо строгое соблюдение «общепринятых стандартов».
Потому, что вам сложно его читать?)
Так может проблема не в коде?)
P.S. Эйнштейн, по моему говорил, что только глупцам нужен порядок…
Я не согласен с вами только в одном моменте. Правда, этот момент принципиален настолько, что приводит к полной невозможности согласиться со всеми вашими выводами.
Программирование — не творчество.
И не будет им никогда для 95% программистов.
Это банальное ремесло, которое нужно освоить, чтобы зарабатывать себе на жизнь. Причём по моему глубокому убеждению и профессиональному мнению, изучать программирование нужно в специализированных ПТУ, а не в вузах.
Вы можете себе представить сварщика или токаря, который после ПТУ приходит на производство и говорит «да вертел я вокруг своей оси все ваши ГОСТы и типоразмеры, я творец, я так вижу, я буду точить дюймовую резьбу, если на чертеже указана метрическая!»
Как долго он продержится на заводе?
Токарь или фрезеровщик получают право на творчество лишь после долгих лет у станка, проведенных за вытачиванием стандартных изделий. Изо дня в день. 8 часов, 5 дней в неделю.
С чего вы взяли, что у программистов по-другому?
Строгое соблюдение стандартов необходимо начинающим, чтобы в последствии не было горького разочарования в профессии. Чтобы не было обид на тему «я — творец, а меня не так поняли». Да так тебя поняли, так. Ты не творец, парень, ты просто кое-какер…
Я говорю о том, что нужно выращивать, специалистов, которые могут создавать что-то новое. Для этого не нужно никаких ограничений.
Вы говорите о том, что нужно создавать винтики (кодеров).
Ну и конечно 95% из них не будут разработчиками. Кто-то просто на это не способен.
А у кого-то вы убили стандартизацией индивидуальность.
Музыканты то же бывают разные. Для кого-то это ремесло, и больше чем играть в ресторанах и на свадьбах, они не могут.
Я же говорю о том что, нужно помогать творцам развиваться.
На вашем примере с токарем… он делает продукт.
И делает его по заранее заданным техническим параметрам.
Но это не значит, что все токари должны делать все детали по «общепринятым стандартам». Вам нужно всего лишь объяснить им для чего эти стандарты нужны и какие они бывают.
И снова таки. Токарь следует чертежу, который для него разработал инженер.
И этот инженер не обязан фанатично следовать стандартам.
Важно, что бы его деталь «работала»
Это все, если мы говорим про продукт, который токарь делает на заводе.
Когда же токарь делает что-то для себя ( как в этой статье ), не важно как и где он это будет использовать…
Он волен следовать чему угодно. Только ему решать. И тут абсолютно не важно насколько много у него опыта. И так же, не следование «стандартам» не делает его деталь хуже.
п.с. Готов получить еще порцию минусов за комментарий.
А у кого-то вы убили стандартизацией индивидуальность.
Вы всё же не удержались, чтобы не сказать какую-то пакость… Ничем не обоснованную пакость с переходом на личности. Жаль.
Но это не значит, что все токари должны делать все детали по «общепринятым стандартам».
Услышьте меня. Чтобы начать что-то делать не по стандарту, чтобы предлагать изменения в стандарты или их отмену — сначала нужно научиться делать по стандарту и делать хорошо.
Именно этим и отличается творческий подход от кое-какерства, которые вы пропагандируете.
Делай хорошо — и хорошо будет. Хреново получилось — не стандарты виноваты, а ты хреново делаешь!
А у кого-то вы убили стандартизацией индивидуальность.
Это из личного опыта. Я наблюдал это много раз. Стандартизацией убивается индивидуальность.
Я не ставлю своей целью как-то вас задеть.
Я говорю вам, что вы учите людей клеить обои. Мотивируя это тем, что это ремесло, надо зарабатывать на жизнь, и все равно 95% из них больше ничего не светит.
Учите, что в 2017 году есть стандарты и обои нужно клеить только вертикально, только с перехлестом в 5 мм. и если обои отклеились, что виноваты не стандарты, а просто хреново приклеили.
Я говорю вам, как человек, разработавший не один дом, от идеи до конечного проекта, решавший не раз все инженерные тонкости и дома которого стоят уже не один год… что обои можно клеить и горизонтально. И даже под углом в 45 градусов к полу.
А можно и вообще без обоев)
Это из личного опыта. Я наблюдал это много раз. Стандартизацией убивается индивидуальность.
Так и пишите тогда. И не надо извиняться и говорить, что не хотели задеть — задели. И хотели.
Я говорю вам, что вы учите людей клеить обои. Мотивируя это тем, что это ремесло, надо зарабатывать на жизнь, и все равно 95% из них больше ничего не светит.
Учите, что в 2017 году есть стандарты и обои нужно клеить только вертикально, только с перехлестом в 5 мм. и если обои отклеились, что виноваты не стандарты, а просто хреново приклеили.
Совершенно верно.
И пока студент не поклеит тысячу квадратных метров обоев я его близко даже к «творчеству» не допущу. Иначе результат «творчества» будет жалок. Что мы и наблюдаем в обсуждаемой статье.
Банальный пример:
Допустим человек не изобрел велосипед и до сих пор для него средство передвижения это конь.
А какой то умник взял и придумал велосипед с квадратными колесами.
Тут вариантов 2.
1) Все его засмеют и скажут, что передвигаться на нем крайне тяжело хоть он и передвигается, и передвигается как конь (скачками), и вообще нафиг нам велосипед ведь конь же передвигается. Лучше займитесь селекцией и выведите породу которая быстрее скачет и плавнее.
2)Более компетентные в физике люди скажут: Блин а задумка интересная. просто можно бы колеса ему сделать круглыми. Тогда и ехать легче и сена не просит.
В обоих случаях будет прогресс. В первом будут лучше кони, во втором будут лучше и коне и велосипеды.
Тут нет неправильного варианта, просто второй немного лучше так как прогресс будет быстрее.
Но если вы не можете прочитать/понять работающий код, то проблема не в коде)
ну а мы неотесанные современники
хорошо что хоть такое допущение принимаешь.
О! да тут помимо мании величия (которая была видна в комментах под прошлыми статьями) еще и вера в заговоры. Шикарно!)
Никто не запрещает же не использовать то, что не нравится. А если нет другого выхода, то надо радоваться тому, что есть выход хоть и кривой. Иначе его вообще бы не было. И надо искать творца, который не факт, что сотворит по стандарту :)
И еще один минус в том, что стандарты отбивают у «убитых стандартизацией индивидуальностей» желание мыслить. Так как человек — это существо ленивое. Ему дали что-то стандартное, а он и рад. Ведь думать не придется. И тут появится «творец» который «сотворит» что-то с уязвимостью в стандарте и все стандартно летят, так как стандартно делали копи паст и не вникали что, где и как.
Когда вы проходили по «аду» того творца, уверен, что вы сообщали начальству о том что там «ад», и вам 100 пудов предложили «охладить ад». И как поступили вы? Сотворили рай? Судя по тому что вы написали
убитые стандартизацией индивидуальности будут все это добро поддерживать и рефакторить, пытаясь понять что имел ввиду творец, оказалось кишка тонка. И пришлось вам бедным все это добро поддерживать и рефакторить.
Как то так.
"Убитые стандартизацией индивидуальности", "творец". Не много на себя берете?
И я не извинялся. Ибо изначально не ставил своей целью вас задеть)
Я говорю абстрактно, про «таких педагогов» в целом.
Считаете и себя таким — ваше дело)
Результат творчества, в данной статье, не плохой, рабочий и имеет место для применения. Что уже было отмечено не только мной.
То, что за отсутствием следования каким-то стандартам кода, вы не увидели самого алгоритма — грустно и само по себе говорит о многом, в очередной раз подтверждая выражение «кто умеет — делает, кто не умеет — учит».
И пока студент не поклеит тысячу квадратных метров обоев я его близко даже к «творчеству» не допущу. Иначе результат «творчества» будет жалок. Что мы и наблюдаем в обсуждаемой статье.
Ну а это как бы совсем «зашквар» )
P.S. Я так и не услышал, от вас, ни единого аргумента, почему код именно в этой статье должен следовать каким-либо «общепринятым стандартам».
Почему код именно в этой статье должен следовать каким-либо «общепринятым стандартам»?
На счёт «общепринятости», читаемости и стандартности я уже объяснил)
примерно по той же причине, что описана в этой статье https://habrahabr.ru/post/183374/
чтобы код был принят сообществом, желательно — в данном случае обязательно, т.к. код не уникален, и может быть отторгнут сообществом — соответствовать общепринятым стандартом. Когда 95% окружающего тебя кода (все топовые библиотеки гитхаба, принятый в компании кодстайл итд) соответствует psr, то несоответствующий код вызывает отторжение.
Потому что так общепринято и стандартно.
В этой "хабравложенности" я вообще потерялся кто кому отвечал. Тяжело воспринимать. Так что оставлю и свой коммент в ветке про "стандартизации".
Существует мнение, что "творить" надо кодом, а не средствами его форматирования. И кажется это вполне укладывается в принцип "используйте PSR-1, PSR-2 и PSR-12".
А ещё стоит помнить один нюанс — используя язык X, как бы не нравилось, используй общепринятые в этом языке подходы, иначе не публикуй и не показывай никому код. Пока такой подход мне не мешал "творить", чего и вам желаю.
Результат творчества, в данной статье, не плохой, рабочий и имеет место для применения. Что уже было отмечено не только мной.
Проблема еще и в том, что «результат творчества» не несет никакой новизны, как я уже отметил ниже, по этому смотрят на реализацию, которая в изначальном варианте статьи была совсем ужасная, сейчас стало немного лучше. Ну и выкладывая код, содержащий грубейшие ошибки (sql injection в первой версии когда в статье), следует быть готовым к тому, что к нему прицепятся.
Я, к примеру, пока не встречал таких реализаций.
На счёт «грубейших ошибок» уже говорили… код для наглядности.
И снова таки. Токарь следует чертежу, который для него разработал инженер.
И этот инженер не обязан фанатично следовать стандартам.
Да, инженер может в процессе работы делать что угодно и как угодно, но когда он завершит творческую часть своей работы, то ему нужно будет конечный результат этой работы — чертеж — оформить в соответствии со стандартами, по ГОСТу. В противном случае его либо развернет контролер, либо, если контролера нет или он проглядел ошибки оформления, может случится авария из-за того, что токарь неправильно поймет и сделает деталь не так, как рассчитывал инженер.
На мой взгляд со стандартами (рекомендациями) по написанию кода все тоже самое, у себя вы можете делать как угодно — следовать «общепринятым» стандартам, придумать свои или вообще писать как попало, но когда выкладываете код туда, где его будут видеть и читать другие люди, то следует привести его к стандартам того места, куда его выкладываете. Ведь наверняка у вас на работе, если вы не в одиночку ведете проект, есть какой-то code-style. Ну а в общих репозиториях PHP это, обычно psr. И я, честно говоря, не вижу в этом беды, если вам не нравятся эти стандарты, то современные IDE (Intellij Idea и основанные на ней точно, подозреваю что и большая часть других) позволяют настроить автоматическое преобразование кода к тому виду, который вам удобен, сразу после pull и обратное преобразование перед push.
Это как говорить, что художник, который пишет картину, должен делать мазки только слева направо, не длиннее 2-х сантиметров. Ибо в 2017 году это «стандарт».
мазки — это творчество. требования к оформлению кода — это технические детали.
Ну и ценность данного метода в плане безопасности почти нулевая.
Зачем изобретать велосипед, когда есть HTTP Digest Auth? https://ru.m.wikipedia.org/wiki/Дайджест-аутентификация
Я вот понять не могу — это диверсия такая?? Уже которая статья на Хабре (кроме дайджеста) с тэгом "php" — это лютый невообразимый кошмар.
Признайтесь, вы специально это делаете, чтобы дать возможность уверенно писать, что "php-программисты тупые уроды"???
И это тоже есть (Digest), только никем не используется. Подозреваю, если покопаться, то все подобные методы окажутся в чём-то небезопасными.
Например, в алгоритме из данного поста знать пароль для авторизации вообще не нужно, достаточно знать md5 пароля. Который хранится как есть в базе и который можно оттуда прочитать любым select'ом (кстати, напомню, в первой версии поста была SQL-инъекция).
Если нужно получить именно чистый пароль, то подобрать его по md5 не составит труда, если он короткий (а у большинства пользователей пароли будут короткие).
У одних и тех же паролей будет один и тот же md5, так что, получив доступ к базе, мы сразу же сможем узнать, у каких пользователей стоят одни и те же пароли.
Короче, лучше просто прикрутить HTTPS и солить пароли в какие-нибудь bcrypt/scrypt/PBKDF2/Argon, так намного проще и безопаснее и надёжность проверена всеми кому не лень.
почему такой функциональности не реализовано в браузерах с завода
Это Вы про HTTPS?
UPD:
Опередили. Но удалять не буду.
Знакомьтесь: https://letsencrypt.org/ Под "некоторыми конторами" в данном случае выступают мозилла, хром, циско, фейсбук и прочие, чуть менее именитые заведения. "Самоподписывают" за бесплатно.
Форма авторизации с отправкой зашифрованного пароля