Php на windows и iis7

Структура URL адресов в админке

Обычно URL адреса в админке формируются по одной из следующих схем:

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

Итак, мы видим, что модулем здесь является products, а действием, к примеру, add. Что теперь с этим делать?

Если вы знакомы с ООП и MVC, тогда модулем для вас будет название класса, а действием — метод этого класса, который нужно запустить. Если действие не указано, то принято запускать метод под названием index.

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

Перепишем пример, написанный нами в единой точке входа, под новую схему URL:

Итак, мы берём 1-ый фрагмент URL и проверяем, существует ли в папке pages файл с таким названием.

Т.е. при переходе на страницу /test/test2 скрипт проверит существование файла /pages/test.php. Если файл есть — PHP выполнит этот файл, в противном случае выполнится файл /pages/404.php.

Как видите, при таком подходе нам больше не нужно прописывать соответствие URL-адресов и PHP-файлов. PHP сам будет искать нужный файл в папке pages по первому фрагменту URL.

Теперь осталось только создать файл pages/products.php. Сделаем небольшую заготовку:

Вот так выглядит обработка действий. Мы смотрим на второй фрагмент URL и ищем обработчик этого действия. Для каждого действия (add, update, delete) нужно прописать отдельный блок elseif.

Внутри обработчика add мы смотрим на то, каким методом пришёл запрос, GET или POST. Если GET — отображаем форму, если POST — добавляем товар.

Если вам не нравится вложенная проверка метода, можно сделать иначе. В файле index.php сохраним метод в отдельную переменную:

products.php

Готово. Да, если вам не нравится, что в коде 2 раза встречается одно и то же действие, только с разными методами, можете использовать немного упрощённую схему URL-адресов из фреймворка Laravel:

Добавление префикса /admin/ в URL

Немного изменим код index.php:

Теперь при запросе страницы /admin/products PHP будет искать файл с названием не products.php, а admin_products.php.

Переименуйте файл и не забудьте заменить в нём все $segments на $segments, поскольку в $segments теперь лежит модуль, а в $segments действие.

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

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

Веб-сервер настраивается так, чтобы все 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 и больше ничего.

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

9 Список литературы

• www.w3.org/XML/Schema – спецификация и прочая информация по XML-схемам
• www.w3.org/TR/soap – спецификация протокола SOAP
• ru.wikipedia.org/wiki/Remote_Procedure_Call – статья про RPC
• ru.wikipedia.org/wiki/REST – статья про REST
• ru.wikipedia.org/wiki/XML – статья про XML
• ru.wikipedia.org/wiki/XML_Schema – статья про XML-схемы
• ru.wikipedia.org/wiki/WSDL – статья про WSDL
• www.php.net/manual/ru/book.soap.php – официальный мануал по работе с SOAP в PHP
• github.com/hats/soap-sms-service – исходные коды примеров из топика

P.P.S. дополнение от Mikaz
Нужно вместо массива использовать ArrayObject в совокупности с SoapVar.
Рабочий код мог бы выглядеть так:

Обеспечиваем безопасность сайта

Файл .htaccess предоставляет большие возможности для защиты сайта от вредоносных скриптов, кражи контента, DOS-атак. Также можно защитить доступ к определенным файлам и разделам.

5. Запрещаем загрузку картинок с вашего сайта

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

Осадите воришек при помощи этого кода:

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

6. Запрещаем доступ

Целым группам нежелательных гостей с определенных IP-адресов, подсетей, а также вредоносным ботам можно запретить доступ на ваш ресурс при помощи следующих директив в .htaccess.

Для нежелательных User Agents (ботов)

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

Частный случай такого запрета — запрет для поисковых роботов. Если вас почему-то не устраивает правило в robots.txt, можно запретить доступ, например, роботу Google при помощи таких директив:

Для подсети

Вписываем маску сети в строку после «deny from».

