Александр Никитин

Не доверяй ИИ

2025-02-25T18:50:00.354Z

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

Це была фабула. А дальше мой короткий рассказ. 😅

Понадобилось мне стало быть в логи nginx пихнуть кусок (именно кусок, а не всю строку ибо там чувствительные данные) строки из заголовка http запроса. Пошёл читать документацию. Понял что необходимое мне можно извлечь из одной переменной в другую через директиву map. И вот я два часа "беседовал" с perplexity/openai-o3 которые отчаянно меня убеждали что результат регулярки (match) или именованную группу нельзя использовать как результат map. И действительно приведенный пример конфига nginx не принимал за валидный конфиг. После чтения документации и пары статей на хабре, в комментариях я таки нашел пример, который натолкнул меня на решение моей задачи, которая в итоге решилась и оказалась простой и элегантной (ввиду простенькой регулярочки которую я уже накидал сам).

В качестве эпилога хочу вам пожелать не верить всяким ИИ, даже если они утверждают что что-то не будет работать. 😁 доверяйте своему инженерному чутью!

У меня всё.

Управление CurrentConfig через nbshell

2025-01-13T16:37:14.955Z

Опытные пользователи Netbox наверняка сталкивались с таким мощным инструментом как Netbox Shell (построенный на базе Django Shell и представляющий собой интерпретатор iPython с расширенной функциональностью).

Управление в интерактивном режиме

Чтобы запустить nbshell необходимо открыть в командной строке папку с дистрибутивом приложения и, активировав virtual environment, выполнить команду python netbox/manage.py nbshell

Что бы получить текущую ревизию конфигурации приложения (которая и содержит динамически конфигурируемые параметры) нам понадобится ID текущей (активной) конфигурации, ее можно получить из кэша приложения:

from django.core.cache import cache

activeRevision = ConfigRevision.objects.get(pk=cache.get('config_version'))

Объект activeRevision будет содержать объект типа ConfigRevision, являющийся активной конфигурацией в данный момент ("Curren configuration"). Объект простой, в поле data содержит словарь с динамически конфигурируемыми параметрами (список всех параметров и их значение можно подсмотреть в официальной документации). Однако просто изменить текущую конфигурацию нельзя, конфигурация будет применена только к новой ревизии конфигурации, а значит нам нужно ее создать.

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

Для примера мы включим параметр MAINTENANCE_MODE, переведя таким образом приложение в режим обслуживания.

# Хорошим тоном будет записать смысл новой ревизии конфига в комментарий
# Заполняем все параметры из текущей конфигурации
newRevsion = ConfigRevision(comment='Enable MM', data=activeRevision.data)
# Изменяем нужный нам параметр
newRevsion.data['MAINTENANCE_MODE'] = True
# Валидируем нашу модель конфигурации на соответствие модели данных,
# заложенных разработчиком
newRevsion.full_clean()
# Сохраняем новую конфигурацию (она автоматически станет активной)
newRevsion.save()

Управление в режиме скрипта

Данный код можно склеить в одну строку, разделив строки точкой с запятой ; и передать одним аргументом для nbshell.

python netbox/manage.py nbshell -c "from django.core.cache import cache; activeRevision = ConfigRevision.objects.get(pk=cache.get('config_version')); newRevsion = ConfigRevision(comment='Enable MM', data=activeRevision.data); newRevsion.data['MAINTENANCE_MODE'] = True; newRevsion.full_clean(); newRevsion.save();"

Для мультинодовых конфигураций

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

UPD: Работа с существующей конфигурацией

Если же хочется изменить какую-то текущую конфигурацию или просто сделать ее активной (например, откатиться на предыдущую), то сделать это можно через встроенный метод класса ConfigRevision - activate()

revision = ConfigRevision.object.get(pk=revisionNumber)
revision.activate()

Авторизация в Netbox через Keycloak (кастомный pipeline)

2025-01-04T20:53:43.008Z

