Что такое url синоним

Справа вы увидите поле для настройки синонима. В нем как раз и можно задать то как будет выглядеть ссылка. Например укажем в поле «news/новость-про-ломтик-бекона»

Доработанная и исправленная статья о формировании красивых синонимов URL в Drupal. Рассматривается возможность совместного использования модулей Path, Pathauto и CCK.

В начале был Path.

Вероятно, вы уже знаете, что в Drupal встроен модуль Path (по умолчанию выключен), позволяющий создавать синонимы (то есть — псевдонимы или алиасы) для документов. После включения модуля при создании или редактировании документа становится доступным дополнительное поле «Настройки адресов». В этом поле можно указать альтернативный синоним URL для документа. То есть, если страница «Мои друзья» на вашем сайте имеет фактический адрес www.mysite.com/node/17, а вам нужно, чтобы адрес был вроде www.mysite.com/aboutme/myfriends, то всё, что следует сделать — просто указать синоним aboutme/myfriends в этом поле (именно так, то есть — всё, что ниже «корневого» слеша):

Drupal сохранит этот связанный синоним в базе, и все последующие ссылки на документ будут формироваться уже с учетом определенных для него синонимов. Также имеется возможность назначать синонимы для категорий (терминов таксономии), заменяя taxonomy/term/term_id на что-то более понятное человеку.

Всё это так, и написано об этом тоже уже много. Но мне этого недостаточно. Я искал возможность максимально автоматизировать формирование алиасов, вместе с тем сохранив определённую гибкость в их создании. Попробую объяснить, что же именно я хотел.

Задачи.

Итак, я бы хотел:

1. Сделать формирование всех алиасов максимально прозрачным, с тем, чтобы ввод синонима URL или не требовался (пусть Drupal сделает это за меня) или же был предельно простым.
2. Мне нравится, когда URL’ы включают в себя расширение «.html». Согласен, это мега-архаизм и излишество, но такая уж у меня слабость. В общем, я хочу, чтобы все сформированные Drupal’ом ссылки на моем сайте имели на своём конце старое доброе «.html».
3. Заставить Drupal формировать синонимы URL, учитывающие принадлежность документа к определенной категории (т.е. термину таксономии) и соответственно наследующие синоним, ранее определённый мною для этой категории.
4. Наконец, определить различные правила формирования синонимов для различных типов содержания.
   • Например, я бы хотел, чтобы для блоговых нодов это было наподобие: blog/5.html, …, blog/25.html, …, blog/278.html, и т.д. и т.п. То есть URL должен включать в себя nid документа (или, возможно, дату).
   • Для других же, статических типов содержания, мне нужна была возможность явно указать синоним непосредственно документа (например, «myarticle»), а на Drupal переложить все заботы, связанные с формированием и включением в URL синонима категории (или полного «пути») перед документом и любимого мною «.html» на конце. В итоге должно было получаться что-то вроде articles/all/myarticle.html.

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

Автопилот: Pathauto.

Модуль Pathauto действительно был создан для целей, связанных с автоматизацией формирования синонимов в Drupal. Включённый модуль «прозрачно» делает свою работу при каждом сохранении документа. Возможностей у него достаточно много. Основной функционал модуля построен на шаблонах преобразования синонима, определяемых пользователем для отдельных (или всех) типов содержания.

Шаблон представляет собой комбинацию из динамических компонентов или фрагментов статического текста. Доступные для включения в шаблоны компоненты перечислены в довольно объёмном списке, находящемся ниже этих полей. В качестве таковых, например, могут выступать: заголовок документа, дата и время его создания, название категории или словаря, синоним категории, название меню, к которому относится документ и ещё ряд других компонентов. Я не буду здесь приводить этот список, он действительно длинный, но всё же советую вам внимательно с ним ознакомиться

Кроме того, в Pathauto встроен механизм транслитерации заголовков документов для компонента [title]. При желании вы сможете автоматически получать URL’ы вроде «kak-ya-otdihal-s-druzyami-na-more», базирующиеся на тексте заголовка. Для корректной работы этого механизма с русским языком следует переименовать файл i18n-ascii.example.txt в папке модуля в i18n-ascii.txt.

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

Итак, Pathauto допускает использование синонимов категорий ([catalias]) в качестве компонента шаблонов. Это хорошо, и значит, я смогу использовать эту особенность для формирования «пути» к документу, включающего в себя синоним термина таксономии, к которой относится материал. Также есть возможность сформировать URL’ы, комбинирующие синоним категории («путь») и дату создания документа, или его nid или ещё какой-либо компонент, и, наконец, моё любимое «.html» (!) в конце. На первый взгляд в нём есть всё то, что я хотел.

