User-agent

Содержание

Обслуживание статических файлов с помощью Nginx (необязательно)

Когда Nginx перенаправляет запросы доменов Apache через прокси-сервер, каждый запрос файла этого домена отправляется в Apache. Nginx обслуживает статические файлы, такие как изображения, JavaScript и таблицы стилей, быстрее Apache. Поэтому мы настроим файл виртуального хоста Nginx  для прямого обслуживания статических файлов и перенаправления запросов PHP в Apache.

Откройте в своем редакторе файл :

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

Если вы решили не использовать сертификаты SSL и TLS, измените свой файл, чтобы он выглядел следующим образом:

/etc/nginx/sites-available/apache

Если вы также хотите обеспечить доступность HTTPS, используйте следующую конфигурацию:/etc/nginx/sites-available/apache

Директива  указывает Nginx искать файлы в корне документа document root и выводить их напрямую. Если файл имеет расширение , запрос перенаправляется в Apache. Даже если файл отсутствует в document root, запрос перенаправляется в Apache, чтобы функции приложения (например, постоянные ссылки) работали без проблем.

Предупреждение. Директива  очень важна, поскольку она не дает Nginx выводить содержимое файлов конфигурации Apache с важными данными, таких как  и .

Сохраните файл и проведите тест конфигурации:

Если тест завершается успешно, перезагрузите Nginx:

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

Теперь откройте в браузере  и посмотрите на результаты вывода журнала. Вы увидите ответ Apache:

Затем откройте страницы  каждого сайта, и вы не увидите записи журнала Apache. Их обслуживает Nginx.

Завершив изучение файла журнала, нажмите  чтобы остановить отслеживание.

При такой настройке Apache не сможет ограничивать доступ к статическим файлам. Контроль доступа к статическим файлам должен быть настроен в файле  виртуального хоста Nginx, однако это не входит в содержание настоящего обучающего руководства.

Проверка функционала PHP

Чтобы убедиться, что PHP работает, мы создадим файл  и получим к нему доступ к через браузер.

Создайте файл , содержащий вызов функции :

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

Убедитесь, что в Server API вверху страницы указано значение FPM/FastCGI. Раздел «Переменные PHP» в нижней трети страницы покажет, что параметр SERVER_SOFTWARE имеет значение Apache на Ubuntu. Это подтверждает, что модуль  активен, и что Apache использует PHP-FPM для обработки файлов PHP.

$_SERVER[‘HTTP_ACCEPT_LANGUAGE’]

В элементе $_SERVER описываются предпочтения клиента относительно языка. Данная информация извлекается из HTTP-заголовка Accept-Language,
который присылает клиент серверу. Можно привести следующий пример:

Который можно интерпретировать следующим образом: клиент предпочитает русский язык, но в случае его отсутствия согласен принимать документы на английском.
Элемент $_SERVER будет содержать точно такую же информацию, но без заголовка Accept-Language:

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

Настройка Nginx для виртуальных хостов Apache

Создадим дополнительный виртуальный хост Nginx с несколькими именами доменов в директивах . Запросы этих доменных имен будут перенаправляться через прокси-сервер в Apache.

Создайте новый файл виртуального хоста Nginx для перенаправления запросов в Apache:

Добавьте следующий блок кода, указывающий имена доменов виртуального хоста Apache и перенаправляющий их запросы в Apache. Обязательно используйте публичный IP-адрес в :

/etc/nginx/sites-available/apache

Сохраните файл и активируйте новый файл виртуального хоста, создав символическую ссылку:

Протестируйте конфигурацию и убедитесь в отсутствии ошибок:

Если ошибок нет, перезагрузите Nginx:

Откройте в браузере URL-адрес . Перейдите в раздел PHP Variables и проверьте отображаемые значения.

Переменные SERVER_SOFTWARE и DOCUMENT_ROOT подтверждают, что запрос был обработан Apache. Переменные HTTP_X_REAL_IP и HTTP_X_FORWARDED_FOR были добавлены Nginx и должны показывать публичный IP-адрес компьютера, используемого для доступа к URL-адресу.

Мы успешно настроили Nginx для перенаправления запросов определенных доменов в Apache через прокси-сервер. Теперь настроим Apache для установки переменной , как если бы эти запросы обрабатывались напрямую.

