Как быстро освоить PHP

Нет смысла, если не для вывода в консоль или лог.

 

Исходный код нет смысла причесывать. Браузеры умеют делать это постфактум при просмотре, DOM-дерево в отладчике и так всегда красивое, плюс можно копипастить код из ответа сервера в IDE и там применять автоформатирование. Как ни крути, отдавать браузеру символы переноса не нужно.

 

Ну хотя я это знаю, я не ставлю их удаление специально из HTML, мне кажется, сейчас это не сильно много смысла имеет. У меня они есть не потому, что я их специально вывожу, а потому что я выключаю режим PHP

 

Ну, я тоже их не выпиливаю, если они естественным путем образовались. Если где-то есть HTML, то в нем и отступы есть, и переносы, но это имеет свой смысл - так проще с ним работать в IDE. А вот добавлять специально переносы там, где смысла в них нет не нужно. Это, наверное, более правильная формулировка. Хотя, по-хорошему, советуют весь отдаваемый HTML минифицировать. Но это уже от ситуации плясать надо.

 

Открыл видео. Увидел, "экспертное видео" с Brakets в качестве IDE. Закрыл видео.

 

Не надо менять значения кнопок (хотя ничего сложного), просто - пользователь залогинился, вывелись другие кнопки

А по-русски? И главное, как это всё соотносится с задачей суриката?

 

Что это должно дать?
--- Добавлено ---

Ну так там же будет отправка формы, с последующей перезагрузкой страницы, верно? Вот ты эти данные прими, и, если все ок и пользователь залогинился, ты отдавай новую страницу. С новыми кнопками. "Меняется" - это то, что видит пользователь, а не то, что прям интерактивно должно на странице меняться. В задании стоит отдельным пунктом ограничение на использование JS. Оно тоже не просто так. Если ты начал загоняться и видишь решение, для которого нужен код на клиенте, то, в данном случае, это решение неправильное. Ищи другое.

 

Ну из первого, что бросается в глаза - пароль светишь даже в куках. Нафига? Во-первых, там не было задания на галочку "оставаться в системе", а во-вторых, это тоже не делается через засвечивание пароля в куках

 

То есть ты настолько самоуверен, что твои админские куки никогда не сопрут? )))

 

Галочка "Оставаться в системе" реализуется генерацией случайного токена. Этот токен записывается в базу данный, ассоциированный с id пользователя, и в куки.
--- Добавлено ---
Хешь пароля тоже светить не стоит. Хотя с использованием современных методов разгадать его очень трудно, но вдруг у кого-то таки получится.

 

а если пойти дальше и постараться предотвратить атаку по вермени, то в базу надо писать случайный идентификатор токена, и токен. В бд писать идентификатор токена и токен. Выборку делать по идентификатору, а сравнивать значение токена постоянной по времени сравнивалкой. Иначе можно статистически анализируя задержки выборки подобрать.

А если пойти ещё дальше, то не стоит хранить в базе идентификатор в открытом виде, ведь иначе тот, кто получит доступ к бд, сможет зайти под любым запомненым юзером. Нужно посчитать хеш пароля функцией password_hash(), и уже его сохранять в базу. Проверять как пароль.

 

1) Про пароль в куке уже было все сказано, так делать не надо. Но что еще не надо делать - так это хранить пароль в сессии. Даже хэш. Зачем? Каждый раз аутентификацию проводить? Проще в той же сессии поставить флаг, мол, юзер вошел, все ок, права такие-то.

2)

PHP:

1. spl_autoload_register(function ($class)
2. {
3.     $array_paths = array(
4.         '/models/',
5.         '/components/'
6.     );
7.     foreach ($array_paths as $path) {
8.         $path = ROOT . $path . $class . '.php';
9.         if (is_file($path)) {
10.             include_once $path;
11.         }
12.     }
13. });

Я, в общем, понимаю логику, но перебирать подряд все возможные пути, до тех пор пока не наткнемся на файлик - это не самое лучшее решение, как мне кажется. У меня, к примеру, архитектура такова, что каждый модуль хранится в папке...с именем модуля. И класс, который этот модуль реализует, тоже называется так же. При этом используется парадигма "все есть модуль". В итоге, если надо дернуть, хз, модуль "builder", я просто дергаю, грубо, "/modules/builder/main.php"
Это решение уровня архитектуры. Еще иногда практикуется добавление в имя класса постфикса, определяющего его тип, чтобы по постфиксу определять путь. Еще можно отдельно в системе хранить массив зарегистрированных в системе классов и путей к ним. И в автолоаде просто дергать путь из такого массива. Вариантов много. Стучаться же по каталогам с вопросом "а такой-то файл тут живет, не?" - спорное решение.