Однако, не всё. Если вы помните, я также хотел иметь возможность создавать свои синонимы для некоторых типов материалов. Но как «научить» Pathauto добавлять к автоматически формируемому «пути» мой синоним?

Здесь есть одна проблема, которая перечёркивает многие преимущества модуля, по крайней мере — в моём случае. Pathauto формирует всё, что от него требуется, но при этом обновляет все системные синонимы документа, привязывая вновь созданные модулем. И, к сожалению, модуль Pathauto не может использовать ранее назначенный синоним документа как компонент шаблона. Таким образом, все ваши попытки непосредственно указать синоним в поле «Настройка адресов» после первого же сохранения документа будут сведены на нет. А что делать, если, как я уже писал, я хочу сам назначать синонимы для документов определённого типа?

Выходит, что модуль Pathauto в чистом виде идеально подходит для автоматических машинно-правильных адресов. В моём случае это пригодилось бы при формировании URL’ов для блоговых нодов или других видов динамического содержания. Но для тех материалов, которые мне хотелось бы подавать как статические страницы, мне нужно нечто большее.

Гибкий рецепт: Path + Pathauto + CCK.

Каков же выход?

Выход в поиске способа предоставить модулю Pathauto информацию о предпочтительном URL документа. Эта информация должна быть сохранена вместе с документом, но отдельно от стандартного поля настройки адреса. Здесь мне поможет мощный инструмент для создания пользовательских полей в нодах Drupal’а — модуль CCK. Этот модуль позволяет добавлять различные виды полей к любым типам содержания и сохранять введенные в них данные в базе, как дополнительные данные для каждого нода. Это именно то, что мне нужно, поскольку CCK экспортирует имена полей в Pathauto в качестве возможных компонентов для шаблона преобразования.

• Итак, устанавливаю модуль CCK. Поскольку CCK является не отдельным модулем, а группой таковых (каждый из которых служит для создания и управления отдельным типом полей), то на странице управления модулями Drupal я включаю только два модуля из набора: Content и Text.
• После включения модуля на странице описания любого из имеющихся типов содержания появляется дополнительный пункт меню – «Fields».
• Для моих целей удобнее всего использовать тип содержания Page. Но я, пожалуй, создам новый тип содержания для своих статических страниц. Просто чтобы не было путаницы.
• Создаю новый тип документов, называю его, скажем – MyStaticPage и присваиваю ему машинное имя my_static_page. Затем открываю страницу добавления дополнительных полей CCK для этого типа.
• Добавляю новое поле типа Text, называю его, скажем: MyURL.
• В свойствах поля указываю – «Обязательно». Это значит, что поле должно быть обязательно заполнено пользователем (ведь мы же не хотим, чтобы Pathauto формировал «отсебятину» в случае пустого поля, верно?).
• Теперь при создании или изменении материалов типа MyStaticPage нам доступно специальное поле для ввода URL, в нём я и буду указывать мой синоним для документа.
• Перехожу к модулю Pathauto. В настройках «Node path settings» теперь появилось новое поле «Pattern for all MyStaticPage paths:». Вот здесь-то нам и нужно указать …что? Смотрим ниже список всех доступных компонентов. Вот оно: «[field_myurl]».
• Этот компонент использует информацию, сохранённую в нашем новом текстовом поле, его нам и нужно указать. Вводим шаблон: «[catalias]/[field_myurl].html».
• Для остальных, «нестатических», типов ставлю шаблон «[catalias]/[nid].html». То есть, это просто id документа внутри Drupal’а, мне так нравится. Можете поменять на дату, или на что-то другое.
• Поскольку теперь мне нужно обновить таблицу синонимов Drupal’а для имеющихся документов, я включаю опцию «Bulk update node paths» (можете пропустить, если у вас ещё нет документов), а также опцию «Create feed aliases» для формирования таких же синонимов в RSS фидере.
• Мне не нужно автоматическое формирование синонимов категорий (я предпочитаю их указывать сам), а потому во избежание путаницы я очищаю все поля в секции «Category path settings».
• Сохраняю настройки.

Теперь URL’ы всех новых страниц типа MyStaticPage будут автоматически формироваться Drupal’ом, комбинируя синонимы категорий, в которые они включены, и синонимы, определенные мною в поле MyURL при создании документа.