Получение SSL: ошибка CERTIFICATE_VERIFY_FAILED

Когда я впервые выполнил указанную выше программу, я получил следующую ошибку, связанную с сертификатами SSL.

$ python3.6 http_client.py 
Traceback (most recent call last):
  File "http_client.py", line 4, in <module>
    connection.request("GET", "/")
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/http/client.py", line 1239, in request
    self._send_request(method, url, body, headers, encode_chunked)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/http/client.py", line 1285, in _send_request
    self.endheaders(body, encode_chunked=encode_chunked)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/http/client.py", line 1234, in endheaders
    self._send_output(message_body, encode_chunked=encode_chunked)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/http/client.py", line 1026, in _send_output
    self.send(msg)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/http/client.py", line 964, in send
    self.connect()
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/http/client.py", line 1400, in connect
    server_hostname=server_hostname)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ssl.py", line 401, in wrap_socket
    context=self, session=session)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ssl.py", line 808, in init
    self.do_handshake()
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ssl.py", line 1061, in do_handshake
    self._sslobj.do_handshake()
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ssl.py", line 683, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLError:  certificate verify failed (_ssl.c:748)
$ 

Из вывода было ясно, что он должен что-то делать с сертификатами SSL. Но сертификат веб-сайта в порядке, так что это должно быть что-то с настройкой. После некоторого поиска в Google я обнаружил, что в MacOS нам нужно запустить файл Install Certificates.command, находящийся в каталоге установки в Python, чтобы исправить эту проблему. На изображении ниже показан результат выполнения этой команды, похоже, что он устанавливает последние сертификаты, которые будут использоваться при создании SSL-соединений.

Обратите внимание, что я получил эту ошибку в Mac OS. Однако в моей системе Ubuntu он работал отлично

$_SERVER[‘HTTP_ACCEPT’]

В элементе $_SERVER описываются предпочтения клиента относительно типа документа.
Содержимое этого элемента извлекается из HTTP-заголовка Accept, который присылает клиент серверу.
Содержимое данного заголовка может выглядеть следующим образом

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

