Создание веб-приложения CodeIgniter с нуля

Russian (Pусский) translation by Masha Kolesnikova (you can also view the original English article)

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

Задачи будут иметь базовые данные, такие как заголовок, описание и вознаграждение (в соответствии с требуемыми параметрами), а так же необязательная дата и примечания. Профиль пользователя будет состоять только из имени пользователя, электронной почты и веб-сайта. Давайте начнем.

Настройка базы данных

Во-первых, для данных приложения мы собираемся использовать MongoDB в качестве сервера базы данных. MongoDB - это документно-ориентированная база данных и самая популярная база данных NoSQL. Она хорошо масштабируется и быстрая, что позволяет управлять огромными объемами данных.

MongoDB - это документально ориентированная база данных и ведущая база данных NoSQL.

Чтобы использовать MongoDB в этом приложении, я собираюсь использовать драйвер MongoDB CodeIgniter, который я написал некоторое время назад и это всего лишь оболочка драйвера PHP MongoDB для имитации SQL ActiveRecord. Вы можете найти исходные файлы для этого драйвера в моем публичном репозитории. Чтобы этот драйвер работал правильно, убедитесь, что у вас установлен драйвер MongoDB PHP, если вы этого не сделали, выполните следующие действия, чтобы заставить его работать.

Обратите внимание, что объяснение драйверов в CodeIgniter и т.д. выходит за рамки данной статьи, обратитесь к документации, если у вас есть какие-либо сомнения. Вам просто нужно переместить "mongo_db.php" из папки "config" в папку "config" вашего приложения и папку "Mongo_db" из папки "libraries" в папку "libraries" в вашем приложении.

Настройка базы данных

Единственным файлом, который нам нужно отредактировать на данный момент, является "mongo_db.php" файл в папке "config", так как моя установка mongo имеет все параметры по умолчанию, я просто отредактирую строку 40 и оставлю имя базы данных, которую я хочу использовать:

1	$config['mongo_db'] = 'billboard';

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

Глобальная конфигурация

Помимо обычных параметров конфигурации, которые должны включать base_url и index_page, если таковые имеются, нам нужно установить string и date хелперы для автозагрузки. Я не буду здесь демонстрировать, как это делается, так как у нас впереди еще много всего, что нужно рассмотреть. Если у вас есть какие-либо сомнения, то лучше обратитесь к документации.

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

Обработка URL-адресов

Это будет RESTful сервис и нам нужен способ принимать запросы, поступающие на сервер, и обработать их соответствующим образом. Мы могли бы использовать существующую библиотеку (кстати, это классная), но для целей этой статьи я собираюсь создать необходимые функции, используя основные возможности CodeIgniter.

Обработка RESTful запросов

В частности, мы будем использовать возможность расширения core классов. Мы начнем с контроллера, для основной части этого расширения мы используем метод "_remap" в базовом контроллере, чтобы все контроллеры нашего приложения могли его использовать. Начните с создания файла MY_Controller.php внутри папки "core" в папке "application", мы создаем его, как и любой другой контроллер CodeIgniter, следующим образом:

<?php
if( !defined( 'BASEPATH' ) ) exit( 'No direct script access allowed' );

class MY_Controller extends CI_Controller {

}

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

public function _remap( $param ) {
    $request = $_SERVER['REQUEST_METHOD'];

    switch( strtoupper( $request ) ) {
        case 'GET':
            $method = 'read';
            break;
        case 'POST':
            $method = 'save';
            break;
        case 'PUT':
            $method = 'update';
            break;
        case 'DELETE':
            $method = 'remove';
            break;
        case 'OPTIONS':
            $method = '_options';
            break;
    }

    $this->$method( $id );
}

Несколько вещей, которые следует здесь отметить: во-первых, есть некоторые глаголы REST, которые мы игнорируем (например, PATCH), так как я демонстрирую создание приложения REST, я не хочу добавлять вещи, которые могут сделать его еще более сложным, чем оно должно быть. Во-вторых, мы не учитываем тот случай, когда контроллер не реализует определенный метод, что вполне вероятно может произойти. Теперь мы можем добавить метод по умолчанию для обработки таких запросов, но чтобы не добавлять слишком много сложностей, давайте оставим его так. В-третьих, мы получаем переменную param в объявлении метода, давайте обратимся к ней, а затем я объясню запрос OPTIONS. Выше оператора switch добавьте следующий код:

