Неизмеримый reg php language alias. Псевдонимы (алиасы) bash для Laravel
Типичная ситуация: HTTP-клиент запрашивает с сервера контент, который либо не существует на данном сервере, либо располагается по другому URL. Причин такому стечению обстоятельств может быть несколько. Вы, например, могли переместить контент в пределах сервера (а то и вообще за его пределы) или же вам понадобилось реорганизовать логическую структуру адресов вашего проекта. При обычных условиях запрос несуществующего контента приведёт к тому, что сервер сообщит об ошибке, однако в Apache имеется полезный модуль mod_alias , предоставляющий возможность создавать синонимы URL (aliasing — алиасинг ), а также выполнять перенаправление клиентов на другой URL (redirect — редирект ).
Псевдонимы (алиасы) позволяют серверу преобразовывать один URL в другой, таким образом перенаправляя клиентов на нужный контент, при этом без физической операции перенаправления: для клиента подобная операция совершенно прозрачна. Это очень полезная возможность, если, например, вы задумали очеловечить URL-адреса страниц вашего проекта с целью SEO-оптимизации или ещё зачем-то.
При помощи алиасов вы также можете организовать доступ к файлам, находящимся за пределами Document Root сервера, таким образом предоставив прямой доступ к любой части ФС сервера, не прибегая к использованию CGI-сценариев. Используя редирект, вы получаете возможность физически перенаправлять клиентов на нужные URL.
Директива AliasДиректива Alias позволяет незаметно для клиентов связывать запрашиваемые URL с любой частью файловой системы сервера. Например:
Директива в примере выше приведёт к тому, что Apache перед тем, как выполнять поиск контента в файловой системе, в строке запроса заменит /images/ на /ftp/public/images/ . Таким образом запрос URL http://www.example-domain.com/images/example-image.jpg заставит искать Apache файл example-image.jpg в физическом каталоге /ftp/public/images/ вместо каталога DOCUMENT_ROOT/images .
Обратите внимание на то, что завершающий слеш имеет значение. Приведённый выше пример не сработал бы, если б мы опустили завершающий слеш в первом параметре Alias . Также, алиасинг не сработал бы в случае, если бы клиент запросил URL, в котором после /images отсутствовал завершающий слеш.
Директива AliasMatchДиректива AliasMatch работает так же, как и Alias, при этом позволяя использовать регулярные выражения для определения исходных URL:
AliasMatch /images/(.*)$ /ftp/public/images/$1
В этом примере показано, как мы можете легко связать относительную часть запрашиваемого URL с частью физической файловой системы. Переменная $1 связана с первым соответствием, обнаруженным в скобках регулярного выражения, $2 — со вторым, и так далее. Таким образом, в примере выше, запрос URL http://www.example-site.com/some_dir/images/img1.jpg приведёт к получению файла /ftp/public/images/img1.jpg . Используя эту директиву вы можете, например, хранить все изображения в одном дереве каталогов, независимо от относительного положения подстроки /images/ в строке запроса.
Существенной разницей между Alias и AliasMatch является их поведение. Разница заключается в том, что Alias копирует оставшуюся часть строки запроса после вычитания из неё первого параметра директивы, в то время как AliasMatch — нет. То есть:
Alias /images/ /ftp/public/images/
совершенно не эквивалентна
AliasMatch /images/ /ftp/public/images/
поскольку вторая будет транслировать все запросы, содержащие подстроку /images/ к каталогу /ftp/public/images/ , не добавляя при перезаписи имён файлов. Чтобы получить то, что нужно, вам понадобится следующая инструкция:
AliasMatch ^/images/(.*)$ /ftp/public/images/$1
Директива ScriptAliasНазначение этой директивы такое же, как и Alias , однако при этом Apache считает конечный каталог таким, который хранит исполняемые CGI-сценарии. То есть после трансляции запроса и определения конечного пути запрашиваемого файла, Apache попытается выполнить последний, как CGI-сценарий.
ScriptAlias /cgi-bin/ /usr/local/apache2/cgi-bin/
В приведённом примере запрос http://www.example-site.com/cgi-bin/some_cgi_script приведёт к выполнению сценария, расположенного в файле /usr/local/apache2/cgi-bin/some_cgi_script . Альтернативный вариант такой конфигурации можно можно описать следующим набором инструкций:
Alias /cgi-bin/ /usr/local/apache2/cgi-bin/ SetHandler cgi-script Options +ExecCGI
Директива ScriptAliasMatchДанная директива аналогична предыдущей, однако умеет работать с регулярными выражениями, как и AliasMatch .
Директива Redirectmod_alias ко всему прочему позволяет явно сообщать клиентам о том, что запрошенный ими URL является некорректным, сообщая другой URL, по которому можно отыскать требуемый контент. Для управления такими перенаправлениями используется директива Redirect .
Эта директива работает подобно Alias , только вместо того, чтобы выполнять перенаправление внутри сервера, она отправляет команду перенаправления клиенту. Опциональным параметром директивы является тип перенаправления, сообщаемый клиенту кодом HTTP-статуса ответа (об этом чуть ниже).
Redirect permanent /images http://www.another-example-site.com/images
В приведённом примере запрос URL http://www.example-site.com/images/img1.gif приведёт к перенапрвлению на http://www.another-example-site.com/images/img1.gif .
Если запрашиваемый URL содержит query string , то она будет оставлена без изменений, только если это явно не определно последним параметром директивы Redirect .
Например, правило, рассмотренное выше, запрос URL http://www.example-site.com/images?img-name=1.gif перенаправит к http://www.another-example-site.com/images?img-name=1.gif . Однако, если мы перепишем правило следующим образом:
Redirect permanent /images http://www.another-example-site.com/images?q=new-value
то тот же запрос будет перенаправлен на http://www.another-example-site.com/images?q=new-value .
Теперь о типах перенаправления. Для того, чтобы сообщить клиенту о необходимости перенаправления на другой URL, сервер использует HTTP статус-коды . При помощи директивы Redirect можно определить один из четырёх HTTP-кодов перенаправления (в скобках указано символическое имя, которое можно использовать вместо номера кода).
301 (permanent) . Ресурс переехал на новый адрес. Клиенты и прокси-серверы должны обновить информацию в своих кешах (только если HTTP-заголовки Cache-Control и Expires не препятствуют этому) и в будущем всегда использовать новый адрес ресурса.
302 (temp) . Адрес ресурса временно изменён. Клиенты и прокси-серверы НЕ должны обновлять информацию в своём кеше и в будущем всегда проверять предыдущий адрес ресурса, прежде чем выполнять перенаправление (только если HTTP-заголовки Cache-Control и Expires не препятствуют этому).
303 (seeother) . Ресурс был замещён другим ресурсом и клиент должен выполнить перенаправление, используя метод GET, независимо от того, какой метод использовался для запроса оригинального ресурса.
410 (gone) . Ресурс был удалён и более недоступен.
Если статус-аргумент будет опущен, то по умолчанию будет использоваться 302-редирект. На самом деле вы можете использовать любой HTTP-статус, а не только четыре из представленных выше. Помните только, что если вы используете HTTP-статус, не попадающий в диапазон 300-399, последний аргумент директивы должен быть опущен.
Директива RedirectMatchЭта директива, как уже все догадались, работает подобно предыдущей, но позволяет пользоваться регулярными выражениями при определении условий, предоставляя больше гибкости в настройке поведения редиректа. Ради примера давайте рассмотрим следующее правило:
RedirectMatch (.*)\.gif$ http://www.example-site.com$1.gif
Здесь все запросы адресов, оканчивающихся.gif , будут перенаправлены в корень другого сервера.
Так же, как и предыдущая директва, RedirectMatch принимает опциональный параметр HTTP статус-кода. В примере выше он не указан, и поэтому будет использоваться код 302.
Также, в семействе Redirect* есть ещё две директивы: RedirectPermanent и RedirectTemp , которые семантически эквиваленты выражениям Redirect permanent и Redirect temp соответственно.
Порядок обработки директивЕсли вы не хотите получить неожиданного поведения сервера при работе с редиректом и алиасингом, вы должны знать о том, что инструкции редиректа обрабатываются перед инструкциями алиасинга , если они были одновременно обнаружены в одном и том же контексте (например в пределах оного и того же контейнера или ).
Когда сервер получает запрос, подходящий под условие Redirect или RedirectMatch , то инструкции этих директив будут обработаны прежде, чем инструкции директив Alias и AliasMatch . Это означает то, что в подобных ситуациях директивы Alias* никогда не будут срабатывать, поскольку будет выпоняться редирект.
Второй момент, о котором всегда всегда помнить, это то, что директивы Alias* и Redirect* применяются в том порядке, в котором они появляются . По этой причине зачастую более разумно определять более общие правила в последнюю очередь. Например инструкции:
Alias /sub-dir1/sub-dir2 /dir3 Alias /sub-dir1 /dir4
НЕ будут работать так же, как и:
Alias /sub-dir1 /dir4 Alias /sub-dir1/sub-dir2 /dir3
поскольку Alias /sub-dir1 /dir4 будет срабатывать всегда до того, как дойдёт очередь до Alias /sub-dir1/sub-dir2 /dir3 .
Доброго времени суток друзья! Давай с Вами рассмотрим регистрацию пользователей на PHP. Для начала давайте определим условия для нашей регистрации пользователей:
- Пароль шифруем при помощи алгоритма MD5
- Пароль будем "солить"
- Проверка на занятость Логина
- Активация пользователя письмом.
- Запись и хранение данных в СУБД MySQL
Для написание данного скрипта нам нужно понять, что такое регистрация пользователя. Регистрация пользователя - это получения данных реального пользователя, обработка и хранение данных.
Если объяснять простыми словами то регистрация это всего лишь запись и хранение определенных данных по которым мы можем авторизировать пользователя в нашем случае - это Логин и Пароль.
Авторизация — предоставление определённому лицу или группе лиц прав на выполнение определённых действий, а также процесс проверки данных прав при попытке выполнения этих действий. Проше говоря с помощью авторизации мы можем разграничить доступ к тому или иному контенту на нашем сайте.
Рассмотрим структуру каталогов скриптов для реализации нашей регистрации с авторизацией. Нам нужно разбить скрипты на логические составляющие. Модули регистрации и авторизации мы поместив в отдельный каталог. Так же в отдельные каталоги мы поместим подключение к базе данных MySQL , файл с пользовательскими функциями, файл стилей CSS и наш шаблон HTML . Данная структура позволяет быстро ориентироваться в скриптах. Представьте себе, что у Вас большой сайт с кучей модулями и т.д. и если не будет порядка, то будет очень сложно что-то отыскать в таком бардаке.
Так как мы будем хранить все данные в СУБД MySQL , то давайте создадим не большую таблицу в которой будем хранить данные о регистрации.
Для начала нужно создать таблицу в базе данных. Таблицу назовем bez_reg где bez - это префикс таблицы, а reg название таблицы.
Структура таблицы: bez_reg -- -- Структура таблицы `bez_reg` -- CREATE TABLE IF NOT EXISTS `bez_reg` (`id` int(11) NOT NULL AUTO_INCREMENT, `login` varchar(200) NOT NULL, `pass` varchar(32) NOT NULL, `salt` varchar(32) NOT NULL, `active_hex` varchar(32) NOT NULL, `status` int(1) NOT NULL, PRIMARY KEY (`id`)) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ; Теперь создадим основные скрипты для дальнейшей работы. Файл INDEX.PHPФайл CONFIG.PHP
less/reg/?mode=auth">Войти