Символ * используется для группирования типов в медиа-ряду. К примеру, символом */* задается использование всех типов,
а обозначение type/* определяет использование всех подтипов выбранного типа type.

Замечание

Медиа-типы отделяются друг от друга запятыми.

Каждый медиа-ряд характеризуется также дополнительным набором параметров. Одним из них является так называемый относительный
коэффициент предпочтения q, который принимает значения от 0 до 1, соответственно, от менее предпочитаемых типов к более предпочитаемым.
Использование нескольких параметров q, позволяет клиенту сообщить серверу относительную степень предпочтения для того или иного медиа-типа.

Замечание

По умолчанию параметр q принимает значение 1. Кроме того, от медиа-типа он отделяется точкой с запятой.

Пример заголовка типа Accept:

text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8

В данном заголовке первым идёт тип audio/* включающий в себя все музыкальные документы и характеризующийся коэффициентом предпочтения 0.2.
Через запятую указан тип audio/basic, для которого коэффициент предпочтения не указан и принимает значение по умолчанию равное единице.
Цитируя RFС2616 данный заголовок можно интерпретировать следующим образом:
«Я предпочитаю тип audio/basic, но мне можно также слать документы любого другого audio-типа, если они будут доступны, после снижения коэффициента предпочтения более чем на 80 %».

Пример может быть более сложным.

Замечание

Следует учитывать, что элемент $_SERVER содержит точно такую же информацию, но без начального заголовка Accept.

Этот заголовок интерпретируется следующим образом: Типы документов text/html и text/x-c являются предпочтительными, но если они недоступны,
тогда клиент отсылающий данный запрос, предпочтёт text/x-dvi, а, если и его нет, то он может принять тип text/plain.

Compare GET vs. POST

The following table compares the two HTTP methods: GET and POST.

  GET POST
BACK button/Reload Harmless Data will be re-submitted (the browser should alert the user that the data are about to be re-submitted)
Bookmarked Can be bookmarked Cannot be bookmarked
Cached Can be cached Not cached
Encoding type application/x-www-form-urlencoded application/x-www-form-urlencoded or multipart/form-data. Use multipart encoding for binary data
History Parameters remain in browser history Parameters are not saved in browser history
Restrictions on data length Yes, when sending data, the GET method adds the data to the URL; and the length of a URL is limited (maximum URL length is 2048 characters) No restrictions
Restrictions on data type Only ASCII characters allowed No restrictions. Binary data is also allowed
Security GET is less secure compared to POST because data sent is part of the URL
Never use GET when sending passwords or other sensitive information!
POST is a little safer than GET because the parameters are not stored in browser history or in web server logs
Visibility Data is visible to everyone in the URL Data is not displayed in the URL

❮ Previous
Next ❯

GET и POST запросы с использованием Python

Существует два метода запросов HTTP (протокол передачи гипертекста): запросы GET и POST в Python.

Что такое HTTP/HTTPS?

HTTP — это набор протоколов, предназначенных для обеспечения связи между клиентами и серверами. Он работает как протокол запроса-ответа между клиентом и сервером.

Веб-браузер может быть клиентом, а приложение на компьютере, на котором размещен веб-сайт, может быть сервером.

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

  1. GET: запросить данные с сервера. Т.е. мы отправляем только URL (HTTP) запрос без данных. Метод HTTP GET предназначен для получения информации от сервера. В рамках GET-запроса некоторые данные могут быть переданы в строке запроса URI в формате параметров (например, условия поиска, диапазоны дат, ID Объекта, номер счетчика и т.д.).
  2. POST: отправить данные для обработки на сервер (и получить ответ от сервера). Мы отправляем набор информации, набор параметров для API. Метод запроса POST предназначен для запроса, при котором веб-сервер принимает данные, заключённые в тело сообщения POST запроса.

Чтобы сделать HTTP-запросы в python, мы можем использовать несколько HTTP-библиотек, таких как:

  • HTTPLIB
  • URLLIB
  • REQUESTS

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

Если вы используете pip для управления вашими пакетами Python, вы можете устанавливать запросы, используя следующую команду:

pip install requests

Если вы используете conda, вам понадобится следующая команда:

conda install requests

После того, как вы установили библиотеку, вам нужно будет ее импортировать

Давайте начнем с этого важного шага:

import requests

Синтаксис / структура получения данных через GET/POST запросы к API

Есть много разных типов запросов. Наиболее часто используемый, GET запрос, используется для получения данных.

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

Чтобы сделать запрос «GET», мы будем использовать функцию.

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

Ниже приведена подборка различных примеров использования запросов GET и POST через библиотеку REQUESTS. Безусловно, существует еще больше разных случаев. Всегда прежде чем, писать запрос, необходимо обратиться к официальной документации API (например, у Yandex есть документация к API различных сервисов, у Bitrix24 есть документация к API, у AmoCRM есть дока по API, у сервисов Google есть дока по API и т.д.). Вы смотрите какие методы есть у API, какие запросы API принимает, какие данные нужны для API, чтобы он мог выдать информацию в соответствии с запросом. Как авторизоваться, как обновлять ключи доступа (access_token). Все эти моменты могут быть реализованы по разному и всегда нужно ответ искать в официальной документации у поставщика API.

#GET запрос без параметров
response = requests.get('https://api-server-name.com/methodname_get')

#GET запрос с параметрами в URL
response = requests.get("https://api-server-name.com/methodname_get?param1=ford&param2=-234&param3=8267")

# URL запроса преобразуется в формат https://api-server-name.com/methodname_get?key2=value2&key1=value1
param_request = {'key1': 'value1', 'key2': 'value2'}  
response = requests.get('https://api-server-name.com/methodname_get', params=param_request)

#GET запрос с заголовком
url = 'https://api-server-name.com/methodname_get'  
headers = {'user-agent': 'my-app/0.0.1'}  
response = requests.get(url, headers=headers)

#POST запрос с параметрами в запросе
response = requests.post('https://api-server-name.com/methodname_post', data = {'key':'value'})

#POST запрос с параметрами через кортеж
param_tuples =   
response = requests.post('https://api-server-name.com/methodname_post', data=param_tuples)

#POST запрос с параметрами через словарь
param_dict = {'param': }  
response = requests.post('https://api-server-name.com/methodname_post', data=payload_dict) 

#POST запрос с параметрами в формате JSON
import json  
url = 'https://api-server-name.com/methodname_post'  
param_dict = {'param': 'data'}  
response = requests.post(url, data=json.dumps(param_dict))

?‍? Практическое занятие: создаем запрос в Postman

Создаем запрос

Использование инструмента Postman для создания запроса о текущих погодных данных при помощи конечной точки API OpenWeatherMap.

  • Если еще не установлен Postman, открываем сайт https://www.getpostman.com/ и установите приложение;
  • Запускаем приложение;
  • Выбираем метод GET (обычно выбирается по умолчанию);
  • Вставляем конечную точку https://api.openweathermap.org/data/2.5/weather в ячейку справа от метода;
  • Открывыем вкладку под методом и вписать следующие значения:

    key: / value:

    key: / value:

    key: / value:

Вставляем в значение ZIP и appid нужный индекс и ключ авторизации API

Интерфейс Postman будет выглядеть так:

При добавлении параметров они будут отображаются в виде строки запроса к URL-адресу конечной точки в поле GET.

В пример конечная точка будет выглядеть так: https://api.openweathermap.org/data/2.5/weather?zip=95050&units=imperial&appid=8d3f4ca3fe57058a39b58b2a30945699 (но с другими значениями API ключа)

Параметры строки запроса отображаются после знака “?” и разделяются между собой амперсандом “&”. Порядок параметров в строке запросов значения не имеет.

Многие API передают ключ API в заголовке, а не в качестве параметра строки запроса в URL-адресе запроса. (Если бы это было так, вы бы кликнули вкладку «Headers» и вставили необходимую пару ключ-значение в заголовок.)

Кликаем на кнопку Send

Ответ появится в нижней панели. Пример:

Сохраняем запрос

  • В Postman нажать на кнопку (правее )
  • В диалоговом окне ввести имя запроса, например: “OpenWeatherMap Current API”
  • В описании запроса написать краткое описание запроса (опционально), например: “gets the current weather for 95050 in imperial units.”
  • Проскроллить окно немного вниз и нажать для создания папки, куда будет сохранен запрос. После создания выбрать созданную папку.

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

Нажимаем Save to (имя папки)

Сохраненные конечные точки будут видны в панели слева в Коллекциях. Если панель “Коллекции” не видна, нажать кнопку в нижнем левом углу.

Создаем запрос на 5-дневный прогноз OpenWeatherMap

Теперь вместо получения текущей погоды, используем другую конечную точку OpenWeatherMap для получения прогноза. Введите данные в Postman для 5-дневного прогноза. В Postman вы можете щелкнуть новую вкладку или щелкнуть стрелку рядом с «Сохранить» и выбрать «Сохранить как». Затем выберите свою коллекцию и запросите название.

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

Добавим в параметры запроса значения API и units

В своей ссылке замените на ключ API

Создаем еще один запрос OpenWeatherMap

Сделаем еще один запрос API OpenWeatherMap, на этот раз изменив параметры, которые использовали ранее для указания местоположения (для любой конечной точки). Например, если указали местоположение по почтовому индексу, изменим его на географические координаты lat и lon.

Например:

HTML Tags

<!—><!DOCTYPE><a><abbr><acronym><address><applet><area><article><aside><audio><b><base><basefont><bdi><bdo><big><blockquote><body><br><button><canvas><caption><center><cite><code><col><colgroup><data><datalist><dd><del><details><dfn><dialog><dir><div><dl><dt><em><embed><fieldset><figcaption><figure><font><footer><form><frame><frameset><h1> — <h6><head><header><hr><html><i><iframe><img><input><ins><kbd><label><legend><li><link><main><map><mark><meta><meter><nav><noframes><noscript><object><ol><optgroup><option><output><p><param><picture><pre><progress><q><rp><rt><ruby><s><samp><script><section><select><small><source><span><strike><strong><style><sub><summary><sup><svg><table><tbody><td><template><textarea><tfoot><th><thead><time><title><tr><track><tt><u><ul><var><video>

Единая точка входа

Принцип работы единой точки входа очень прост.

Веб-сервер настраивается так, чтобы все HTTP-запросы, вне зависимости от их URL, обрабатывались одним и тем же скриптом index.php.

Перенаправление всех запросов на index.php

Текущий URL можно получить из переменной $_SERVER. Дальше останется только написать свои правила обработки URL-адресов. Упрощённый пример:

Однако в схеме выше есть одно упущение. Ведь если на сервер пришёл запрос к существующему файлу (style.css, script.js, logo.png и т.д) — сервер должен отдать этот файл, а не перенаправлять его.

Принцип работы единой точки входа

Вот и весь принцип единой точки входа. Именно так она работает в популярных CMS вроде WordPress и Opencart, в фреймворках Laravel, Symfony и т.д.

Единственный вопрос, который вам останется решить — что делать с запросами к существующим папкам.

Лично я предпочитаю также перенаправлять их на index.php.

На самом деле на сайтах часто используются 2 точки входа.

Первая — index.php, вторая — отдельный скрипт, предназначенный для работы с сайтом через консоль.

Плюсы единой точки входа

  • Позволяет использовать ЧПУ
  • Позволяет полностью управлять URL-адресами в PHP, в том числе хранить URL-адреса в базе данных
  • Скрипты с конфигами, важными функциями и библиотеками подключаются только 1 раз и становятся доступны везде. Не нужно дублировать их подключение где-либо ещё.

Единая точка входа с Apache

Для настройки единой точки входа необходимо добавить несколько строк в конфиг веб-сервера. Проще всего это сделать с помощью файла .htaccess.

Этот файл позволяет переопределять настройки Apache для определённых сайтов и папок.

Добавляем следующие настройки в .htaccess:

Чтобы перенаправление срабатывало для существующих директорий, удаляем строку с !-d в конце, вот так:

Готово. Получить URL адрес текущей страницы можно из переменной $_SERVER.

Также в интернете часто можно встретить другой вариант конфига, отличается он только последней строкой:

Главное отличие в том, что URL-адрес текущей страницы будет храниться как в $_SERVER, так и в отдельном GET-параметре, в нашем случае $_GET, причём этот URL будет очищен от GET-параметров.

Флаг QSA нужен, поскольку без него GET-параметры не будут работать, т.е. массив $_GET будет содержать только url_param и больше ничего.

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

Примеры запросов POST с использованием библиотеки REQUESTS в PYTHON

Выгрузка данных из Bitrix24 с фильтром по дате из REST API

import requests

# method
method_name = "crm.deal.list"

# Адрес api метода для запроса get 
url_param = "https://domain.ru/rest/1/854984lkjdsijd432/" + method_name

params = {"filter": "2020-01-01T00:00:01+01:00"}

print(params)

response = requests.post(url_param, data = params)
result = response.json()
total = result
print(total)

Выгрузка данных из Bitrix24 с двумя фильтрами по дате из REST API

import requests

# method
method_name = "crm.deal.list"

# Адрес api метода для запроса get 
url_param = "https://domain.ru/rest/1/854984lkjdsijd432/" + method_name

params = {
    "filter":"2019-01-01T00:00:01+01:00",
    "filter":"2020-01-01T00:00:01+01:00"
    }

print(params)

response = requests.post(url_param, data = params)
result = response.json()
total = result
print(total)

Установка и настройка mod_rpaf

На этом шаге вы установите модуль Apache под названием , который перезаписывает значения REMOTE_ADDR, HTTPS и HTTP_PORT на базе значений, предоставленных обратным прокси-сервером. Без этого модуля для некоторых приложений PHP потребуется изменение кода для бесшовной работы из-за прокси-сервера. Этот модуль представлен в хранилище Ubuntu как , однако он устарел и не поддерживает некоторые директивы конфигурации. Поэтому мы установим его из источника.

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

Загрузите последний стабильный выпуск из GitHub:

Выполните извлечение загруженного файла:

Перейдите в новый каталог, содержащий файлы:

Скомпилируйте и установите модуль:

Затем создайте в каталоге  файл, который будет загружать модуль ,

Добавьте в файл следующий код для загрузки модуля:

/etc/apache2/mods-available/rpaf.load

Сохраните файл и выйдите из редактора.

Создайте в этом каталоге другой файл с именем , который будет содержать директивы конфигурации для :

Добавьте следующий блок кода для настройки  и обязательно укажите IP-адрес своего сервера:

/etc/apache2/mods-available/rpaf.conf

Здесь приведено краткое описание каждой директивы. Дополнительную информацию можно найти в файле  по модулю .

  • RPAF_Header — заголовок, используемый для реального IP-адреса клиента.
  • RPAF_ProxyIPs — IP-адрес прокси-сервера для корректировки запросов HTTP.
  • RPAF_SetHostName — обновляет имя vhost так, чтобы работали  и .
  • RPAF_SetHTTPS — задает переменную среды  на основе значения, содержащегося в .
  • RPAF_SetPort — задает переменную среды . Полезна для использования, когда сервер Apache находится за прокси-сервером SSL.

Сохраните  и активируйте модуль:

При этом создаются символические ссылки файлов  и  в каталоге . Теперь протестируем конфигурацию:

Если ошибок нет, перезагрузите Apache:

Откройте в браузере страницы  по адресам  и  и проверьте раздел PHP Variables. Переменная REMOTE_ADDR также будет использоваться для публичного IP-адрса вашего локального компьютера.

Теперь настроим шифрование TLS/SSL для каждого сайта.

Простой роутинг

Если единая точка входа настроена правильно, то при заходе по любому несуществующему URL-адресу, например /test должен запуститься файл index.php.

URL текущей страницы находится в переменной $_SERVER

Теперь мы можем написать очень простой роутер, который смотрит на текущий URL и подключает соответствующий скрипт:

Внесём ещё пару доработок. Во-первых, зачастую URL-адреса должны работать вне зависимости от наличия GET-параметров, поэтому вырежем их из URI:

Кроме этого, часто требуется получить доступ к определённой части URL. Для этого разобьём URL на части по слешу:

В переменной $segments для URL /products/15 будет лежать массив вида .

Теперь мы можем легко добавить маршруты для админки:

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

При хранении URL адресов в базе данных роутинг будет выглядеть примерно так (реальный код зависит от библиотеки, которую вы используете для взаимодействия с БД):

VPN через PPtP на MikroTik

PPtP – самый распространенный протокол VPN. Представляет собой связку протокола TCP, который используется для передачи данных, и GRE – для инкапсуляции пакетов. Чаще всего применяется для удаленного доступа пользователей к корпоративной сети. В принципе, может использоваться для многих задач VPN, однако следует учитывать его изъяны в безопасности.

Прост в настройке. Для организации туннеля требуется:

создать на роутере MikroTik, через который пользователи будут подключаться к корпоративной сети, PPtP-сервер,

создать профили пользователей с логинами/паролями для идентификации на стороне сервера,

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

Включаем PPtP сервер.

Для этого идем в раздел меню PPP, заходим на вкладку Interface, вверху в перечне вкладок находим PPTP сервер и ставим галочку в пункте Enabled.

Снимаем галочки с наименее безопасных алгоритмов идентификации – pap и chap.

Создаем пользователей.

В разделе PPP переходим в меню Secrets и с помощью кнопки » + » добавляем нового пользователя.

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

В поле Service выбираем тип нашего протокола – pptp, в поле Local Address пишем IP-адрес роутера MikroTik, который будет выступать в роли VPN-сервера, а в поле Remote Address – IP-адрес пользователя

Прописываем правила для Firewall.

Нам нужно открыть 1723 порт для трафика по TCP-протоколу для работы VPN-туннеля MikroTik, а также разрешить протокол GRE. Для этого идем в раздел IP, потом – в Firewall, потом на вкладку Filter Rules, где с помощью кнопки «+» добавляем новое правило. В поле Chain указываем входящий трафик – input, в поле Protocol выбираем протокол tcp, а в поле Dst. Port – указываем порт для VPN туннеля 1723.

Переходим здесь же на вкладку Action и выбираем accept – разрешать (трафик).

Точно также добавляем правило для GRE. На вкладке General аналогично предыдущему прописываем input, а в поле Protocol выбираем gre.

На вкладке Action как и в предыдущем правиле выбираем accept.

Не забываем поднять эти правила в общем списке наверх, поставив ПЕРЕД запрещающими правилами, иначе они не будут работать. В RouterOS Mikrotik это можно сделать перетаскиванием правил в окне FireWall.

Все, PPtP сервер для VPN на MikroTik поднят.

Небольшое уточнение.

В некоторых случаях, когда при подключении необходимо видеть локальную сеть за маршрутизатором, нужно включить proxy-arp в настройках локальной сети. Для этого идем в раздел интерфейсов (Interface), находим интерфейс, соответствующий локальной сети и на вкладке General в поле ARP выбираем proxy-arp.

Если вы подняли VPN между двумя роутерами MikroTik и вам необходимо разрешить передачу broadcast, можно попробовать добавить существующий профиль подключения (PPP – Profiles) удаленного роутера в бридж главного:

UPD из комментария: Если вам дополнительно нужно получить доступ к расшаренным папкам на компьютерах локальной сети, понадобится также открыть порт 445 для проходящего трафика SMB-протокола, который отвечает за Windows Shared. (Правило forward в брандмауере).

Настройка клиента .

На стороне VPN-клиента настройки состоят только в том, чтобы создать подключение по VPN, указать IP-адрес VPN (PPtP) сервера, логин и пароль пользователя.

Examples of Request Message

Now let’s put it all together to form an HTTP request to fetch hello.htm page from the web server running on tutorialspoint.com

GET /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

Here we are not sending any request data to the server because we are fetching a plain HTML page from the server. Connection is a general-header, and the rest of the headers are request headers. The following example shows how to send form data to the server using request message body:

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: application/x-www-form-urlencoded
Content-Length: length
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

licenseID=string&content=string&/paramsXML=string

Here the given URL /cgi-bin/process.cgi will be used to process the passed data and accordingly, a response will be returned. Here content-type tells the server that the passed data is a simple web form data and length will be the actual length of the data put in the message body. The following example shows how you can pass plain XML to your web server:

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: text/xml; charset=utf-8
Content-Length: length
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

<?xml version="1.0" encoding="utf-8"?>
<string xmlns="http://clearforest.com/">string</string>

Previous Page
Print Page

Next Page  

Request Header Fields

We will study General-header and Entity-header in a separate chapter when we will learn HTTP header fields. For now, let’s check what Request header fields are.

The request-header fields allow the client to pass additional information about the request, and about the client itself, to the server. These fields act as request modifiers.Here is a list of some important Request-header fields that can be used based on the requirement:

  • Accept-Charset

  • Accept-Encoding

  • Accept-Language

  • Authorization

  • Expect

  • From

  • Host

  • If-Match

  • If-Modified-Since

  • If-None-Match

  • If-Range

  • If-Unmodified-Since

  • Max-Forwards

  • Proxy-Authorization

  • Range

  • Referer

  • TE

  • User-Agent

You can introduce your custom fields in case you are going to write your own custom Client and Web Server.

$_SERVER[‘REMOTE_ADDR’]

В элемент $_SERVER помещается IP-адрес клиента. При тестировании на локальной машине — этот адрес будет равен 127.0.0.1.
Однако при тестировании в сети переменная вернёт IP-адрес клиента или последнего прокси-сервера через который клиент попал на сервер.
Если клиент использует прокси-сервер узнать его IP-адрес можно при помощи переменной окружения HTTP_X_FORWARDED_FOR,
значение которой можно получить при помощи функции getenv().

31.184.219.139

Замечание

Прокси-сервера являются специальными промежуточными серверами, предоставляющими специальный вид услуг: сжатие трафика, кодирование данных,
адаптация под мобильные устройства и т.п. Среди множества прокси-серверов различают так называемые анонимные прокси-сервера,
которые позволяют скрывать истинный IP-адрес клиента, такие сервера не возвращают переменной окружения HTTP_X_FORWARDED_FOR.

Apache2

Для поддержки файла .htaccess, который используется многими сайтами, необходимо установить и настроить веб-сервер Apache.

Настройка

Заходим в настройки портов:

И редактируем следующее:

мы настроили прослушивание на порту 8080, так как на 80 уже работает NGINX. Также мы закомментировали прослушивание по 443, так как и он будет слушаться NGINX.

Запрещаем mpm_event:

по умолчанию, apache2 может быть установлен с модулем мультипроцессовой обработки mpm_event. Данный модуль не поддерживает php 7 и выше.

Разрешаем модуль мультипроцессовой обработки :

Разрешаем модуль :

Разрешаем модуль :

Разрешаем модуль :

Разрешаем автозапуск и запускаем службу:

в разделе Server API мы должны увидеть Apache.