Последнее «но».

Осталось ещё одно «но». Модуль CCK при отображении документа с пользовательскими полями выводит также название поля и его содержание, что не есть хорошо. Они отображаются как в теле тезауруса, так и при просмотре документа.

Настройки модуля, к сожалению, не допускают возможности скрыть содержание поля при просмотре документа. Но выход всё-таки есть. Модуль CCK позволяет подключать собственные шаблоны для визуализации полей модуля, в которых при желании можно просто …ничего не выводить. Это позволит отключить отображение и названия поля и его данных. Для этого потребуется простейшая модификация файла template.php из вашей темы оформления. Эта процедура описана в файле readme.txt, находящемся в папке модуля CCK: modules/cck/theme/readme.txt, на основании этого файла я и опишу все последующие шаги.

Итак, находим в папке modules/cck/theme/ файл template.php. Как видите, он содержит единственную функцию phptemplate_field:

Аккуратно копируем весь код функции и вставляем в конец файла template.php текущей темы оформления. Сохраняем файл. Добавленная функция переопределяет стандартную процедуру вывода полей CCK и «сообщает» модулю CCK, что забота о выводе полей теперь ложится на пользователя.

В соответствии с описанием, в папке текущей темы также нужно создать файл field-field_myurl.tpl.php (помните, что поле в моём примере выше называется field_myurl?). Этот файл — просто шаблон, в котором можно определить, как именно поле CCK будет отображаться в браузере, то есть, HTML-обвязку выводимых данных поля. Поскольку нам ничего не нужно выводить (мы хотим скрыть поле), то создаём пустой файл, а лучше — вообще ничего не создаём (ничего страшного не произойдёт). Для интереса можете посмотреть как может выглядеть шаблон вывода поля, открыв файл modules/cck/theme/field-field_body.tpl.php.

На этом настройка закончена. Помните о том, что, поскольку мы переопределили функцию вывода полей CCK, в будущем вам придётся создавать шаблоны вывода для всех новых полей CCK, иначе они отображаться не будут. Либо определить дополнительно общий шаблон для вывода полей CCK (field.tpl.php). Подробности — в файле modules/cck/theme/readme.txt.

Что же касается меня, то я совершил святотатство, надругавшись над своим модулем content.module из набора CCK, и вообще отключил вывод полей на уровне кода модуля. Я могу себе это позволить, поскольку поля CCK у меня пока больше нигде не используются. При необходимости я вернусь к способу скрытия полей CCK с помощью тем.

Время на прочтение
8 мин

Количество просмотров 2.9K

В прошлом году Дэниэл Стенберг, создатель curl, написал пост об одном забавном URL:

http://http://http://@http://http://?http://#http://

Пост интересен, рекомендую его прочитать. Автор объясняет, как устроен URL, и как различные системы его обрабатывают.

Но в том посте не разобрано, в частности, как сказывается такая разница в обработке одних и тех же URL различными системами. В этой лекции 2017 года (слайды, видео) Оранж Цай рассматривает и многие другие несогласованности между различными библиотеками, а также риски из области безопасности, возникающие из-за такой несогласованности.

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

Элементы URL

Как в вышеупомянутом посте, так и в лекции, на которую я обратил ваше внимание, сказано, что определить URL непросто. Для этого существует RFC, спецификация WHATWG и множество разношёрстных реализаций.

В самом общем виде URL состоит из следующих частей:

scheme://username:password@host:port/path?query#fragment

• scheme: используемый протокол (например, http или https).

• username:password: Сайты, на которых используется базовая схема аутентификации, позволяют при аутентификации вставлять ваши имя пользователя и пароль прямо в URL. Такая практика считается очень небезопасной, поэтому не так много сайтов, где она поддерживается.

• host: Это домен или IP-адрес, к которому вы хотите подключиться (например, google.com или 127.0.0.1).

• port: порт напоминает номер абонентского ящика, и по этому номеру можно связаться с хостом. Если такого порта нет, то по умолчанию в такой схеме используется 80 для http и 443 для https).

• path: это конкретная веб-страница на хосте. Например, путь к оригиналу этой статьи — /posts/what-is-a-url.html

• query: это коллекция параметров, обычно представленных в форме пар key=value, которые объединяются знаком &. Они используются для отправки на сервер более конкретной информации.