В сети есть хороший мануал по настройке авторизации в Netbox через Keycloak, однако он хорошо подходит для новых инсталляций, когда у вас чистая БД, ну или размер таблицы с пользователями и группами не очень большой и вам не составит труда все переделать.

Сложность, с которой я столкнулся, заключалась в том, что используемая нами инсталляция Netbox имеет множество активных пользователей импортированных из Active Directory, активную ролевую модель основанную на группах из Active Directory и потерять все эти ассоциации очень не хотелось бы.

Изучая документацию на модуль python-social-auth (а также код самого модуля и его бэкэнд к Keycloak) я наткнулся на раздел Extending the Piplene и понял что весь конвеер авторизации легко настраивается и изменяется, однако придётся немного по-питонить.

Проблемы с которыми я столкнулся

Собственно их было две:

Дефолтный Pipeline падает при наличии в Netbox пользователей с одинаковыми email (это специфический случай, который характерен для нашей организации и с которым вы можете никогда не столкнуться. Для снятия лишних вопросов скажу что, у нас есть правило записывать в поле email соответствующий email владельца технической учётной записи)
Дефолтный Pipeline не обновляет членство в группах (а вот это уже критично для ролевой модели доступа основанной на группах).

Дефолтный Pipeline

Дефолтный pipeline для Netbox определяется в модуле <your-netbox-folder>/netbox/netbox/settings.py и выглядит так:

SOCIAL_AUTH_PIPELINE = (
    'social_core.pipeline.social_auth.social_details',
    'social_core.pipeline.social_auth.social_uid',
    'social_core.pipeline.social_auth.social_user',
    'social_core.pipeline.user.get_username',
    'social_core.pipeline.social_auth.associate_by_email',
    'social_core.pipeline.user.create_user',
    'social_core.pipeline.social_auth.associate_user',
    'netbox.authentication.user_default_groups_handler',
    'social_core.pipeline.social_auth.load_extra_data',
    'social_core.pipeline.user.user_details',
)

Он содержит функции из дефолтного, для модуля python-social-auth, конвеера, за исключением функции user_default_groups_handler из модуля <your-netbox-folder>/netbox/netbox/authentication.py (строка 'netbox.authentication.user_default_groups_handler').

Решение проблемы №1

В первых трех функциях Pipeline происходит получение и декодирование JWT access_token из которого извлекаются различные поля, которые передаются клиенту (в нашем случае Netbox) от Keycloak, и помещаются в переменную details (dict содержащий данные о пользователе, на базе которых пайплайн должен будет создать или обновить данные пользователя Netbox).

Функция get_username создает на базе совокупности различных настроек приложения и модуля python-social-auth имя пользователя, а функция associate_by_email пытается по email найти в БД Netbox соответствующего пользователя.

Функция associate_by_email выглядит так:

def associate_by_email(backend, details, user=None, *args, **kwargs):
    """
    Associate current auth with a user with the same email address in the DB.

    This pipeline entry is not 100% secure unless you know that the providers
    enabled enforce email verification on their side, otherwise a user can
    attempt to take over another user account by using the same (not validated)
    email address on some provider.  This pipeline entry is disabled by
    default.
    """
    if user:
        return None

    email = details.get("email")
    if email:
        # Try to associate accounts registered with the same email address,
        # only if it's a single object. AuthException is raised if multiple
        # objects are returned.
        users = list(backend.strategy.storage.user.get_users_by_email(email))
        if len(users) == 0:
            return None
        elif len(users) > 1:
            raise AuthException(
                backend, "The given email address is associated with another account"
            )
        else:
            return {"user": users[0], "is_new": False}

Очевидно, что при наличии в в БД нескольких пользователей в одинаковым email эта функция упадёт.

Чтобы решить эту проблему я создал новый модуль и переписал эту функцию так, чтобы использовать для ассоциации не только поле email но username.

import re
from social_core.exceptions import AuthException


def associate_by_email_and_username(backend, details, user=None, *args, **kwargs):
    """
    Associate current auth with a user with the same email address and username in the DB.
    """
    if user:
        return None
    email = details.get("email")
    username = details.get("username")
    # If username in upn format, get username part
    if m:=re.match(r"^(?:(?P<username>[^@]+)@(?P<domain>.+))quot;, username):
        username = m.group('username')
    if email:
        users = list(backend.strategy.storage.user.get_users_by_email(email))
        if len(users) == 0:
            return None
        elif len(users) > 1:
            for u in users:
                if u.username == username:
                    return {"user": u, "is_new": False}
            raise AuthException(
                backend, "The given email address is associated with another account"
            )
        else:
            return {"user": users[0], "is_new": False}
    else:
        raise AuthException(backend, "No email address returned")

Функция извлекает из словаря details username, если он в формате userPrincipalName - извлекает из него username часть и при наличии в БД Netbox пользователей с одинаковым email проводит дополнительную проверку по полю username.

Остается только собрать пакет из модуля, импортировать его в venv окружение, в котором работает Netbox, и переопределить в настройках приложения Pipeline (об этом расскажу ниже).

Решение проблемы №2

Изучив встроенную функцию netbox.authentication.user_default_groups_handler я понял что она назначает пользователю только группы определенные в переменной REMOTE_AUTH_DEFAULT_GROUPS из configuration.py. Я принял решение заменить эту функцию в конвеере совместив с функциональностью обновления групп, полученных от Keycloak.

Код этой функции будет выглядеть так:

Важно! Для того чтобы эта функция корректно работала access_token, который возвращает ваш Keycloak после авторизации, должен содержать поле groups с массивом имён групп. Если этого поля нет или оно содержит пустой массив - пользователю Netbox будут сброшены все связи с группами, а новых связей создано не будет.

import logging
from django.conf import settings
from django.contrib.auth.models import Group

def update_user_groups(backend, response, user=None, *args, **kwargs):
    """
    Custom pipline handler with adds remote auth users to extist groups or
    create non-exist groups
    """
    logger = logging.getLogger(
        "netbox-social-auth-custom.auth_username.update_user_groups_handler"
    )
    if not user:
        return None
    else:
        user_groups = []
        auth_groups = response.get("groups", [])
        user.groups.clear()

        # Add or Create DEFAULT USER GROUPS defined in configuration.py
        for name in settings.REMOTE_AUTH_DEFAULT_GROUPS:
            group, created = Group.objects.get_or_create(name=name)
            user_groups.append(group)

        # Add or Create Social Auth user groups
        # groups should be added to access token as array (list) of names
        for name in auth_groups:
            group, created = Group.objects.get_or_create(name=name)
            user_groups.append(group)

        if user_groups:
            user.groups.add(*user_groups)
        else:
            logger.info(
                f"No any groups assignments for {user}. May be REMOTE_AUTH_DEFAULT_GROUPS incorrectly set\
                  or not returned from OAuth provider"
            )

Переопределение Pipeline

Итак, обе функции помещены в файл, который я назвал auth_username.py, сложены в папки netbox-social-auth-custom/pipeline (вторая папка больше для красоты в названии - обозначения что это часть pipeline по аналогии с модулем social_core) и из этого собран python package (как собирать python-пакеты я описывать не буду, т.к. для этого есть куча разного инструментария и соответствующих гайдов - например такой, разве что подскажу, что не плохо бы при сборке указать зависимость от social-auth-core>=4.5).

Пакет установлен в окружении venv нашего Netbox и остается только переопределить собственно сам Pipline. Для этого в файле configuration.py переопределяется переменная SOCIAL_AUTH_PIPELINE в виде вот такого массива:

SOCIAL_AUTH_PIPELINE = (
    'social_core.pipeline.social_auth.social_details',
    'social_core.pipeline.social_auth.social_uid',
    'social_core.pipeline.social_auth.social_user',
    'social_core.pipeline.user.get_username',
    'netbox_social_auth_custom.pipeline.auth_username.associate_by_email_and_username',
    'social_core.pipeline.user.create_user',
    'social_core.pipeline.social_auth.associate_user',
    'social_core.pipeline.social_auth.load_extra_data',
    'social_core.pipeline.user.user_details',
    'netbox_social_auth_custom.pipeline.auth_username.update_user_groups',
)

Собственно на этом всё. Спасибо что дочитали, надеюсь это кому-то пригодится.

UPD: Отладка Pipline

Забыл написать про отладку вашего (или вообще) конвеера авторизации. Чтобы в увидеть в логах или dev-консоли сервера Netbox

UPD: Отладка Pipline

Забыл написать про отладку вашего (или вообще) конвеера авторизации. Чтобы в увидеть в логах или dev-консоли сервера Netbox отладочную информацию добавьте в конец (или перед падающей функцией конвеера) строку

'social_core.pipeline.debug.debug',

Проверка аргументов (переменных) для роли Ansible

2024-09-23T07:09:41.534Z

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

С приятным удивлением обнаружил механизм, который в Ansible появился с релизом ansible-core 2.11 (апрель 2021) и называется он Role argument validation. Исходя из собственного опыта написания модулей Ansible, я предполагаю, что в данном механизме используется тот же самый код, что и при валидации аргументов модуля (по крайней мере, всё на это указывает).

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

ansible-doc --type role --roles-path <you roles path> <role_name>

Пример вызова такой роли:

Реализация

Для создания подобной функциональности используется файл meta/argument_specs.yml. Его формат описан в документации и довольно прост. Более того, у Вашей роли может быть не одна точка входа (по умолчанию это main.yml) но и дополнительные, возможно для вызова через ansible.builtin.import_role или ansible.builtin.include_role, набор параметров для каждой точки входа можно описать в этом файле. Также параметры можно пометить обязательными, указать тип данных (набор типов данных, которые умеет проверять AnsibleModule тут), который должен содержаться в параметре, его значение по умолчанию (если оно находится в ../defaults/<entry-point>.yml, например) ну и, конечно же, описание (short_description и description для точки входа и description для каждого параметра).

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

При вызове роли через ansible.builtin.import_role или ansible.builtin.include_role есть возможность отключить проверку аргументов, используя параметр rolespec_validate установленный в false.

Интересный cmdlet из модуля Microsoft.PowerShell.TextUtility

2024-09-23T07:04:41.097Z

Модуль Microsoft.PowerShell.TextUtility получил новый командлет ConvertFrom-TextTable. Он умеет превращать текстовую таблицу (типичный вывод большинства shell-команд Linux) в массив объектов. И даже больше - он может распарсить значения в столбцах таблицы и сконвертировать их в соответсвующие типы (например Int или Float, Boolean). Ну и наконец вместо объекта массива, командлет может вернуть массив строк в формате JSON.

Установить модуль можно из PowershellGallery:

Install-Module -Name Microsoft.PowerShell.TextUtility -AllowPrerelease

Пример использования:

PS> df | select -first 6 | convertfrom-texttable -ConvertPropertyValue | Format-Table

Filesystem 1K-blocks      Used Available Use% Mounted_on
---------- ---------      ---- --------- ---- ----------
none         8167564         4   8167560 1%   /mnt/wsl
none       498723140 443586308  55136832 89%  /usr/lib/wsl/drivers
none         8167564         0   8167564 0%   /usr/lib/wsl/lib
/dev/sdc   263112772  27894640 221779976 12%  /
rootfs       8164316      1936   8162380 1%   /init

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

PS> ls -l | select -First 5 | ConvertFrom-TextTable -Skip 1 -NoHeader | ft

Property_01 Property_02 Property_03 Property_04 Property_05 Property_06 Property_07 Property_08 Property_09
----------- ----------- ----------- ----------- ----------- ----------- ----------- ----------- -----------
drwxr-xr-x  3           ihumster    ihumster    4096        Aug         21          2022        aac-base
drwxr-xr-x  3           ihumster    ihumster    4096        Jul         20          23:48       ansible_collections
drwxr-xr-x  7           ihumster    ihumster    4096        Apr         30          15:43       ansible-module-vcloud-director
drwxr-xr-x  3           ihumster    docker      4096        Jun         14          2022        ansible-netbox-dev

Модуль еще находится в процессе разработки и если он вам понравился и пригодился, но вы нашли какую-либо ошибку, то оставить баг-репорт можно прямо в разделе Issues репозитория.

Нюансы обновления до VCD 10.4.1

2024-09-23T07:03:35.187Z

После обновления до VCD 10.4.1 одна из Advisores отсылает нас к KB78885 (но да кто их читает, да?), которая опубликована в далеком уже 2021 году и которая напоминает нам о том, что после обновления VCD у нас может пропасть доверненное подключение к различным элементам нашей инфраструктуры. Ужесточение требований к сертификатам в инфраструктуре началось в VCD еще с версии 10.1 (о чём так же отдельно пишется во врезке, на странице документации посвященной обновлению VCD).

В 10.4.1 ужесточили еще один аспект инфраструктуры, а именно подключение к ESXi хостам. В результате, после обновления до 10.4.1 (и автоматическом переходе на новую консоль, старую выпилили таки, и слава богу), в VCD перестанут работать операции требующие прямого доступа к хосту, а именно доступ к консоли ВМ, ипорту OVF/ISO, Guest Customization.

В логах это может отобразиться в виде следующих сообщений:

[ 88fc5c17-f0c7-4021-922b-5dfe1b84b7cd ] PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
 - PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
 - PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
 - unable to find valid certification path to requested target

 2023-02-24 02:59:01,050 | ERROR    | pool-jetty-81             | ServerWebSocket                | Connecting to ESX esx01.lab.ihumster.ru [server: [L=/192.168.168.25:443 R=/192.168.168.30:60004]] [client: [id: 0x13240ef6, L:/192.168.168.25:52056 ! R:esx01.lab.ihumster.ru/192.168.168.101:443]] |
io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Решение

Самый простой вариант - это запустить повторно CMT trust-infra-certs:

./cell-management-tool trust-infra-certs --vsphere --unattended
Downloading certificates for 2 host(s), including 1 vCenter(s):
        vc-mng.lab.ihumster.ru                                      [Download: SUCCESS] (VMCA)
        vc-mng.lab.ihumster.ru                                      [Download: SUCCESS] (VMCA)
        vc-mng.lab.ihumster.ru                                      [Download: SUCCESS]
        nsx.lab.ihumster.ru                                         [Download: SUCCESS]
Downloaded certificates for 3/2 host(s).
Trusting certificates for 2 host(s):
        vc-mng.lab.ihumster.ru                                       [Already Trusted: SUCCESS]
        nsx.lab.ihumster.ru                                          [Already Trusted: SUCCESS]
Trusting VMCA certificates for 1 vCenter(s):
        vc-mng.lab.ihumster.ru                                       [Add Trusted: SUCCESS] (VMCA) - alias=vc-mng.lab.ihumster.ru_vmca_2023-02-24-11-05-13
Trusted 3/3 downloaded certificates.

Или самостоятельно скачать с vCenters их сертификаты VMCA (<vcenter>/certs/download.zip) и вручную добавить VMCA сертификаты в Trusted Certificates вашего VCD.

Для VCD с большим количеством vCenters (или организаций с высокими требованиями к безопасности инфраструктурных компонентов) самым правильным путём, по моему мнению, будет вариант с заменой сертификата VMCA на vCenters на подписанный с внутреннего или внешнего CA и последующей регенерацией сертификатов ESXi.

VMware Cloud Director Availability Initial Setup API

2024-09-23T07:02:53.641Z

Встала задача по автоматизации развертывания VCDA для инсталляций VCD где VCDA еще не развернут. Начав изучение вопроса и прочтя внимательно документацию по VCDA с удивлением понял что для развертывания самих аплайнсов есть способ по автоматизации процесса, т.к. аплайнсы поставляются в формате OVF с обычными, для аплайнсов VMware, возможностями деплоя их как с помощью UI, так и с помощью OVFTool ну и прочими средствами (например, community.vmware.vmware_deploy_ovf из коллекции ansible). Но для дальнейшей первоначальной настройки нет иного официального пути, кроме как пойти в UI и потыкать кнопки, заполняя поля в Initial Setup Wizard.

Вооружившись DevTools я за несколько итераций записал все необходимые API вызовы, которые происходят при выполнении этапов Initial Setup Wizard и после, проверив возможность их воспроизведения сторонними средствами (воспроизводил в Postman) решил что хочу записать их в виде документации OpenAPI 3.0 что бы любой мог импортировать ее в Postman и ознакомиться с деталями запросов.

По этому спешу представить Вам первую версию документации к VCDA Initial Setup API. В репозиторий добавлена также готовая коллекция для Postman (на случай если вы не умеете генерировать коллекцию из OpenAPI спецификации).

В коллекции все запросы пронумерованы в порядке выполнения их в Wizard. Отдельно не пронумерован один Get запрос - он используется для проверки доступности той или иной системы (VCD, vCenter server, ReplicatorAppliance, Tunnel Appliance) из VCDA Manager, а также возвращает SSL-сертификат используемый системой (сам сертефикат в PEM-encoded формате, его thumbprint - используются в остальных запросах).

Конфигурация VCDA которую я изучал - это рекомендуемая в продуктивной среде конфигурация из отдельных "ролевых" аплайнсов - manager, replicator, tunnel. Для combined и vc_combined версии, последовательность и структура запросов скорее всего иная (в vc_combined например не используется VCD).

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

Для работы с этим API вам необходимы минимум 3 задеплоенных удобным вам способом аплайнса.

Комфортная работа в Postman с VMware Cloud Director (2)

2024-09-23T07:02:07.305Z

В процессе работы с OpenAPI разных версий VMware Cloud Director понял что меня раздражает постоянно следить за версией API, которая указывается в Header 'Accept'. Чтобы автоматизировать актуализацию версии API в моих запросах я модифицировал свой pre-request Script из предыдущей статьи.

Добавьте следующую строку между запросами версии и получением access_token, либо после них:

pm.request.headers.get('Accept').replace('application\/json;version=(?<version>\d{2}\.\d{1})','application/json;version={{apiVersion}}')

Regexp для парсинга URL по RFC

2024-09-23T07:01:22.567Z

Не претендуя на истину в последней инстанции, однако, хотелось закрыть для себя этот вопрос на всегда. Частенько в скриптах posh\python и т.п. приходится на входе принимать в качестве параметра строку с URL и быть уверенным что это:

точно URL
иметь возможность легко получить его составляющие (схему\fqdn\query\etc)

Подсматривая в интернет, получилось написать вот такую "красивую" регулярку, которая входящую строку бъет на следующие группы:

url (собственно если строка соответствует паттерну url - в этой группе будет отображаться полный url
scheme - схема URL http:// | ftp:// | anycustomscheme://
hostname - FQDN
port
path
query

Как работает этот regexp вы можете увидеть ниже

(?<url>(?:(?<scheme>[a-zA-Z]+:\/\/)?(?<hostname>(?:[-a-zA-Z0-9@%_\+~#=]{1,256}\.){1,256}(?:[-a-zA-Z0-9@%_\+~#=]{1,256})))(?::(?<port>[[:digit:]]+))?(?<path>(?:\/[-a-zA-Z0-9!$&'()*+,\\\/:;=@\[\]._~%]*)*)(?<query>(?:(?:\#|\?)[-a-zA-Z0-9!$&'()*+,\\\/:;=@\[\]._~]*)*))

На Python именованные группы нужно обозначать через символ P, поэтому для Python regex будет выглядеть чуть иначе:

(?P<url>(?:(?P<scheme>[a-zA-Z]+:\/\/)?(?P<hostname>(?:[-a-zA-Z0-9@%_\+~#=]{1,256}\.){1,256}(?:[-a-zA-Z0-9@%_\+~#=]{1,256})))(?::(?P<port>[[:digit:]]+))?(?P<path>(?:\/[-a-zA-Z0-9!$&'()*+,\\\/:;=@\[\]._~%]*)*)(?P<query>(?:(?:\#|\?)[-a-zA-Z0-9!$&'()*+,\\\/:;=@\[\]._~]*)*))

Ну и пример кода на Powershell:

$URL = "https://vcloud.lab.ihumster.ru/api/query?type=adminOrgVdcStorageProfile"
$URL -match "(?<url>(?:(?<scheme>[a-zA-Z]+:\/\/)?(?<hostname>(?:[-a-zA-Z0-9@%_\+~#=]{1,256}\.){1,256}(?:[-a-zA-Z0-9@%_\+~#=]{1,256})))(?::(?<port>[[:digit:]]+))?(?<path>(?:\/[-a-zA-Z0-9!$&'()*+,\\\/:;=@\[\]._~%]*)*)(?<query>(?:(?:\#|\?)[-a-zA-Z0-9!$&'()*+,\\\/:;=@\[\]._~]*)*))"
$Matches

True

Name                           Value
----                           -----
path                           /api/query
hostname                       vcloud.lab.ihumster.ru
url                            https://vcloud.lab.ihumster.ru/api/query?type=adminOrgVdcStorageProfile
scheme                         https://
query                          ?type=adminOrgVdcStorageProfile
0                              https://vcloud.lab.ihumster.ru/api/query?type=adminOrgVdcStorageProfile

Операнд -math возвращает boolean результат соответствия строки в $URL нашему регулярному выражению и если он True, то автопеременная $Matches будет содержать key-value словарь в котором ключами будут имена групп с соответствующими values.

Спасибо что дочитали до конца, надеюсь это будет вам полезно.

Комфортная работа в Postman с VMware Cloud Director

2024-09-23T07:00:31.766Z

В последний раз что-то полезное на эту тему писал Tomas Fojta в, далеком уже, 2018 году. С тех пор в VCD появились новые интересные методы API и в частности в 10.3.1 появились Cloud Director API Token.

По этому я решил слегка модернизировать подход к работе с VCD API в Postman с использованием токенов.

Если вам интересно - добро пожаловать под cut.

Подход к работе с токенами/авторизацией и вообще разными инстансами VCD в Postman будет основан на использовании всей доступной в Postman функциональности Workspaces, Collections, Variables и Scripts.

Первым делом создадим для работы с VCD отдельный Workspace и дадим ему имя (например, внезапно, VMware Cloud Director).

Создадим коллекцию запросов назвав ее, ну например, VCD API.

Переменные окружения и глобальные переменные

Откроем блок глобальных переменных и создадим там следующие переменные:

apiVersion
accept-vcloud-xml: application/*+xml;version={{apiVersion}}
accept-vcloud-json: application/*+json;version={{apiVersion}}

Это будут переменные общего назначения, и наиболее часто используемые, т.к. именно через поле заголовка Accept в запросе передается используемая версия API.

Не забудьте сохранить глобальные переменные (кнопка Save).

Следующим этапом будет создание переменных окружения. Наборы переменных окружения позволяют нам использовать одни и те же запросы к разным инстансам VCD. Выбор текущего набора переменных окружения позволит вам работать с конкретным инстансом VCD.

В окружении "ihumster lab" (дайте своему окружению имя, позволяющее конкретно идентифицировать инстанс с котороым будет вестись работа) будет 3 переменных:

vcd-url - базовый url вашего инстанса VCD (я намеренно не указываю url вида https://vcd-fqdn/api т.к. у VCD с некоторых пор 2 API - классический XML-RPC и новый OpenAPI)

bearer - переменная типа secret, ее initial значение пустое, т.к. получать значение переменная будет в процессе работы

user_token - переменная типа secret, содержащая токен вашего пользователя, позволяющий получить bearer токен без аутентификации с логином и паролем (как получить этот токен описано в статье VMware).

Важно!

Имейте ввиду, с использованием этого API Token вы не сможете через API:

Менять пароль пользователя
Управлять пользователями
Создавать новые API Tokens
Видеть и отзывать текущие API Tokens

А также, при использовании API Token, для следующих ресурсов будет иметься доступ только для чтения:

User
Group
Roles
Global roles
Rights bundles

Не забудьте сохранить ваши переменные (кнопка Save). Итого ваше окружение будет выглядеть так:

Настройки коллекции

Для нашей созданной ранее коллекции мы будем настраивать следующие свойства:

Authorization

Выбераем тип Bearer Token и в свойство Token вписываем переменную {{bearer}}.

Теперь любой созданный в коллекции запрос будет использовать наследуемый тип авторизации через токен.

Pre-request Script

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

Получать последнюю версию API (т.е. текущую для нашего инстанса VCD) и сохранять ее в глобальную переменную apiVersion.
Получать токен доступа от VCD с использованием нашего user_token и сохранение его в переменную окружения bearer.

// Get last version of VCD and save it to 'apiVersion' global variable
let urlVer = pm.environment.get("vcd-url") + "/api/versions"
const urpRequest = {
    url: urlVer,
    method: 'GET',
    header: {
        'Accept': 'application/*+json',
        'Content-Type': 'application/json'
    }
}
pm.sendRequest(urpRequest, (error,repsponse) =>{
    if (error){
        console.log(error)
    } else {
        pm.globals.set('apiVersion', repsponse.json().versionInfo.last().version)
    }
})

// Get access token using env var 'user_token' and transform it to Bearer token data 
// with save to 'bearer' env var
let urlTok = pm.environment.get("vcd-url") + "/oauth/provider/token"
let body = 'grant_type=refresh_token&refresh_token=' + pm.environment.get('user_token')
const postRequest = {
  url: urlTok,
  method: 'POST',
  header: {
    'Accept': 'application/json',
    'Content-Type': 'application/x-www-form-urlencoded'
  },
  body: {
    mode: 'raw',
    raw: body
  }
};

pm.sendRequest(postRequest, (error, response) =>{
    if (error){
        console.log(error)
    } else {
        pm.environment.set('bearer', response.json().access_token)
    }
})

Остается только проверить работу этого скрипта. Давайте попробуем получить ответ на запрос GET /api/admin/ (надо понимать что ваш user_token взят у пользователя из организации system и имеет права для запросов из раздела /api/admin/).

Создадим запрос типа GET, в url впишем конечный адрес с использованием переменной {{vcd-url}}, в разделе Headers добавим заголовок Accept с value {{accept-vcloud-json}}, и нажмем Send.

В результате ваш запрос выполнит сначала Pre-request Script (т.е. получит поддерживаемую версию API и получит access token для использования в запросе).

Использование данного подхода к OpenAPI

Залогиньтесь в провайдерскую консоль вашего VCD и откройте его API Exporer (Help-> API Exporer) и сохраните на локальный диск его Swagger файл (cloudapi.json)

Перейдите в Postman в раздел APIs и нажмте + после чего в разделе Import выберите ранее скаченный файл.

Postman покажет вам тип API (Swagger 2.0) и предложит сгенерировать новую коллекцию запросов из этого API.

Имейте ввиду, после процесса импорта окно не закрывается, а остается активным с вновь доступной кнопкой Import. Нажимать ее повторно не нужно - просто закройте окно крестиком.

В коллекциях у вас появится новая коллекция VMware Cloud Director OpenAPI с набором всех доступных методов и их описанием (документацией) - это очень удобно (требуется лишь изредка обновлять коллекцию при выходе новых версий API).

Что бы использовать эту коллекцию с всеми удобствами созданных нами ранее переменных и скриптов проделаем следующее:

Изменим тип авторизации с API Key на Bearer Token и вставим в поле Token {{bearer}}.
В разделе Pre-request Script вставим аналогичный код
В разделе Variables значение переменной baseUrl замените с /cloudapi на {{vcd-url}}/cloudapi для Initial и Current

После чего можно проверить новую коллекцию с помощью запроса Get base navigation links. В настройки запроса достаточно добавить только заголовок Accept с переменной {{accept-vcloud-json}}

Спасибо что дочитали до конца!