1	if ( preg_match( "/^(?=.[a-zA-Z])(?=.[0-9])/", $param ) ) {
2	$id = $param;
3	} else {
4	$id = null;
5	}

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

Запрос OPTIONS

Поскольку мы создаем веб-сервис и клиентское приложение как отдельные части, имеет смысл, что оба они будут размещаться в разных доменах, поэтому мы включим CORS на back-end, а это означает, среди прочего, что наше приложение будет правильно отвечать на запросы OPTIONS.

Когда веб-приложение, созданное с помощью BackboneJS (и некоторых других фреймворков), пытается выполнить асинхронный запрос на удаленный сервер, он отправляет запрос OPTIONS перед отправкой фактического запроса, который он должен отправить. Среди прочего, клиент сообщает серверу, откуда он отправляет запрос, какой тип запроса он собирается отправить и ожидаемый контент. После этого сервер должен отправить ответ клиенту, где он подтверждает запрос или отклоняет его.

Поскольку наша внутренняя служба, независимо от того, какой контроллер вызывается, собирается получить этот запрос OPTIONS, имеет смысл реализовать метод ответа на него в нашем базовом контроллере. Добавьте следующий метод ниже (или выше) метода _remap в нашем контроллере.

private function _options() {
    $this->output->set_header( 'Access-Control-Allow-Origin: *' );
    $this->output->set_header( "Access-Control-Allow-Methods: POST, GET, PUT, DELETE, OPTIONS" );
    $this->output->set_header( 'Access-Control-Allow-Headers: content-type' );
    $this->output->set_content_type( 'application/json' );
    $this->output->set_output( "*" );
}

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

Управление выводом

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

protected function _format_output( $output = null ) {
    $this->output->set_header( 'Access-Control-Allow-Origin: *' );

    if( isset( $output->status ) && $output->status == 'error' ) {
        $this->output->set_status_header( 409, $output->desc );
    }
    $this->_parse_data( $output );

    $this->output->set_content_type( 'application/json' );
    $this->output->set_output( json_encode( $output ) );
}

Опять же, чтобы BackboneJS обрабатывал ответ сервера, он должен знать, что его хост принят сервером, следуя заголовку Allow-Origin, а затем, если результат является невалидным, то мы устанавливаем заголовок состояния, указывающий на это. Этот status станет более понятным, когда мы будем создавать модели на бэкенде. Затем мы используем хелпер parse_data, который будет частным методом (который мы скоро напишем), затем мы устанавливаем тип содержимого как JSON и, наконец, мы конвертируем ответ в объект JSON , Опять же, здесь мы могли (и должны) поддерживать другие выходные форматы (например, XML).

Теперь давайте создадим вспомогательный метод parse_data (и я объясню его позже), добавьте следующий код в базовый контроллер:

private function _parse_data( &$data ) {
    if ( ! is_array( $data ) && ! is_object( $data ) )
        return $data;

    foreach ( $data as $key => $value ) {
        if ( is_object( $value ) || is_array( $value ) ) {
            if( is_object( $data ) ) {
                $data->{$key} = $this->_parse_data( $value );
            } else {
                $data[ $key ] = $this->_parse_data( $value );
            }
        }

        if ( isset( $value->sec ) ) {
            if( is_object( $data ) ) {
                $data->{$key} = date( 'd.m.Y', $value->sec );
            } else {
                $data[ $key ] = date( 'd.m.Y', $value->sec );
            }
        }

        if ( is_object( $value ) && isset( $value->{'$id'} ) ) {
            if( is_object( $data ) ) {
                $data->{$key} = $value->__toString();
            } else {
                $data[ $key ] = $value->__toString();
            }
        }
    }

    return $data;
}