3)

PHP:

1. $params = include($paramsPath);

Вот так цеплять что либо вообще нежелательно. Использование include в таком ключе это экзотика и костыль сродни goto. В итоге получается какой-то недовызов недофункции. Include лучше использовать по назначению - для линковки кода. В твом случае, чем возвращать таким образом массив, правильнее было бы описать конфиг в виде статического класса и обращаться к его свойствам. Да и само по себе такое решение чище.

4) В логауте:

PHP:

1. header('Location: /auth');
2.         die;
3.         return true;

Ты уж определись IDE бы сразу на такой код ругнулась, потому что строчка с ретурном это "недостижимый код".

5)

PHP:

1. $query = "SELECT * FROM users WHERE login = '$this->login'";
2. $query = $db->prepare($query);
3. $query->execute();

SQL-инъекция. И дальше везде, где юзаешь БД, у тебя дыры. То есть, ты, конечно, используешь PDO->prepare(), но от этого нет никакого толка. Как работает prepare? Что ты подготовил в этом запросе? И как ты использовал эту подготовку? Ничего и никак. Перечитай еще раз доку.

6) Ты в одной функции посылаешь запрос по всем полям users, чтобы узнать, существует ли такой логин. Потом в другой функции посылаешь запрос с теми же условиями к той же users, но только по полю password, чтобы узнать, какой у него был пароль. При том, что ты его и так вытащил в первом запросе, если тот оказался удачным. Так почему бы просто не тянуть все одним запросом?

7)

PHP:

1. if($this->loginExists($this->login, $error_array)) {
2.             //    Проверяем соответствие пароля
3.             $this->passwordMatches($this->login, $this->password_hash, $error_array);
4.             if(empty($error_array)) {
5.                 return true;
6.             }
7.             else {
8.                 return false;
9.             }
10.         }

Почему бы просто не поставить вызовы проверяющих функций в одно условие через && ?

8) Проверка на занятость логина тоже идет через select. Почему бы на уровне базы не сделать поле с логином уникальным, и, при попытке регистрации, просто не отдавать базе запрос на запись нового логина? Вернет окей, значит все хорошо. Вернет ошибку нарушения уникальности - упс, логин занят. Это же не ошибка синтаксиса. Этого бояться не надо. Вполне нормальная практика.

9) Бабах:

PHP:

1. $db = Db::GetConnection();
2.             $query = "INSERT INTO users (login, password, birth_date) VALUES (:login, :password, :birth_date)";
3.             //    Подготавливаем запрос. В документации написано, что этот метод защищает от SQL-инъекций
4.             $query = $db->prepare($query);
5.             $query->bindParam(':login', $this->login);

А тут ты как будто бы правильно используешь подготовку, но, почему-то, только на две трети. Странно, почему ты до этого так не делал. Но и странно, почему препейришь 3 параметра, а биндишь два.

10)

PHP:

1. public static function months()
2.     {
3.         //    вывод месяцев в <select>
4.         return array(Январь, Февраль, Март, Апрель, Май, Июнь, Июль, Август, Сентябрь, Октябрь, Ноябрь, Декабрь);
5.     }

Как-то странно это видеть в классе, отвечающем не за построение GUI. У тебя же есть отдельно вьюхи, прописал бы там

Вердикт: в основном, на самом деле, к коду только придирки. Из фатальных недочетов только проблемы с безопасностью работы БД и хранение паролей в куках. В открытом виде.. Это вообще не круто.

В остальном, код аккуратный, логичный, последовательный, хоть и имеет место оверинжиниринг для такой простой задачки. Вангую, что ты раньше писал на яве или шарпиках.

Теперь по верстке... На дворе 2017 год. Верстать таблицами не круто уже лет 15 как. Таблицы - это элемент для подачи табличных данных, а не для выравнивания разметки. Таблицы в качестве макета это плохо. Очень плохо. Ну и ничего не говорилось про два поля ввода для паролей. Говорилось не просто так. Это лишняя мишура, она тут просто не нужна. Но это не принципиально. А вот от таблиц надо уходить.