Теперь немного позанимаемся процессом публикации проекта на удалённом сервере так чтобы он был доступен с любого компьютера.

Но прежде озаботимся необходимостью защитить данные от неавторизованного доступа. Сейчас ваше приложение представляет собой что-то среднее между обычным многостраничным сайтом и админкой.

Было бы логично чтобы случайны пользователь не мог редактировать данные.

Для контроля доступа в приложениях принято использовать так называемую концепцию middleware. По сути это специальные обработчики который выполняется либо до непосредственной обработки запроса, либо после.

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

Давайте создадим базовый Middleware класс в папке framework

вот с таким содержимым

<?php

class BaseMiddleware {
    public function apply(BaseController $controller, array $context) {
        
    }
}

теперь идем в Router и сначала правим маршрут:

class Route {
    public string $route_regexp;
    public $controller; 
    public array $middlewareList = []; // добавил массив под middleware
    
    // метод с помощью которого будем добавлять обработчик
    public function middleware(BaseMiddleware $m) : Route {
        array_push($this->middlewareList, $m);
        return $this;
    }

    public function __construct($route_regexp, $controller)
    {
        // ...
    }
}

а теперь подкручиваем сам роутер:

class Router {
    // ...
    
    // перепиливаем функцию add таким образом
    // добавляем возвращаемый тип : Route 
    public function add($route_regexp, $controller) : Route {
        // создаем экземпляр маршрута
        $route = new Route("#^$route_regexp$#", $controller);
        array_push($this->routes, $route);
        
        // возвращаем как результат функции
        return $route;
    }

плюс переопределяем get_or_default:

class Router {
    // ...
    public function add($route_regexp, $controller) : Route {
        // ...
    }