Во-первых, обратите внимание, что мы анализируем данные только для массивов и объектов, и мы делаем это рекурсивно. Этот предварительный анализ имеет отношение к тому факту, что MongoDB использует даты и идентификаторы как объекты, но нашим клиентам эта информация не нужна. Теперь для случая идентификаторов нам просто нужно его строковое значение, поэтому для свойства '$id' мы вызываем метод toString. Впоследствии мы преобразуем даты в формат day.month.year, это делается для удобства в дизайне клиентского приложения, опять же, не самый гибкий подход, но он работает для этого примера.

Обработка ввода

Поскольку мы отправляем JSON обратно в клиентское приложение, логично, что мы также принимаем данные в формате JSON. CodeIgniter не поддерживает это по умолчанию, как например Laravel, на самом деле CodeIgniter даже не поддерживает put и delete параметры. Это связано главным образом с тем, что фреймворк не предназначен для создания RESTful сервиса, однако усилия, которые необходимо предпринять для его адаптации, минимальны по сравнению с получаемыми преимуществами, по крайней мере, с моей точки зрения.

Поэтому мы начнем с поддержки данных JSON, которые посылает BackboneJS. Создайте новый файл внутри папки "core", на этот раз он будет называться "MY_Input.php" и он будет иметь следующую основную структуру:

<?php
if( !defined( 'BASEPATH' ) ) exit( 'No direct script access allowed' );

class MY_Input extends CI_Input {

}

Теперь каждый раз, когда мы используем $this->input в нашем приложении, мы будем ссылаться на этот класс, мы создадим несколько новых методов и переопределим несколько существующих. Прежде всего, мы добавим поддержку данных JSON, добавим следующий метод в новый класс.

public function json() {
    if ( !self::$request_params ) {
        $payload    = file_get_contents( 'php://input' );

        if ( is_array( $payload ) ) {
            self::$request_params   = $payload;
        } else if ( ( substr( $payload, 0, 1 ) == "{" ) && ( substr( $payload, ( strlen( $payload ) - 1 ), 1 ) == "}" ) ) {
            self::$request_params   = json_decode( $payload );
        } else {
            parse_str( $payload, self::$request_params );
        }
    }

    return (object) self::$request_params;
}

$request_params - статическая переменная, используемая для хранения строки запроса/данных, отправленных клиентом. Она статична, чтобы сделать объект независимым, чтобы мы могли получить доступ к нему с любого контроллера в любой момент времени. Данные получены из php://input, а не из глобальной переменной $_POST. Это делается для получения данных, отправленных через запросы PUT и DELETE. Наконец, полученный пейлоад проверяется, является ли массивом, объектом, закодированным JSON, или строкой запроса, и обрабатывается соответствующим образом. Затем результат возвращается как объект.

Чтобы этот метод работал, нам нужно создать статическую переменную $request_params и добавить ее объявление в начало класса.

1	private static $request_params = null;

Обработка регулярных запросов

Затем нам нужно переопределить метод post обычного класса ввода и использовать новый JSON место глобальной переменной $ _POST, добавим следующий метод в новый класс ввода.

public function post( $index = NULL, $xss_clean = FALSE ) {
    $request_vars   = ( array ) $this->json();
    if ( $index === NULL && !empty( $request_vars ) ) {
        $post       = array();
        foreach( array_keys( $request_vars ) as $key ) {
            $post[$key]  = $this->_fetch_from_array( $request_vars, $key, $xss_clean );
        }
        return $post;
    }
    return $this->_fetch_from_array( $request_vars, $index, $xss_clean );
}

Это почти то же самое, что и метод post из исходного класса CI_Input, с той лишь разницей, что он использует наш новый метод JSON вместо глобальной переменной $_POST для получения данных из post запроса. Теперь давайте сделаем то же самое для метода PUT.

public function put( $index = NULL, $xss_clean = FALSE ) {
    $request_vars   = ( array ) $this->json();
    if ( $index === NULL && !empty( $request_vars ) ) {
        $put = array();
        foreach( array_keys( $request_vars ) as $key ) {
            $put[$key]   = $this->_fetch_from_array( $request_vars, $key, $xss_clean );
        }
        return $put;
    }
    return $this->_fetch_from_array( $request_vars, $index, $xss_clean );
}

А затем нам также нужен метод DELETE:

public function delete( $index = NULL, $xss_clean = FALSE ) {
    $request_vars   = ( array ) $this->json();
    if ( $index === NULL && !empty( $request_vars ) ) {
        $delete = array();
        foreach( array_keys( $request_vars ) as $key ) {
            $delete[$key]   = $this->_fetch_from_array( $request_vars, $key, $xss_clean );
        }
        return $delete;
    }
    return $this->_fetch_from_array( $request_vars, $index, $xss_clean );
}

Теперь технически нет необходимости в дополнительных методах, поскольку метод post может обрабатывать параметры в запросах PUT и DELETE, но семантически так лучше (на мой взгляд).

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

Базовая модель

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

<?php
if( !defined( 'BASEPATH' ) ) exit( 'No direct script access allowed' );

class MY_Model extends CI_Model {

}

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

protected function _set_error( $desc, $data = null ) {
    $this->_error           = new stdClass();
    $this->_error->status   = 'error';
    $this->_error->desc     = $desc;
    if ( isset( $data ) ) {
        $this->_error->data = $data;
    }
}

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

1	protected $_error;

Наконец, чтобы сохранить структуру, давайте создадим метод getter для этого свойства.

1	public function get_error() {
2	return $this->_error;
3	}

Обработка сеансов

Контроллер сеанса

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

Контроллер для нашего сеанса будет отвечать на любой запрос POST, сделанный для нашего ресурса Session, поскольку сеанс не может быть восстановлен после создания или обновлен напрямую, этот контроллер будет отвечать только на запросы POST и DELETE. Обратите внимание, что отправка любого другого запроса на ресурс приведет к ошибке сервера, но этого можно было бы легко избежать, проверяя, существует ли вызванный метод в нашем файле MY_Controller, и задав имя метода по умолчанию если ресурс не поддерживает данный запрос.

Ниже вы найдете структуру для нашего контроллера Session:

<?php
if ( !defined( 'BASEPATH' ) ) exit( 'No direct script access allowed' );

class Session extends MY_Controller {

    public function __construct() {}

    public function save() {}

    public function remove( $id = null ) {}
}

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

public function __construct() {
    parent::__construct();

    $this->load->model( 'session_model', 'model' );
}

Этот простой конструктор просто вызывает свой родительский конструктор (как и каждый контроллер в CodeIgniter), а затем загружает модель контроллера. Код для метода save выглядит следующим образом.

public function save() {
    $result = $this->model->create();
    if ( !$result ) {
        $result = $this->model->get_error();
    }
    $this->_format_output( $result );
}

А вот код для метода remove:

public function remove( $id = null ) {
    $result = $this->model->destroy( $id );
    if ( !$result ) {
        $result = $this->model->get_error();
    }
    $this->_format_output( $result );
}

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

Модель сеанса

Теперь перейдем к модели сеанса. Вот ее основная структура:

<?php
if ( !defined( 'BASEPATH' ) ) exit( 'No direct script access allowed' );

class Session_Model extends MY_Model {

    public function __construct() {}

    public function create() {}

    public function destroy( $id ) {}
}

Подобно контроллеру, эта модель расширяет класс MY_Model вместо обычного класса CI_Model, это делается для того, чтобы использовать общие методы, которые мы создали ранее. Опять же, давайте начнем с конструктора.

1	public function __construct() {
2	$this->load->driver( 'mongo_db' );
3	}

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

public function destroy( $id ) {
    $filters    = array( '_id' => $this->mongo_db->gen_id( $id ) );

    $query     = $this->mongo_db->get_where( 'sessions', $filters );
    if ( $query->num_rows() == 0 ) {
        $this->_set_error( 'INVALID_CREDENTIALS' );
        return false;
    }

    $this->mongo_db->remove( 'sessions', $filters );
    return 'SESSION_TERMINATED';
}

В этом методе мы проверяем, есть ли сеанс для данного session_id, и если так, то мы попытаемся удалить его, отправив сообщение об успешном завершении, если все будет хорошо, или установим ошибку и вернем false, если что-то пойдет не так. Обратите внимание, что при использовании session_id мы используем специальный метод $this->mongo_db->gen_id, так как, как я уже упоминал ранее, идентификаторы в MongoDB являются объектами, поэтому мы используем строку id для его создания.

Наконец, давайте напишем метод create, который завершит первую часть этой серии уроков.