Спамные IP-адреса можно вычислить в логах сервера или с помощью сервисов статистики. В административной панели WordPress отображаются IP-адреса комментаторов:

К определенному файлу

Вписываем название файла вместо «myfile.html» в примере. Пользователю будет показана ошибка 403 — «доступ запрещен».

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

Для сайтов на WordPress важно ограничить доступ к файлу wp-config.php, т.к. в нем содержится информация о базе данных:

Для пользователей, пришедших с определенного сайта

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

7. Защищаем доступ к определенному файлу или папке

Для начала создайте файл .htpasswd, пропишите в нем логины и пароли в формате user:password и разместите в корне сайта. В целях безопасности пароли лучше зашифровать. Это можно сделать при помощи специальных сервисов генерации записей, например, такого. Следующим шагом добавьте директории или файлы в .htaccess:

Защита паролем папки

Вместо «/pub/home/.htpasswd» укажите путь до файла .htpasswd от корня сервера. Рекомендуем проверить доступ после установки кода.

8. Запрещаем выполнение вредоносных скриптов

Следующая группа директив защищает сайт от так называемых «скриптовых инъекций» — инструмента хакерских атак:

Все попытки причинить вред вашему ресурсу будут перенаправлены на страницу ошибки 403 «доступ запрещен».

9. Защищаем сайт от DOS-атак

Один из способов защиты — ограничить максимально допустимый размер запроса (ограничение отсутствует по умолчанию).

Для этого прописываем в .htaccess размер загружаемых файлов в байтах:

В примере указан размер 10 Мбайт. Если вы хотите запретить загрузку файлов, пропишите число меньше 1 Мбайт (1048576 байт).

Также можно изучить возможности директив LimitRequestFields, LimitRequestFieldSize и LimitRequestLine в официальной документации.

Проверка подлинности в режиме ядра с помощью KerberosKernel mode authentication with Kerberos

HTTP.sys делегирует задачи в проверку подлинности в режиме ядра с помощью протокола проверки подлинности Kerberos.HTTP.sys delegates to kernel mode authentication with the Kerberos authentication protocol. Проверка подлинности в режиме пользователя не поддерживается с Kerberos и HTTP.sys.User mode authentication isn’t supported with Kerberos and HTTP.sys. Необходимо использовать учетную запись компьютера для расшифровки маркера/билета Kerberos, полученного из Active Directory и переадресованного клиентом на сервер для проверки подлинности пользователя.The machine account must be used to decrypt the Kerberos token/ticket that’s obtained from Active Directory and forwarded by the client to the server to authenticate the user. Зарегистрируйте имя субъекта-службы (SPN) для узла, а не пользователя приложения.Register the Service Principal Name (SPN) for the host, not the user of the app.

Пояснение на примерах

1. Многие спрашивают, для чего нужен — $_SERVER — в интернете практически не найти, а лучше смотрите пример:

Такой код может выдать такой ответ: Web-сервер — Apache. То есть вы поняли для чего он нужен, едем дальше…

2. $_SERVER — необходим для вывода информации об операционной системе клиента и версии и названии браузера:

Такой код может выдать такой ответ(только то, что в кавычках): Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0. Собирая данную информацию, можно оптимизировать свой сайт под наиболее востребованные браузеры.

3. $_SERVER — показывает имя сервера, которое совпадает с доменом без http и слешей, только имя.

Такой код может выдать такой ответ: saitsozdanie.ru — то есть как видим, что http:// опускается

$_SERVER — зачастую показывает практически тоже самое;

4. $_SERVER — используется для указания информации «откуда человек пришел» — а, именно, с какой страницы.

Такой код может выдать такой ответ: http://yandex.ru/clck/…. и так далее, если вы перешли на мой сайт к примеру с яндекса из поиска. Очень полезная функция получается для оценки трафика с поисковиков.

5. Использование $_SERVER — покажет вам предпочтения клиента относительно типа документа. Указание заголовка Accept позволяет уточнить желаемый медиа-тип.