    public function get_or_default($default_controller) {
        $url = $_SERVER["REQUEST_URI"];

        $path = parse_url($url, PHP_URL_PATH);

        $controller = $default_controller;
        $newRoute = null; // добавили переменную под маршрут

        $matches = [];
        foreach($this->routes as $route) {
            if (preg_match($route->route_regexp, $path, $matches)) {
                $controller = $route->controller;
                $newRoute = $route; // загоняем соответствующий url маршрут в переменную
                break;
            }
        }

        // ...

        // вызываем обработчики middleware, если такие есть
        if ($newRoute) {
            foreach ($newRoute->middlewareList as $m) {
                $m->apply($controllerInstance, []);
            }
        }

        return $controllerInstance->process_response();
    }

теперь добавим класс обработчик для проверки был ли пользователь авторизован. Для этого создадим папку middlewares и добавим в нее класс

загоним в него просто вывод сообщения, что необходимо авторизоваться

public function apply(BaseController $controller, array $context)
{
    echo "Авторизуйтесь пожалуйста";
}

и теперь подключим его во всех контроллерах в которых происходит некоторая манипуляция данными, у меня оказалось четыре таких контроллера:

и теперь попробуем их пооткрывать:

как видно теперь вверху выскакивает надпись. Давайте попробуем реализовать простейшую HTTP авторизацию, она делается с помощью указания специальных заголовков в запросе

class LoginRequiredMiddeware extends BaseMiddleware {
    public function apply(BaseController $controller, array $context)
    {
        // заводим переменные под правильный пароль
        $valid_user = "user";
        $valid_password = "12345";
        
        // берем значения которые введет пользователь
        $user = isset($_SERVER['PHP_AUTH_USER']) ? $_SERVER['PHP_AUTH_USER'] : '';
        $password = isset($_SERVER['PHP_AUTH_PW']) ? $_SERVER['PHP_AUTH_PW'] : '';
        
        // сверяем с корректными
        if ($valid_user != $user || $valid_password != $password) {
            // если не совпали, надо указать такой заголовок
            // именно по нему браузер поймет что надо показать окно для ввода юзера/пароля
            header('WWW-Authenticate: Basic realm="Space objects"');
            http_response_code(401); // ну и статус 401 -- Unauthorized, то есть неавторизован
            exit; // прерываем выполнение скрипта
        }
    }
}

получается такой вполне себе такой колхозный ограничитель неавторизованного доступа.

Теперь, когда у нас сайт более-менее защищен, рассмотрим процесс выкладки его на хостинг.

Я покажу как это сделать на примере хостинга jino потому что это самый бюджетный вариант с вполне приличным функционалом.

Идем на сайт https://jino.ru/ и кликаем создать аккаунт. У них кстати можно привязать акк к вк, гуглу, фб и не тратить лишнее время на придумывание паролей.

Я подключусь с гугла, потому что мой вк аккаунт уже привязан, в общем для чистоты эксперимента:

откроется стандартное окно для OAuth авторизации, в котором просто надо будет войти в свою учетную запись. После успешного входа увидите что-то в этом роде

тыкаем Войти как новый пользователь и нас переносит на панель управления

на ней тыкаем кнопку Хостинг

В принципе уже можно работать. У нас 10 дней тестового периода. Для поиграться нам хватит.

Если же вы захотите сохранить сайт на этом хостинге, то надо будет внести деньги на счет и отключить лишние услуги как на картинке (чтобы перейти на эту страницу надо нажать на кнопку услуги), то есть обведенные зеленым оставляется, обведенные красным выключаете

без пополненного счета он не даст это сделать

Разбираемся с техническим доменом

Тыкаем на кнопку файловый менеджер:

тут мы попадаем в папку на сервере куда будем загружать файлы нашего сайта. Заходим в папку domains

там будет еще одна папка, заходим и в нее, там лежит одинокий index.html файл

Джино по умолчанию создает для нас так называемы технический домен к которому можно привязать один сайт без необходимости покупать собственно настоящий домен.

Чтобы узнать адрес этого технического домена надо зайти сюда:

и увидеть его адрес

если зайти по этому адресу, то увидим следующий текст

на самом деле это просто содержимое файлика index.html который мы только что смотрели.

Возвращаемся обратно в файловый менеджер

кликаем на файл

и меняем содержимое body

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

и видим тот самый текст что мы только что загнали в файлик

можно сразу проверить работает ли у нас php, кликаем на файлик правой кнопкой мыши и выбираем переименовать

и меняем имя на index.php

и давайте во внутрь загоним что-то такое:

<!DOCTYPE html>
<html>
    <head>
        <meta http-equiv="content-type" content="text/html;charset=utf-8">
        <meta http-equiv="X-UA-Compatible" content="IE=edge">
        <title>Сайт в разработке</title>
    </head>
    <body>
        <pre>
        <?php print_r($_SERVER); ?>
        </pre>
    </body>
</html>

теперь открываем страницу технического домена и смотрим

Ура! Все работает! =)

Загружаем сайт на сервер

Вообще сайт на сервер можно загрузить через прямо через сайт. Можно первый раз прямо так и сделать.

Заливаем проект на сервер

И так, первое что надо сделать это упаковать папку с приложением в zip-архив. Паковать можно чем угодно, я, например, через 7z:

перетягиваем архив

распаковываем

причем папку указываем внутри папки domains

теперь в папке domains появится новая подпапка

Надо настроить ей и всем вложенным папкам права. Нажмите на нее правой кнопкой и выбирете

далее укажите такие значения

и нажмите сохранить.

Теперь можно зайти в папку. Собственно, теперь нам надо настроить технический домен чтобы он раздавал папку public из нашего проекта.

Идем в настройки вебсервера и тыкаем сюда

и выбираем путь к папке public

теперь надо пойти в папку public создать файлик .htaccess

и написать в него

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /index.php?path=$1 [NC,L,QSA]

и последнее чтобы видеть ошибки которые происходят с сервером, в начало index.php добавьте

error_reporting(E_ALL);
ini_set('display_errors', '1');

Разбираемся с autoload

открываем теперь и видим такую ошибку

тут написано, что не найден класс TwigBaseController, этот класс у нас должен подгружаться автоматически через autoload, давайте возьмем и прямо на сервере поправим файл framework/autoload.php

перезапускаем и смотрим:

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

мы в нашем коде явно прописываем обратный слеш, и так как мы работаем на винде у нас проблем не возникает:

но как быть, есть ли какое-то универсальное решение?

К счастью да, в PHP встроена специальная предопределенная константа DIRECTORY_SEPARATOR , просто подставим ее вместо \\

и в проекта в visual studio code тоже не забудьте.

Настраиваем подключение к БД

Перегружаем и видим новую ошибку

тут, уже идет жалоба на то что PDO не может подключится к базе данных. Сначала надо понять почему собственно это происходит.

Дело в том, что у вас на своем компе установлен mysql/mariadb с дефолтными настройками, например мы пароль вообще не указывали.

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

Давайте посмотрим эти настройки. Тыкаем вот сюда

и попадаем в управление базами данных, тыкаем создать базу данных

я назову ее spaceobjects

но на самом деле полное имя БД будет с префиксом вашего юзера, т.е. у меня имя будет j6600410_spaceobjects

давайте теперь зайдем в управление базами

и увидим уже знакомый нам phpMyAdmin

Как мы видим тут пустая база. Мы ее заполним чуть позже. А пока давайте попробуем настроить наш сайт, чтобы он подключался к правильной БД.

Сначала надо задать пароль юзеру. Тыкаем сюда

и тыкая на ключи справа создаем пароль

его надо сразу куда-нибудь сохранить.

Вообще по идее его можно загнать в index.php. Это конечно не совсем правильный подход, но давайте пока сделаем так. Идем в файловый менеджер, находим там файлик index.php

и прописываем там настройки подключения

заходим на страничку нашего сайта, и видим очередную ошибку

о том, что необходимая таблица в базе не найдена.

Создаем бэкап и загружаем его на сервер

Ну в принципе логично, у нас ведь БД пустая. Надо ее теперь как-нибудь заполнить. Можно конечно руками перетащить, записей то не много. Но сразу понятно, что это не вариант.

Специально для этих целей во все СУБД встроен механизм создания бэкапа базы, который позволяет сохранить состояние данных в файл, а потом этот файл развернуть на другой машине.

И так заходим в phpMyAdmin который подключен к базе на нашем компе http://localhost/phpMyAdmin/ и идем в экспорт

и скачивается файлик

если открыть файлик, то увидим SQL-скрипт, в котором есть команды для создания таблиц, а есть команды для заполнения данных

в общем теперь наша задача, зайти в phpMyAdmin на сайте jino и загнать туда этот скрипт.

Снова идем в управление MySQL

снова заходим в управление базами

тыкаем нашу базу, тыкаем Импорт и выбираем файл со скриптом

ну и скроллим вниз, затем тыкаем Вперед

увидим что-то такое:

теперь открываем сайт:

Ура! =) Только забыли убрать вывод в framework/autoload.php

вот теперь красота:

Теперь рассмотрим более прогрессивный способ работы с авторизацией, да и не только с ней: так называемую сессию.

Сессия это такие данные которые фиксируются за пользователем который заходит на наш сайт, и могут оставаться привязанными к нему даже после закрытия браузера. Могут, но как правило не остаются, и пропадают сразу после закрытия бразуера.

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

Как же это работает?

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

Это имя передается браузеру и браузер начинает это имя хранить. Хранит он его в тех самых куках про которые пишет каждый первый сайт:

Мы их еще разберем подробнее, но попозже.

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

Пробрасываем данные между страницами

Чтобы не сразу кидаться во все тяжкие и реализовывать авторизацию. Попробуем просто добавить поле для ввода, в которое можно будет что-то написать, и чтобы оно стало доступно на всех страницах.

Создадим сначала SetWelcomeController, которые пока просто будет перенаправлять пользователя на страницу с которой будет отправляться запрос

вот этот $_SERVER['HTTP_REFERER'] как раз хранит адрес такой страницы.

Теперь привяжем контроллер к роутеру:

$router->add("/set-welcome/", SetWelcomeController::class);

и добавим поле для ввода в навигацию

получится такое:

теперь у меня такая идея, я хочу туда что-то написать, и чтобы это что-то стало доступно сразу на всех страницах. Причем мне не надо будет ничего фиксировать в БД.

И так, активируем механизм сессии. Так как нам надо чтобы сессия была доступна с любой страницы, то править будем BaseController, на самом деле конечно это не очень хорошо. И сессию лучше делать через middleware, но и наш подход допустим.

Правим функцию process_response, добавляем строчку

в принципе все, механизм сессии активировался! =)

Как это проверить?

Открываем консольку и идем сюда

То есть в куках (а куки это просто встроенное в бразуер хранилище в виде словарика, где есть ключ и привязанное к нему значение), под ключем PHPSESSID лежит уникальный номер вашей сессии. Вы можете удалить эту строчку через Delete перегрузить страницу и там появится уже новый номер.

А как посмотреть файлик который привязывается к этой сессии? Сначала надо найти папку куда PHP сохраняет сессии. Для этого в laragon надо зайти в настройки php

и найти там ключ session.save_path

тут и будет указано где хранятся файлики с сессиями. Давайте зайдем в папку и найдем файлик, соответствующий нашей сессии:

если его открыть он будет пустой. Давайте в него что-нибудь запишем. Идем в SetWelcomeController и добавляем строчку:

<?php

class SetWelcomeController extends BaseController {
    public function get(array $context) {
        $_SESSION['welcome_message'] = $_GET['message']; // добавил
        
        $url = $_SERVER['HTTP_REFERER'];
        header("Location: $url");
        exit;
    }
}

а теперь попробуем чего-нибудь написать в наше новое поле для ввода и тыкнуть Enter

вроде ничего не произошло, но теперь если открыть файл сессии, то увидим в нем

то есть наше сообщение зафиксировалось и теперь доступно с любой страницы.

Давайте, например, будем выводить его на странице объектов. Идем в ObjectController добавляем переменную в контекст со значением из сессии

правим шаблон:

открываем любой объект и пробуем что-то писать:

Но всегда надо помнить, что сессия привязана к одному браузеру.

Например, если открыть эту же страницу в режиме инкогнито, то мы и вовсе получим ошибку

почему так? Потому что открытие страницы в режиме инкогнито равносильно запуску одноразового браузера, у которого чистая история и чистые куки.

То есть инкогнито браузер запрашивает уже новую сессию в которой значение $_SESSION['welcome_message'] еще не определено. А поэтому ключ не доступен.

Поэтому во избежание такой ошибки надо добавить проверку на существование ключа, вот так

$context["my_session_message"] = isset($_SESSION['welcome_message']) ? $_SESSION['welcome_message'] : "";

вот теперь ошибки нет

можно глянуть их куки:

и увидеть, что у них разные значения ключей.

В принципе мы можем подделать сессию если скопируем значения ключа

вообще, такой прием называется подделкой сессии и является одной из возможных атак на сайт =)

Хранение массивов в сессии

Кстати в сессии можно хранить не обязательно простые типы, навроде строк или цифр. Можно, например, хранить массивы. Для этого нам надо просто изначально ключ в сессии инициализировать пустым списком, как-то так:

подключаем в контроллере:

class ObjectController extends BaseSpaceTwigController {
    public $template = "__object.twig";

    public function getContext(): array
    {
        // ...

        // передаем в контекст список messages
        $context["messages"] = isset($_SESSION['messages']) ? $_SESSION['messages'] : "";

        return $context;
    }
}   

и теперь можно выводить в шаблоне

тестим:

Сохранение сессии после закрытия браузера

Кстати вы возможно заметили, что если закрыть и открыть браузер, то все что мы тут вводили теряется.

Почему так происходит? Потому что стандартное поведение сессии — это забыться по закрытию браузера. И на самом деле забывает сессию именно бразуер. Помните вот эту картинку

вот это идентификатор сессии который можно посмотреть в бразуере в куках, имеет определенное время жизни. Увидеть его можно в cтолбике Expire

значение Session означает что эта кука удалится по закрытию браузера. Но можно тыкнуть по значению два раза и ввести туда какую-нибудь дату в формате YYYY-MM-DD (например, 2021-12-31)

попробовать закрыть и открыть браузер, и убедиться, что значения теперь сохранились.

Но тут есть две проблемы, первая – не будем же мы заставлять пользователя лазить в куки и прописывать значения вручную. И вторая – хотя мы и установили время жизни куки с идентификатором сессии на конкретную дату, на сервере все равно стоит другое значение. Можно зайти в настройки

и найти там такое значение

которое означает что сессия будет считаться просроченной через 36000 секунд, то есть примерно через 10 часов. То есть это означает, что файлик с сессией будет удален на сервер не раньше, чем через 10 часов.

Но мы ж вроде в браузере посидели всего несколько минут закрыли-открыли, и данных уже нет. Как сделать так чтобы данные сохранились хотя бы на ближайшие 10 часов.

Для этого есть еще одна функция которая называется session_set_cookie_params с помощью него можно указать как долго браузер будет хранить идентификатор сессии. Давайте загоним туда эти самые 10 часов.

Идем в BaseController и добавляем перед session_start:

проверяем, только не забудьте открыть и закрыть браузер, чтобы старое значение PHPSESSID сбросилось. Получается так:

Можно теперь смело закрывать браузер и не бояться потерять значение

Реализация закрытия доступа ко всем страницам и авторизация

1. Сделать контроллер под страницу логина. То есть новый twig шаблон, на котором будет форма с двумя input полями под юзер и пароль
2. В обработке POST запроса у этого контроллера должна происходить проверка на существование введенных данных в БД, то есть примерно то что у нас сейчас делается в LoginRequiredMiddeware, только данные берутся не из $_SERVER а из $_POST
3. Если данные в БД найдены, то надо в сессию прописать какое-нибудь новое поле типа is_logged и поставить ему значение true, типа $_SESSION["is_logged"] = true
4. В LoginRequiredMiddeware можно убрать весь код и просто проверять есть ли значение is_logged в сессии и если его нет или оно ложное, то делать редирект на страницу логина (то есть на контроллер из пункта 1)

Кнопка выхода

1. Надо добавить кнопку выйти на все шаблоны, кнопка должна находится в форме и иметь тип submit
2. Также надо добавить контроллер с url`ом типа /logout. Все что надо делать внутри этого контроллера это сбрасывать значение $_SESSION["is_logged"] на false и делать редирект на страницу /login