public function create() {
    $query      = $this->mongo_db->get_where( 'users', array( 'email' => $this->input->post( 'email' ) ) );
    if ( $query->num_rows() != 1 ) {
        $this->_set_error( 'INVALID_CREDENTIALS' );
        return false;
    }

    $this->load->library( 'encrypt' );
    $user   = $query->row();
    $salt   = $this->encrypt->decode( $user->salt );
    if ( $user->pass != sha1( $this->input->post( 'pass' ) . $salt ) ) {
        $this->_set_error( 'INVALID_CREDENTIALS' );
        return false;
    }

    $this->mongo_db->remove( 'sessions', array( 'user_id' => $user->_id->__toString() ) );

    $session    = array(
        'timestamp'     => now(),
        'user_id'       => $user->_id->__toString(),
        'persistent'    => $this->input->post( 'persistent' )
    );

    if ( !$this->mongo_db->insert( 'sessions', $session ) ) {
        $this->_set_error( 'ERROR_REGISTERING_SESSION' );
        return false;
    }

    $result                 = new stdClass();
    $result->id             = $this->mongo_db->insert_id();
    $result->user_id        = $user->_id->__toString();

    return $result;
}

Прежде всего, мы проверяем, есть ли пользователь, связанный с данным email. Затем мы декодируем связанную с пользователем salt (которую я объясню во второй части этой серии, когда мы рассмотрим регистрацию пользователя) и проверяем, что данный пароль соответствует сохраненному паролю пользователя.

Затем мы удаляем любой предыдущий сеанс, связанный с пользователем, и создаем новый объект сеанса. Если бы мы более тщательно проверяли сеанс, то можно было добавить к этому объекту еше такие вещи, как user_agent, ip_address, last_activity и т.д. Наконец, мы отправляем клиенту сеанс и идентификатор пользователя для нового сеанса.

Заключение

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

1	private function _parse_data( &$data ) {
2	if ( ! is_array( $data ) && ! is_object( $data ) )
3	return $data;
4
5	foreach ( $data as $key => $value ) {
6	if ( is_object( $value ) \|\| is_array( $value ) ) {
7	if( is_object( $data ) ) {
8	$data->{$key} = $this->_parse_data( $value );
9	} else {
10	$data[ $key ] = $this->_parse_data( $value );
11	}
12	}
13
14	if ( isset( $value->sec ) ) {
15	if( is_object( $data ) ) {
16	$data->{$key} = date( 'd.m.Y', $value->sec );
17	} else {
18	$data[ $key ] = date( 'd.m.Y', $value->sec );
19	}
20	}
21
22	if ( is_object( $value ) && isset( $value->{'$id'} ) ) {
23	if( is_object( $data ) ) {
24	$data->{$key} = $value->__toString();
25	} else {
26	$data[ $key ] = $value->__toString();
27	}
28	}
29	}
30
31	return $data;
32	}

1	public function create() {
2	$query = $this->mongo_db->get_where( 'users', array( 'email' => $this->input->post( 'email' ) ) );
3	if ( $query->num_rows() != 1 ) {
4	$this->_set_error( 'INVALID_CREDENTIALS' );
5	return false;
6	}
7
8	$this->load->library( 'encrypt' );
9	$user = $query->row();
10	$salt = $this->encrypt->decode( $user->salt );
11	if ( $user->pass != sha1( $this->input->post( 'pass' ) . $salt ) ) {
12	$this->_set_error( 'INVALID_CREDENTIALS' );
13	return false;
14	}
15
16	$this->mongo_db->remove( 'sessions', array( 'user_id' => $user->_id->__toString() ) );
17
18	$session = array(
19	'timestamp' => now(),
20	'user_id' => $user->_id->__toString(),
21	'persistent' => $this->input->post( 'persistent' )
22	);
23
24	if ( !$this->mongo_db->insert( 'sessions', $session ) ) {
25	$this->_set_error( 'ERROR_REGISTERING_SESSION' );
26	return false;
27	}
28
29	$result = new stdClass();
30	$result->id = $this->mongo_db->insert_id();
31	$result->user_id = $user->_id->__toString();
32
33	return $result;
34	}