Такой код может выдать такой ответ: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8.

Где q — это относительный коэффициент предпочтения (может принимать значения от 0 до 1, где 1 — означает, что более предпочтителен). Как видим типы отделяются между собой запятыми, а между типом и его коэффициентом ставится точка с запятой — application/xml;q=0.9,*/*;q=0.8 — где / — все типы. А вот там где нет значения q, он по-дефолту равен 1;

6. $_SERVER — используют для вычисления языкового предпочтения клиента(то есть возможность использования для национальной принадлежности). Извлечение идет из HTTP-заголовка Accept-Language:

Такой код может выдать такой ответ: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3. Это мои значения, у вас будут другие. Есть зависимость от браузера — англоязычные версии будут показывать в приоритете — English.

7. $_SERVER —  применяется для вычисления корневой директории сайта или папки(место, где лежит сайт, основная папка):

Такой код может показать такое: C:/Users/Sergio/OpenServer/domains/saitsozdanie.ru — если я проверяю свой сайта на локальном компьютере. На хостинге результат, естественно, будет другой, но для примера думаю красноречиво!

8. $_SERVER — используется для вычисления ip адреса клиента.

Такой код может показать такое: 127.0.0.1 это на локалке. В интернете же мы получим айпишник клиента. Если к нам на сайте человек зашел через прокси, то пользуем переменную окружения HTTP_X_FORWARDED_FOR (ее значения можно определить с помощью функции getenv() — кроме анонимных прокси, echo @getenv(HTTP_X_FORWARDED_FOR); ).

9. $_SERVER — показывает часть адреса или ссылки. К примеру, если у нас есть — http://saitsozdanie.ru/php/superglobalnyj-massiv-server-podrobno.html то элемент $_SERVER содержит это «/php/superglobalnyj-massiv-server-podrobno.html».

10. Что еще из полезного мы можем узнать из этого глобального массива:

Нетрудно догадаться и начать конструировать собственные конструкторы, которые, в принципе, уже давно созданы:

echo «http://».$_SERVER.$_SERVER; — и получить полный путь например к скрипту относительно сервера.

11. $_SERVER — позволяет получить часть ссылки после знака вопроса, то есть параметры, переданные скрипту.

12. $_SERVER — примените его и узнаете, какой метод запроса был использован GET или POST.

13. $_SERVER — для вычисления адреса скрипта относительно сервера. К примеру имеем строку запроса — http://sait.ru/byume/index.php?id=1&title=wet&them=215. Значения переменной $_SERVER — будет таковым: «/byume/index.php».

Похожее будет и с $_SERVER — этот элемент показывает абсолютный путь до файла(скрипта), только уже относительно сервера(может быть такое /var/www/sait.ru/index.php).

Более новые статьи:

• php создание файла, чтение и запись — 22/02/2016 11:54
• switch тонкости — 15/02/2016 13:10
• Ошибки PHP — 05/06/2015 12:23

8 Заключение

• вам по силам написать необходимый для вашего веб-сервиса WSDL-файл;
• вы без всяких проблем можете написать свой собственный клиент способный общаться с сервером по протоколу SOAP;
• вы можете написать свой собственный сервер общающийся с окружающим миром по SOAP;
• вы можете отправлять массивы однотипных объектов на сервер со своего клиента (с некоторыми ограничениями).

• нативный класс SoapClient не умеет правильно сериализовывать однотипные структуры данных в XML;
• при сериализации массива в XML он создает лишний элемент с именем Struct;
• при сериализации объекта в XML он создает лишний элемент с именем BOGUS;
• BOGUS меньшее зло чем Struct из-за того, что конверт получается компактнее (не добавляются лишние namespace’ы в XML заголовке конверта);
• к сожалению, класс SoapServer автоматически не валидирует данные конверта нашей XML-схемой (возможно, и другие сервера этого не делают).