• fragment: обычно используется в качестве якоря для перехода в конкретный раздел документа. Например, именно к этому разделу можно перейти по ссылке #parts. Правда, обратите внимание, что сервер не видит этого фрагмента. Он обрабатывается (или игнорируется) именно на стороне клиента.

Отличия и сложности

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

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

Запрос или имя пользователя

http://1.1.1.1 &@ 2.2.2.2# @3.3.3.3/

Как следует распарсить этот URL?

• Если хост — это 1.1.1.1, то всё после & (@ 2.2.2.2) — запрос, а остальное — фрагмент, поскольку идёт после #. Именно такое поведение было встроено в библиотеку Python urllib2.

• Если хост — это 2.2.2.2, то всё до первого @ (1.1.1.1 &)  — это имя пользователя, а всё после # (@3.3.3.3/) — это фрагмент. Это поведение библиотеки requests на Python.

• Если хост — это 3.3.3.3, то всё до второго @ (1.1.1.1 &@ 2.2.2.2#) — это имя пользователя. Таково поведение встроенной библиотеки Pythonurllib.

Разумеется, мы видим, как такая нестрогая реализация, в которой якобы реализуется стратегия достижения цели «малой кровью», может логически выйти на любой из трёх вариантов. Современные реализации requests и urllib сошлись на том, что нужно трактовать 1.1.1.1 &@ 2.2.2.2 как хост (urllib2 в Python 3 не существует, поэтому больше не поддерживается).

Порт или путь

http://127.0.0.1:5000:80/

Как же должен быть разобран этот URL?

• Если порт 5000, то путь :80/. Именно такое поведение было свойственно вызову readfile в PHP.

• Если порт 80, то хост 127.0.0.1:5000. Именно так действовал parse_url в PHP.

Путаница с хостами

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

Хост может выглядеть, как доменное имя, например google.com, как адрес IPv4, например 127.0.0.1, или как адрес IPv6, например ::1. Как с IPv4, так и с IPv6 бывают особые случаи, и применяются особые правила форматирования, и поддерживаться они могут несогласованно. Например, в самом документе RFC подчёркиваются возможные рассогласования при синтаксическом разборе адресов IPv4:

• В некоторых реализациях поддерживается менее 4 частей. В адресе с тремя полями последнее значение трактуется как 16-разрядное (127.0.1). В адресе с двумя полями последнее значение трактуется как 24-разрядное (127.1). Если в адресе 1 часть, то всё это значение разбирается просто как единое 32-разрядное целое число (2130706433).

• Есть и такие реализации, в которых каждая часть также может быть представлена в десятичном (127), восьмеричном (0177) или шестнадцатеричном формате (0x7F)

Итак, в зависимости от реализации http://2130706433 может считаться (или не считаться) равным http://127.0.0.1

Риск

Да, конечно, какие-то разбежки существуют, но в чём реальная проблема? Просто не надо делать странных URL — и вы не столкнётесь с пограничными случаями.

Проблема в том, что иногда приходится иметь дело с URL, которые составлял кто-то другой. В особенности, люди, которым вы не доверяете — их ещё называют «пользователями».

Защита Localhost

Представьте, что строите систему на основе вебхуков. Ваши пользователи предоставляют вам URL, и всякий раз при определённом событии вы отправляете HTTP-запрос по данному URL.

В подобной системе возникает риск, связанный с подделкой запросов на стороне сервера (SSRF), так как пользователь может заставить вас отправить запрос в случае, когда для вас это нежелательно. Например, у вас на порту 9000 может работать какой-нибудь критически важный сервис. Но, если пользователь установит URL-вебхук на http://localhost:9000/shutdown, то ваша система вебхуков отправит этот http-запрос критичному сервису, и сделает это изнутри сети!

Чтобы предотвратить подобные случаи, можно написать, например, такой код:

def call_webhook(url):
  parts = urllib.parse.urlparse(url)
  if isLocalHost(parts.hostname):
    raise Exception("localhost is not allowed!")
  requests.get(url)

Как мы реализуем isLocalHost? Для начала давайте побеспокоимся только об IP-адресах. Можно вспомнить различные сложности, возникающие при предоставлении адресов IPv4 и IPv6. Поэтому не будем сравнивать их с конкретными строками, а лучше преобразуем адреса в десятичное представление и сравним десятичные значения (как рекомендовано в RFC). Таким образом, все 127.0.0.1, 127.0.1 и 127.1 будут отображаться на одно и то же значение: 2130706433. В таком случае код может принять вид

def isLocalHost(hostname):
  if isIPv4(hostname):
    decimal = int(ipaddress.IPv4Address(hostname))
    return decimal == 2130706433
  if isIPv6(hostname):
    decimal = int(ipaddress.IPv6Address(hostname))
    return decimal == 1
  return False

Это уже выглядит довольно хорошо, за такой код можно и по плечу программиста похлопать. Но злоумышленник берёт и посылает нам URL: http://0:9000/shutdown. Как разобрано на приведённых выше слайдах, 0 в Linux отображается на localhost! Поскольку 0 не равно 1 или 2130706433, этот запрос проходит нашу валидацию.

Мы последователи дополнительным советам, содержащимся в спецификации, и всё равно облажались.

Список разрешённых доменов

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

Код для такой операции может выглядеть примерно так:

def pull_data(url):
  parts = urllib.parse.urlparse(url)
  hostname = parts.hostname
  if hostname != "companyname.s3.amazonaws.com":
    raise Exception("Only companyname bucket allowed")
  
  data = requests.get(url, AWS_KEY_FOR_BUCKET)
  return analyze(data)

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

Правда, всё равно сохраняется проблема. Предположим, пользователь присылает нам такой URL:

http://malicious-website.com#@ companyname.s3.amazonaws.com

Для валидации URL и для отправки HTTP-запроса мы пользуемся разными библиотеками. Как было указано выше, по данным urllib хост-имя — это companyname.s3.amazonaws.com, но библиотека requests отправила бы запрос на вредоносный сайт malicious-website.com! Хуже того, этот запрос содержал бы ключ к AWS API, что открыло бы злоумышленнику полный доступ к нашей корзине!

Hidden text

Это сработало бы лишь в случае, если вы пользуетесь короткоживущими сеансовыми токенами. Если генерировать сигнатуры, специфичные для каждого запроса, то становится гораздо сложнее повторно использовать учётные данные. 

Именно такой риск возникает из-за несогласованного парсинга URL от системы к системе и от библиотеки к библиотеке.

Так что же?

Те уязвимости, что я упомянул выше, были найдены и исправлены в 2016/2017. Но сама проблема никуда не исчезла. Вот баг от декабря 2022, из библиотеки, использующей requests; она отправляла бы запросы по поводу http://domain:0 на заданный по умолчанию порт: http://domain:80. Вот баг от мая 2022, найденный в curl, который привёл бы к отправке запроса http://example.com%2F10.0.0.1/ на http://example.com/10.0.0.1/.

В обеих этих ситуациях нашу валидацию можно было бы обойти. В URL указан порт 80? Нет. В URL содержится хост-имя example.com? Нет. И, всё-таки, запрос пошёл бы, соответственно, на порт 80 и к домену example.com.

Поэтому, если данная проблема никуда не девается, что мы можем сделать? Ответ такой же как и с большинством бед из области безопасности: не доверяйте пользовательскому вводу. Но в идеале недоверие пользовательскому вводу должно быть предусмотрено ещё на уровне архитектуры. Возвращаясь к ситуации, где пользователь отправлял нам URL на корзину S3, нам нет никакого резона принимать от пользователя полный URL. Пусть пользователь пришлёт вам какой-нибудь идентификатор файла, а затем вы сами соберёте URL у вас в коде.

Hidden text

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

Пример с вебхуками гораздо сложнее. В шпаргалке OWASP, помогаюшей предотвращать подделку запросов на стороне сервера, даются рекомендации на такой случай, но даже в этом документе случай с вебхуками описан весьма туманно. Думаю, максимум, что можно сделать — изолировать сервис и лишить его привилегий при вызове вебхуков. Таким образом, если сервис всё-таки обманом заставят выполнять вебхуки, у него не будет доступа по сети к другим компонентам, а если и будет, то сервис не будет обладать нужными привилегиями, которые позволили бы ему повлиять на систему.

Молодежный словарь

Этот сайт-словарь предназначен для поиска новых слов, которые сейчас все чаще и чаще появляются, возможно вас всегда интересовало кто такие зумеры? Или хотите лучше понять своего ребёнка? Тогда вы попали по адресу. Как пользоваться нашим Словарём? Всё очень просто, введите в поиск любую часть слова и вы увидите все слова с этим префиксом, а так же можно просто нажимать по разделам меню.

Посмотри так же сайт с аниме

USERAGENT →← UPTOLIKE

Смотреть что такое URL в других словарях: