По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Использование REST API является полезной функцией для реализации ваших сценариев. Вы можете получить доступ к новым функциям, а также расширить возможности создания новых, более продвинутых сценариев. Опыт многих пользователей показывает, что, когда начинаешь использовать REST API в скриптах, то чувствуешь себя довольно неуклюже и непривычно. В этой заметке мы обсудим: Что такое REST API Как читать документацию Как использовать API REST с PowerShell Некоторые советы и подсказки, как облегчить и улучшить практику Что такое "REST"? REST, или RESTful API, это API, который использует HTTP запросы для получения, добавления, удаления или манипулирования данными в различных сервисах. Как правило, то, что нужно сделать с данными, решается тем, какой HTTP-метод вы используете. Вот краткий список методов HTTP и их применение в REST API: GET-Read POST-Create PATCH-Partial update/modify PUT-Update/replace DELETE-Remove Данные, которые возвращает API REST, обычно представляются в формате JSON. Теперь давайте начнём с нашего первого API запроса! Что такое API Работа с документацией Для использования различных API REST необходимо научиться читать и интерпретировать документацию. К счастью, если вы знаете, как читать один тип документации, вы сможете быстро научиться читать другие. В этой статье мы используем petstore.swagger.io, так как он использует популярный фреймворк Swagger, который довольно часто используется в разработке. На предыдущем рисунке показана наиболее важная информация о конечных точках REST API: HTTP-метод-GET/POST/DELETE и т.д. URL-адрес, связанный с конечной точкой REST API (Базовый URL, как правило, представлен в верхней части страницы документации) Краткое описание Подробности Первая страница документации просто замечательная, и, как правило, с помощью этой информации можно выполнить большинство запросов, требующих использования метода HTTP GET. Но такие методы, как POST и SET, обычно требуют, чтобы вы щелкнули и развернули строку, чтобы получить больше информации. Если вы нажмете на одну из строк, то получите информацию, которая выглядит так: Здесь мы представили конечную точку REST, которая может создать новый объект pet. Здесь указывается, как должен выглядеть JSON, предоставленный в теле POST, и какой тип контента он принимает. Другие конечные точки REST указывают, что это за параметры, каким типом данных они должны быть и т.д. Это основы для чтения документации. Теперь, когда общие принцип более-менее ясны, пора начать использовать REST API с PowerShell. Получение первых данных (GET) Используя REST API с PowerShell обычно довольно просто, используется встроенные командлеты, таким образом, нет необходимости в дополнительных модулях. Мы собираемся извлечь данные с помощью метода GET в конечной точке /pet/{ petId}. Если развернуть конечную точку /pet/{ petId} в документации, можно увидеть, что {petId} на самом деле является параметром, который принимает целое число. Это делает URL-адрес для выборки объекта pet с идентификатором 1: https://petstore.swagger.io/v2/pet/1 В документации SWAGGER REST API обычно отображается базовый URL-адрес в верхней части страницы. Теперь начнем с PowerShell. Откройте окно терминала и введите: PS51 > Invoke-RestMethod -Method GET -ContentType "application/json" -Uri "https://petstore.swagger.io/v2/pet/1" id : 1 category : @{id=0; name=string} name : doggie photoUrls : {string} tags : {@{id=0; name=string}} status : available Поскольку в ответе от сервера возвращается тип содержимого "application/json" используется метод Invoke-RestMethod, который автоматически преобразует возвращаемый JSON в объект. Ошибка 404 Not found, как правило, означает, что объект не найден или URL-адрес введен неправильно. Итак, мы выполнили первый вызов REST API. Но возможности метода GET для получения данных довольно ограничены, так что давайте создадим что-нибудь с помощью метода POST. Создание объекта методом POST Метод POST чаще всего используется для создания, например, пользователей или записей и т.д. Запрос POST отправляет BODY, содержащий информацию, конечной точке REST, обычно в формате JSON, но он также может быть в виде формы с кодировкой URL. Вы узнаете, как создать объект JSON, который можно отправить в конечную точку/pet. Можно увидеть, как должен выглядеть JSON, если развернуть строку POST/pet в документации. Начнем с создания хэштаблицы, который можно преобразовать в объект JSON. Raw JSON следует избегать в скриптах PowerShell, поскольку он ограничивает его возможности. $Body = @{ id = 19 category = @{ id = 45 name = "Whatever" } name = "Dawg" photoUrls = @( "string" ) tags = @( @{ id = 0 name = "string" } ) status = "available" } Если вам трудно создать хештаблицу, который преобразуется в нужный JSON, установите модуль PsdKit и используйте команду $ JsonString | ThreadTo-Psd Теперь имеется хэш-таблица, которую можно преобразовать в строку JSON и POST в конечную точку/pet: $JsonBody = $Body | ConvertTo-Json $Uri = "https://petstore.swagger.io/v2/pet" Invoke-RestMethod -ContentType "application/json" -Uri $Uri -Method Post -Body $JsonBody id : 19 category : @{id=45; name=Whatever} name : Dawg photoUrls : {string} tags : {@{id=0; name=string}} status : available При создании объекта он обычно получает созданный для подтверждения объект. Использование DELETE. Метод DELETE используется для удаления данных, а применение очень схоже с методом GET. PS51 > Invoke-RestMethod -Method DELETE -ContentType "application/json" -Uri "https://petstore.swagger.io/v2/pet/1" Только убедитесь, что не удалите ничего важного Использование PUT Метод PUT используется для обновления данных. Это делается аналогично методу POST путем представления полного или частичного объекта JSON: PS51> $Body = [PSCustomObject]@{ id = 19 name = "Dawg with a new name" } PS51> $JsonBody = $Body | ConvertTo-Json PS51> $Uri = "https://petstore.swagger.io/v2/pet" PS51> Invoke-RestMethod -ContentType "application/json" -Uri $Uri -Method PUT -Body $JsonBody id name photoUrls tags -- ---- --------- ---- 19 Dawg with a new name {} {} Обычно API REST возвращает объект JSON с использованными и/или обновленными данными. Можно увидеть, что объект был обновлен с помощью метода GET: PS 51> Invoke-RestMethod -ContentType "application/json" -Uri "https://petstore.swagger.io/v2/pet/19" id : 19 category : @{id=45; name=Whatever} name : Dawg with a new name photoUrls : {string} tags : {@{id=0; name=string}} status : available Создание функций Писать эти команды каждый раз вручную может стать довольно утомительным и на самом деле не масштабируемым. Если мы вызываем конечную точку несколько раз, то лучше создать для нее функцию. Это довольно просто и нужно написать всего несколько строк: Function Get-PetstorePet { [cmdletbinding()] param( # Id of the pet [Parameter(Mandatory,ValueFromPipeline)] [int]$Id ) Begin{} Process{ $RestMethodParams = @{ Uri = "https://petstore.swagger.io/v2/pet/$Id" ContentType = "application/json" Method = "GET" } Invoke-RestMethod @RestMethodParams } End{} } После создания функции ее можно вызвать в сценарии: PS51> Get-PetstorePet -Id 1 id name photoUrls tags -- ---- --------- ---- 1 Doggie {http://picture.url} {} Это можно сделать и для метода POST для создания нового объекта pet в Petstore: Function Add-PetstorePet { [cmdletbinding()] param( # Id of the pet [Parameter(Mandatory,ValueFromPipelineByPropertyName)] [int]$Id, # Name of the pet [Parameter(Mandatory,ValueFromPipelineByPropertyName)] [string]$Name, # Status of the pet (available, sold etc) [Parameter(Mandatory,ValueFromPipelineByPropertyName)] [string]$Status, # Id of the pet category [Parameter(Mandatory,ValueFromPipelineByPropertyName)] [int]$CategoryId, # Name of the pet category [Parameter(Mandatory,ValueFromPipelineByPropertyName)] [string]$CategoryName, # URLs to photos of the pet [Parameter(Mandatory,ValueFromPipelineByPropertyName)] [string[]]$PhotoUrls, # Tags of the pets as hashtable array: @{Id=1;Name="Dog"} [Parameter(Mandatory,ValueFromPipelineByPropertyName)] [Hashtable[]]$Tags ) Begin{} Process{ $Body = @{ id = $Id category = @{ id = $CategoryId name = $CategoryName } name = $Name photoUrls = $PhotoUrls tags = $Tags status = $Status } $BodyJson = $Body | ConvertTo-Json $RestMethodParams = @{ Uri = "https://petstore.swagger.io/v2/pet/" ContentType = "application/json" Method = "Post" Body = $BodyJson } Invoke-RestMethod @RestMethodParams } End{} } И вызов этой функции PowerShell намного упрощает задачу: PS51> $AddPetStorePetsParams = @{ Id = 44 Name = "Birdie" Status = "available" CategoryId = 50 CategoryName = "Hawks" PhotoUrls = "https://images.contoso.com/hawk.jpg" Tags = @( @{ Id=10 Name="Not eagles" } ) } PS51> Add-PetStorePet @AddPetStorePetsParams id : 44 category : @{id=50; name=Hawks} name : Birdie photoUrls : {https://images.domain.com/hawk.jpg} tags : {@{id=0}} status : available Возможно, что многие модули, которые вы ежедневно используете, состоят из функций, который за кулисами используют REST API. Заключение Обучение работы с REST API, главным образом основано на чтении документации. Мы использовали документацию на основе SWAGGER в этом посте, так как она представляет, как могут выглядеть другие стили документации. Кроме того, преобразование вызовов API в функцию может сэкономить много времени, упростить работу и очистить сценарии.
img
Всем привет! Сегодня статью мы посвятим рассказу о протоколе DHCP (Dynamic Host Configuration Protocol) – что он из себя представляет, для чего он нужен и как он работает. DHCP доступен как для IPv4 (DHCPv4) , так и для IPv6 (DHCPv6) . В этой статье мы рассмотрим версию для IPv4. А следующей статье мы расскажем про его настройку. DHCP за 200 секунд Порассуждаем Каждому устройству, подключенному к сети, нужен уникальный IP-адрес. Сетевые администраторы назначают статические IP-адреса маршрутизаторам, серверам, принтерам и другим сетевым устройствам, местоположение которых (физическое и логическое) вряд ли изменится. Обычно это устройства, предоставляющие услуги пользователям и устройствам в сети, поэтому назначенные им адреса должны оставаться постоянными. Кроме того, статические адреса позволяют администраторам удаленно управлять этими устройствами – до них проще получить доступ к устройству, когда они могут легко определить его IP-адрес. Однако компьютеры и пользователи в организации часто меняют места, физически и логически. Это может быть сложно и долго назначать новые IP-адреса каждый раз, когда сотрудник перемещается. А для мобильных сотрудников, работающих из удаленных мест, вручную настройка правильных параметров сети может быть весьма непростой задачей. Использование DHCP в локальной сети упрощает назначение IP-адресов как на настольных, так и на мобильных устройствах. Использование централизованного DHCP-сервера позволяет администрировать все назначения динамических IP-адресов с одного сервера. Эта практика делает управление IP-адресами более эффективным и обеспечивает согласованность внутри организации, включая филиалы. DHCPv4 динамически назначает адреса IPv4 и другую информацию о конфигурации сети. Отдельный сервер DHCPv4 является масштабируемым и относительно простым в управлении. Однако в небольшом офисе маршрутизатор может быть настроен для предоставления услуг DHCP без необходимости выделенного сервера. DHCPv4 включает три разных механизма распределения адресов для обеспечения гибкости при назначении IP-адресов: Ручное распределение(Manual Allocation) - администратор назначает предварительно установленный IPv4-адрес клиенту, а DHCP сервер передает IPv4-адрес на устройство. Автоматическое распределение(Automatic Allocation) - DHCPv4 автоматически назначает статический IPv4-адрес на устройство, выбирая его из пула доступных адресов. Нет аренды (lease), и адрес постоянно назначается устройству. Динамическое распределение (Dynamic Allocation) - DHCPv4 динамически назначает или дает в аренду IPv4-адрес из пула адресов в течение ограниченного периода времени, выбранного сервером, или пока клиент больше не нуждается в адресе. Динамическое распределение является наиболее часто используемым механизмом DHCP и при его использовании клиенты арендуют информацию с сервера на определенный период. DHCP серверы настраивают так, чтобы установить аренду (лизинг) с различными интервалами. Аренда обычно составляет от 24 часов до недели или более. Когда срок аренды истекает, клиент должен запросить другой адрес, хотя обычно он снова получает старый. Механизм работы DHCP DHCPv4 работает в режиме клиент/сервер. Когда клиент взаимодействует с сервером DHCPv4, сервер назначает или арендует IPv4-адрес этому клиенту. Он подключается к сети с этим арендованным IP-адресом до истечения срока аренды и должен периодически связываться с сервером DHCP, чтобы продлить аренду. Этот механизм аренды гарантирует, что клиенты, которые перемещаются или выходят из строя, не сохраняют за собой адреса, которые им больше не нужны. По истечении срока аренды сервер DHCP возвращает адрес в пул, где он может быть перераспределен по мере необходимости. Рассмотрим процесс получения адреса: Когда клиент загружается (или хочет присоединиться к сети), он начинает четырехэтапный процесс для получения аренды. Он запускает процесс с широковещательным (broadcast) сообщением DHCPDISCOVER со своим собственным MAC-адресом для обнаружения доступных серверов DHCPv4. Поскольку у клиента нет способа узнать подсеть, к которой он принадлежит, у сообщения DHCPDISCOVER адрес назначения IPv4 адреса -255.255.255.255. А поскольку у клиента еще нет настроенного адреса IPv4, то исходный IPv4-адрес - 0.0.0.0. Сообщение DHCPDISCOVER находит серверы DHCPv4 в сети. Поскольку клиент не имеет IPv4 информации при загрузке, он использует широковещательные адреса 2 и 3 уровня для связи с сервером. Когда DHCPv4-сервер получает сообщение DHCPDISCOVER, он резервирует доступный IPv4-адрес для аренды клиенту. Сервер также создает запись ARP, состоящую из MAC-адреса клиента и арендованного IPv4-адреса DHCP сервер отправляет связанное сообщение DHCPOFFER запрашивающему клиенту, как одноадресная передача (unicast), используя MAC-адрес сервера в качестве исходного адреса и MAC-адрес клиента в качестве адреса доставки. Когда клиент получает DHCPOFFER с сервера, он отправляет обратно сообщение DHCPREQUEST. Это сообщение используется как для получения, так и для продления аренды. Когда используется для получения аренды, DHCPREQUEST служит в качестве уведомления о принятии выбранных сервером параметров, которые он предложил, и отклонении предложения от других серверов. Многие корпоративные сети используют несколько DHCP серверов, и сообщение DHCPREQUEST отправляется в виде широковещательной передачи, чтобы информировать все серверы о принятом предложении. При получении сообщения DHCPREQUEST сервер проверяет информацию об аренде с помощью ICMP-запроса на этот адрес, чтобы убедиться, что он уже не используется и создает новую ARP запись для аренды клиента, а затем отвечает одноадресным DHCPACK-сообщением. Это сообщение является дубликатом DHCPOFFER, за исключением изменения поля типа сообщения. Когда клиент получает сообщение DHCPACK, он регистрирует информацию и выполняет поиск ARP для назначенного адреса. Если ответа на ARP нет, клиент знает, что адрес IPv4 действителен и начинает использовать его как свой собственный. Теперь рассмотрим, как происходит продление аренды адреса: Когда срок аренды истек, клиент отправляет сообщение DHCPREQUEST непосредственно DHCP серверу, который первоначально предлагал адрес. Если DHCPACK не получен в течение определенного периода времени, то клиент передает другой DHCPREQUEST, чтобы один из других доступных серверов DHCPv4 мог продлить аренду. При получении сообщения DHCPREQUEST сервер проверяет информацию об аренде, возвращая DHCPACK
img
В прошлой статье мы рассказывали о ресурсе HIBP, на котором можно, проверить находится ли ваш email или пароль в базе взломанных учётных данных. В этой статье расскажем о расширении от Google, которое может выполнять такую же проверку автоматически на любом сайте, где вы вводите учётные данные, используя браузер Google Chrome. Расширение, описанное в данной статье, актуально только для пользователей браузера Google Chrome. Остальным же, мы надеемся, будет просто полезно ознакомиться с возможностями решения. Похоже, что факт обнаружения баз слитых учёток Collection #1 и последующих более крупных Collection #2-5, не остался без внимания Google. Потому что 5 февраля (в день безопасного Интернета, кстати) они объявили о создании сразу двух расширений, которые призваны сделать процесс работы с вэб-ресурсами и приложениями ещё более безопасным. Про одно из них мы бы хотели рассказать в нашей статье. Password Checkup Проверяет учётные данные, которые вы вводите на каждом сайте или в приложении через Google, по базе из свыше 4 миллиардов взломанных логинов и паролей. Если расширение обнаруживает ваши логин и пароль (то есть оба типа данных, которые необходимы для получения доступа к вашему аккаунту) в списке взломанных, то оно генерирует оповещение с предложением сменить скомпрометированные данные. При этом, расширение не будет уведомлять о том, что вы используете слабый пароль или о том, что ваш старый, не актуальный пароль был скомпрометирован. Google заявляет, что разрабатывал расширение так, чтобы учетные данные, которые вы вводите, никогда не попали не только в злоумышленникам, но и в сам Google, в этом им помогали эксперты в области криптографии Стэндфордского Университа. Итак, как это работает? Когда вы вводите на каком-либо сайте свой логин и пароль расширение обращается к серверам Google для того, чтобы проверить находятся ли введённые учётные данные в списке скомпрометированных. При этом, в запросе не передаются сами логин и пароль. То есть расширение опрашивает сервер, не передавая туда запрашиваемую информацию. При этом, важно исключить возможность использования расширения злоумышленниками, которые будут брутить сайты и пробовать получить от расширения информацию о скомпрометированных учётках. Для этого в расширении применяется сразу несколько технологий шифрования, многоразовое хэширование вводимой информации, а также технологии Private Set Intersection (PSI) и k-annonimity. Google имеет в своём распоряжении базу из взломанных учётных данных, содержащих около 4 миллиардов записей. Однако, это не учётные данные в открытом виде, а их захэшированная и зашифрованная копия, ключ от которой известен только Google. Каждый раз, когда вы вводите свой логин и пароль, расширение Password Checkup будет отправлять на сервера Google захэшированную копию этих данных, ключ от которых будет известен только вам. В свою очередь на сервере Google эта копия также будет зашифрована специальным ключом. Последнее преобразование происходит локально в самом расширении - полученная копия от Google дешифруется и если результат сходится с тем хэшом скомпрометированных учётных данных, что хранится на сервере Google - то пользователю выводится Алерт с рекомендациями по смене пароля. Если вы пользуетесь браузером Google Chrome, то рекомендуем установить данное расширение, чтобы обезопасить свои аккаунты от доступа к ним третьих лиц. И никогда, пожалуйста, не используйте одни и те же пароли на разных сайтах.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59