По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Git – это популярная система контроля версий. Благодаря Git разработчики могут сотрудничать и без проблем работать над проектами совместно. Git позволяет отслеживать изменения, которые вы вносите в проект с течением времени. Помимо этого, он позволяет вернуться к предыдущей версии, если вы вдруг решили не вносить изменение. Git работает по следующему принципу: вы размещаете файлы в проекте с помощью команды git add, а затем фиксируете (коммитите) их с помощью команды git commit. При совместной работе над проектами могут возникнуть ситуации, когда вы не захотите, чтобы какие-то файлы или части проекта были видны всем участникам команды. Иными словами, вы не захотите включать и фиксировать эти файлы в основной версии проекта. Вот почему вы можете не захотеть использовать разделитель (точку) с командой git add, так как в этом случае каждый отдельный файл будет размещен в текущем каталоге Git. Когда вы используете команду git commit, то каждый отдельный файл фиксируется – это также добавляет файлы, которые не нужно. Вы можете, наоборот, захотеть, чтобы Git игнорировал определенные файлы, но для такой цели не существует команды git ignore. Итак, как же сделать так, чтобы Git игнорировал и не отслеживал определенные файлы? С помощью файла .gitignore. В этой статье вы узнаете, что такое файл .gitignore, как его создать и как использовать для игнорирования некоторых файлов и папок. Также вы узнаете, как можно заставить Git игнорировать уже закоммиченый файл. Что такое файл .gitignore? Для чего он нужен? Каждый из файлов в любом текущем рабочем репозитории Git относится к одному из трех типов: Отслеживаемые – это все файлы и каталоги, о которых знает Git. Это файлы и каталоги, которые были недавно размещены (добавлены с помощью git add) и зафиксированы (закоммичены с помощью git commit) в главном репозитории. Неотслеживаемые – это новые файлы и каталоги, которые созданы в рабочем каталоге, но еще не размещены (или добавлены с помощью команды git add). Игнорируемые – это все файлы и каталоги, которые полностью исключаются и игнорируются, и никто о них в репозитории Git не знает. По сути, это способ сообщить Git о том, какие неотслеживаемые файлы так и должны остаться неотслеживаемыми и не должны фиксироваться. Все файлы, которые должны быть проигнорированы, сохраняются в файле .gitignore. Файл .gitignore – это обычный текстовый файл, который содержит список всех указанных файлов и папок проекта, которые Git должен игнорировать и не отслеживать. Внутри файла .gitignore вы можете указать Git игнорировать только один файл или одну папку, указав имя или шаблон этого конкретного файла или папки. Используя такой же подход, вы можете указать Git игнорировать несколько файлов или папок. Как создать файл .gitignore Обычно файл .gitignore помещается в корневой каталог репозитория. Корневой каталог также известен как родительский или текущий рабочий каталог. Корневая папка содержит все файлы и другие папки, из которых состоит проект. Тем не менее, вы можете поместить этот файл в любую папку в репозитории. Если на то пошло, но у вас может быть несколько файлов .gitignore. Для того, чтобы создать файл .gitignore в Unix-подобной системе, такой как macOS или Linux, с помощью командной строки, откройте приложение терминала (например, в macOS это Terminal.app). Затем для того, чтобы создать файл .gitignore для вашего каталога, перейдите в корневую папку, которая содержит проект, и при помощи команды cd введите следующую команду: touch .gitignore Файлы, перед именем которых стоит точка ., по умолчанию скрыты. Скрытые файлы нельзя просмотреть, используя только команду ls. для того, чтобы иметь возможность просмотреть все файлы, включая скрытые, используйте флаг -a с командой ls следующим образом: ls –a Что добавлять в файл .gitignore В файл .gitignore должны быть добавлены файлы любого типа, которые не нужно фиксировать. Вы можете не хотеть их фиксировать из соображений безопасности или потому, что они нужны только вам и не нужны другим разработчикам, работающим над тем же проектом, что и вы. Вот некоторые файлы, которые могут быть включены: Файлы операционной системы. Каждая операционная система, будь то macOS, Windows или Linux, создает системные скрытые файлы, которые не нужны другим разработчикам, так как их система создает такие же файлы. Например, в macOS Finder создает файл .DS_Store, который содержит пользовательские настройки внешнего вида и отображения папок, такие как размер и положение иконок. Файлы конфигурации, создаваемые такими приложениями, как редакторы кода и IDE (Integrated Development Environment – интегрированная среда разработки). Эти файлы настроены под вас, ваши конфигурации и ваши настройки, например папка .idea. Файлы, которые автоматически генерируются языком программирования или средой разработки, которую вы используете для своего проекта, и в процессе компиляции специфичных для кода файлов, такие как файлы .o. Папки, созданные диспетчерами пакетов, например, папка npm node_modules. Это папка, которая используется для сохранения и отслеживания зависимостей для каждого пакета, который вы устанавливаете локально. Файлы, которые содержат конфиденциальные данные и личную информацию. Примерами таких файлов могут послужить файлы с вашими учетными данными (имя пользователя и пароль) и файлы с переменными среды, такие как файлы .env (файлы .env содержат ключи API, которые должны оставаться защищенными и закрытыми). Файлы среды выполнения, такие как файлы .log. Они предоставляют информацию об использовании операционной системы и ошибках, а также историю событий, произошедших в рамках ОС. Как игнорировать файл или папку в Git Если вы хотите игнорировать только один конкретный файл, то вам необходимо указать полный путь к файлу из корневой папки проекта. Например, если вы хотите игнорировать файл text.txt, который расположен в корневом каталоге, то вы должны сделать следующее: /text.txt А если вы хотите игнорировать файл text.txt, который расположен в папке test корневого каталоге, вы должны сделать следующее: /test/text.txt Вы можете это записать иначе: test/text.txt Если вы хотите игнорировать все файлы с определенным именем, то вам нужно написать точное имя файла. Например, если вы хотите игнорировать любые файлы text.txt, то вы должны добавить в .gitignore следующее: text.txt В таком случае вам не нужно указывать полный путь к конкретному файлу. Этот шаблон будет игнорировать все файлы с таким именем, расположенные в любой папке проекта. Для того, чтобы игнорировать весь каталог со всем его содержимым, вам нужно указать имя каталога со слешем в конце: test/ Эта команда позволит игнорировать любой каталог (включая другие файлы и другие подкаталоги внутри каталога) с именем test, расположенный в любой папке вашего проекта. Стоит отметить, что если вы напишете просто имя каталога без слеша, то этот шаблон будет соответствовать как любым файлам, так и любым каталогам с таким именем: # соответствует любым файлам и каталогам с именем test test Что делать, если вы хотите игнорировать любые файлы и каталоги, которые начинаются с определенного слова? Допустим, вы хотите игнорировать все файлы и каталоги, имя которых начинается с img. Для этого вам необходимо указать имя, а затем селектор подстановочного символа *: img* Эта команда позволит игнорировать все файлы и каталоги, имя которых начинается с img. Но что делать, если вы хотите игнорировать любые файлы и каталоги, которые заканчиваются определенным набором символов? Если вы хотите игнорировать все файлы с определенным расширением, то вам необходимо будет использовать селектор подстановочного знака *, за которым последует расширение файла. Например, если вы хотите игнорировать все файлы разметки, которые заканчиваются расширением .md, то вы должны в файл .gitignore добавить следующее: *.md Этот шаблон будет соответствовать любому файлу с расширением .md, расположенному в любой папке проекта. Мы разобрали, как игнорировать все файлы, которые оканчиваются одинаково. Но что делать, если вы хотите сделать исключение для одного из этих файлов? Допустим, вы добавили в свой файл .gitignore следующее: .md Этот шаблон позволит игнорировать все файлы, оканчивающиеся на .md, но вы, например, не хотите, чтобы Git игнорировал файл README.md. Для этого вам нужно будет воспользоваться шаблоном с отрицанием (с восклицательным знаком), чтобы исключить файл, который в противном случае был бы проигнорирован, как и все остальные: # игнорирует все файлы .md .md # не игнорирует файл README.md !README.md Учитывая эти два шаблона в файле .gitignore, все файлы, оканчивающиеся на .md будут игнорироваться, кроме файла README.md. Стоит отметить, что данный шаблон не будет работать, если вы игнорируете весь каталог. Допустим, что вы игнорируете все каталоги test: test/ И допустим, внутри папки test у вас есть файл example.md, который вы не хотите игнорировать. В этом случае вы не сможете сделать исключение для файла внутри игнорируемого каталога следующим образом: # игнорировать все каталоги с именем test test/ # попытка отрицания файла внутри игнорируемого каталога не сработает !test/example.md Как игнорировать ранее закоммиченый файл Лучше всего создать файл .gitignore со всеми файлами и различными шаблонами файлов, которые вы хотите игнорировать, при создании нового репозитория, до его коммита. Git может игнорировать только неотслеживаемые файлы, которые еще не были зафиксированы в репозитории. Что же делать, если вы уже закоммитили файл, но хотели бы, чтобы он все-таки не был закоммичен? Допустим, что вы случайно закоммитили файл .env, в котором хранятся переменные среды. Для начала вам необходимо обновить файл .gitignore, чтобы включить файл .env: # добавить файл .env в .gitignore echo ".env" >> .gitignore Теперь, вам нужно указать Git не отслеживать этот файл, удалив его из перечня: git rm --cached .env Команда git rm вместе с параметром --cached удаляет файл из репозитория, но не фактический файл. Это значит, что файл остается в вашей локальной системе и в вашем рабочем каталоге в качестве файла, который игнорируется. Команда git status покажет, что файла в репозитории больше нет, в ввод команды ls покажет, что файл существует в вашей локальной файловой системе. Если вы хотите удалить файл из репозитория и вашей локальной системы, то не используйте параметр --cached. Затем добавьте .gitignore в область подготовленных файлов с помощью команды git add: git add .gitignore И наконец, закоммитте файл .gitignore с помощью команды git commit: git commit -m "update ignored files" Заключение Вот и все – теперь вы знаете, как игнорировать файлы и папки в Git.
img
Что такое SSO? С помощью системы единого входа (SSO - single sign-on) клиенты могут получать доступ к различным сайтам и приложениям, используя всего один набор входных данных. SSO работает со стратегией подтверждения личности клиента. Это происходит, когда клиент входит в одну программу и сразу же получает доступ в других связанных приложениях. Различные имена пользователей и пароли теперь можно более эффективно отслеживать в различных учетных записях и ресурсах. Удобно ведь, когда человек входит в Google, и его сертификаты за доли секунды подтверждаются в связанных ресурсах, включая Gmail и YouTube, без необходимости регистрации в каждой из них. Токен SSO Токеном системы единого входа (SSO Token) называется сбор информации или данных, которые отправляются с одной платформы на другую в процессе использования SSO. Это основополагающие данные такие, как адрес электронной почты клиента и сведения о системе, которая отправляет токен. Чтобы условный сборщик имел возможность подтвердить, что токен поступает из надежного источника, они должны быть строго промаркированы. В процессе настройки пересылается подтверждение надежности токена, используемого для этой маркировки. Важность системы единого входа SSO имеет важное значение в свете того факта, что постоянно растет количество ресурсов и учетных записей, доступ к которым клиентам необходимо контролировать, и каждый из этих ресурсов требует определенной степени безопасности, которая обычно обеспечивается с помощью комбинации имени пользователя и пароля. Тем не менее, руководителям и клиентам, которые стараются подобрать надежные пароли для нескольких учетных записей, может быть трудно упорядочить и работать с таким количеством учетных записей. Система единого входа поддерживает безопасный доступ к приложениям, унифицируя технику для руководителей и клиентов. Процедура единого входа может выполняться с использованием различных методических инструкций, но все они соответствуют одной и то же базовой структуре. Важным аспектом является то, что они позволяют приложениям отдавать право подтверждения клиента другому приложению или администратору. Этап SSO рассматривается как отдельное пространство, где можно работать лишь с идентификаторами клиентов. Как работает SSO? В основе лежат доверительные отношения между поставщиком услуг (Service Provider) – программой, и поставщиком удостоверений (Identity Provider) – например такой компанией, как OneLogin. Сертификат, которым обмениваются поставщик услуг и поставщик удостоверений, как правило, служит основой для этих самых доверительных отношений. Чтобы поставщик услуг знал, что идентификационная информация поступает из надежного источника, этот сертификат можно использовать для подписи этой идентификационной информации, которая передается от поставщика идентификационной информации поставщику услуг. В SSO эти идентификационные данные представляют собой токены, которые включают в себя идентифицирующие данные о человеке, такие как его адрес электронной почты или имя пользователя. SSO работает на основе доверительных отношений, установленных между приложением, называемым поставщиком услуг, и поставщиком персональных данных, таким как OneLogin. Эти доверительные отношения часто основаны на положительном заключении, одобрении, которым обмениваются поставщик персональных данных и специализированная организация. Это одобрение можно использовать для подписи данных о пользователе, которые отправляются от поставщика персональных данных в специализированную организацию, чтобы поставщик услуг убедился в надежности источника данных. В SSO эта персональная информация отображается в виде токенов, которые содержат различимые фрагменты данных о клиенте, такие как адрес электронной почты клиента или имя пользователя. Далее показано, как обычно происходит взаимодействие при входе в систему: Клиент изучает программу или сайт – «поставщика услуг», к которому он хочет получить доступ. Чтобы запросить проверку личности клиента у SSO, иначе называемой поставщиком удостоверений, поставщик услуг передает токен, который содержит некоторую информацию о клиенте, например, его адрес электронной почты. Чтобы разрешить доступ к приложению поставщика услуг и сразу перейти к пункту 5, поставщик удостоверений должен для начала определить, проходил ли недавно клиент аналогичную проверку. Если клиент этого еще не делал, ему будет предложено войти в систему, предоставив требуемые условия допуска поставщика удостоверений. Это может быть просто имя пользователя и пароль, или это может быть даже совсем другая стратегия подтверждения, например, одноразовый пароль. Поставщик удостоверений отправляет обратно поставщику услуг символьные данные подтверждения фактической проверки каждый раз, когда он подтверждает отправленные сертификаты. Программа клиента передает этот токен поставщику услуг. Доверительные отношения, который были установлены между поставщиком услуг и поставщиком удостоверений во время основного соглашения, используются для утверждения пути проверки через символьные данные, полученные поставщиком услуг. Специализированная организация (поставщик услуг) разрешает доступ клиента. Новый сайт также должен иметь группу доверия, настроенную с механизмом SSO, и процесс проверки будет аналогичным, когда клиент попытается получить доступ к альтернативному сайту. Типы конфигураций SSO SAML - Открытый стандарт SAML (Security Access Markup Language) рассматривает обмен символьной информацией путем кодирования текста в машинный язык. На сегодняшний день SAML – один из основных принципов SSO, он помогает поставщикам приложений гарантировать правильность выполнения их требований проверки. Данные могут передаваться через интернет-браузер благодаря SAML 2.0, который был создан специально для использования в веб-приложениях. OAuth - Компонент авторизации открытого стандарта, известный под названием oAuth, отправляет идентификационные данные между приложениями, используя шифрование машинного кода. Это особенно удобно для использования в локальных приложениях, поскольку позволяет клиентам разрешать доступ к своей информации, начиная с первого приложения, и далее в следующих приложениях, без необходимости подтверждать свою личность физически. Kerberos - При неопределенной организации защиты клиент и сервер могут проверять личность друг друга, используя соглашение Kerberos. Клиенты и программирующие программы, такие как клиенты электронной почты или вики-серверы, проверяются с помощью пропускающего ресурса, который распространяет токены. OIDC - OIDC расширяет OAuth 2.0 путем расширения возможности SSO и поддерживая явную информацию о клиенте. Это позволяет произвести однократную авторизацию для входа в систему для нескольких уникальных приложений. Например, позволяет клиентам входить в справочную систему, используя свою учетную запись Facebook или Google, а не вносить новую информацию в сертификат клиента. Проверка подлинности смарт-карты - Помимо обычного SSO, существует также средства, поддерживающие подобный механизм. Модели устройств содержат устройства чтения карт, которые клиенты могут подключать к своим компьютерам. Для проверки личности клиента программа использует криптографические ключи, хранящиеся на карте. Карты должны находиться только у клиента во избежание утери. Их использование является дорогостоящим, независимо от того, являются ли они просто сами по себе безопасными или требуют PIN-код для работы. Использование SAML и OAuth в SSO Для проверки своей легитимности токены подтверждения используют рекомендации по обмену данными (переписке). SAML, который является языком для создания токенов подтверждения, является основной рекомендацией. XML используется в стандарте SAML для разрешения проверки личности клиента и передачи ему доступа, чтобы можно было связываться через зоны действия системы безопасности. SAML работает с перепиской между клиентом, SP и IdP при использовании его в SSO. Данные клиентов должны безопасно предоставляться различным ресурсам с единственным входом в систему. Это становится возможным с OAuth, который позволяет различным внешним ресурсам использовать данные записи клиента. SP сообщает IdP о запросе клиента на доступ, который IdP затем проверяет и подтверждает, прежде чем предоставлять доступ клиенту. Решение зарегистрироваться на сайте, используя учебную запись Facebook, а не имя пользователя и пароль, является одним из примеров. SSO может использоваться как для автономных соглашений OAuth, так и для SAML. В то время как SAML проверяет клиентов, OAuth используется для подтверждения доступа клиентов. Преимущества и недостатки SSO Преимущества: Сокращение количества атак: SSO исключает возможность того, что закончатся пароли, а также правила подбора паролей, что делает организацию более защищенной от фишинга. Это исключает сбросы паролей, что является утомительным и дорогостоящим, и позволяет клиентам запоминать лишь один пароль. Простой и безопасный клиентский доступ: SSO предоставляет организациям возможность оперативно получить информацию о том, какие клиенты, когда и откуда получили доступ к тем или иным приложениям, позволяя им тем самым защитить целостность своих инфраструктур. Механизмы SSO также могут справить с такими угрозами безопасности, как сбой рабочего устройства, позволяя IT-службам быстро блокировать доступ к учетным записям и важной информации на устройстве. Улучшена оценка клиентского доступа. В постоянно меняющейся обстановке в организации, как правило, стараются обеспечить доступ законных сотрудников к базовым данным и активам на соответствующем уровне. В зависимости от работы, подразделения и статуса клиента права доступа могут быть реализованы с использованием механизмов SSO. Это обеспечивает различимость входных уровней. Конкурентоспособность: пользователи отмечают более быстрый и удобный доступ к проектам, которые им необходимо завершить. Физическая обработка запросов – это задача, которая в основном раздражает клиентов. Проверка SSO избавляет от этой необходимости, предоставляя мгновенный доступ к огромному количеству приложений всего за одну галочку. SSO – это наиболее важный этап защиты вашего бизнеса и его клиентов. Вы можете использовать SSO в качестве основы для других средств защиты, включая многофакторную проверку подлинности и сочетание проверки личности, оценки рисков и согласования советов директоров для выполнения предварительных требований и сокращения предоставления неверных данных. SSO делает вашу организацию легитимной и обеспечивает ее безопасность. Недостатки: SSO проста и практична в использовании, но если она не контролируется должным образом, то это может быть проблемой для безопасности. К проблемам SSO относятся: Если злоумышленник получает права доступа SSO клиента, он также получает и доступ ко всем его приложениям. Соответственно, использование стратегий проверки, отличных от паролей, является основополагающим принципом. Возможные недостатки: недавно злоумышленники получили несанкционированный доступ к веб-сайтам и различным записям из-за недостатков, обнаруженных к SAML и OAuth. Работа с поставщиком, который объединяет SSO с другими этапами проверки и управление личностями в своем продукте, является крайне необходимой в этом отношении. Сходство приложений: иногда приложение может быть спроектировано так, что оно не очень подходит для работы с SSO. Будь то через SAML, Kerberos или OAuth, поставщики приложений должны обеспечить полноценную функциональность SSO. В любом другом случае, ваша система SSO не будет полностью вовлечена, а просто добавит еще один пароль, чтобы клиенты могли его восстановить. Безопасна ли система SSO? Однако неверно было бы утверждать, что SSO – это волшебное решение проблемы. Стоимость, контроль, нормализация (SAML против OAuth) и безопасность, безусловно, являются трудными задачами для организации системы единого входа. Сайт или ресурс могут быть подвержены атаке злоумышленника из-за проблем с проверкой, таких как уязвимость функции «Войти через Apple» или дефект Microsoft OAuth. Кроме того, стоит понимать, что SSO-этап должен быть включен в более крупную корпоративную IT-структуру, поэтому следует тщательно продумать, как это сделать, сохраняя при этом общую безопасность. SSO, например, может помешать устройствам безопасности распознать начальный IP-адрес клиента при попытке пойти в вашу систему. Несмотря на все это, использование SSO в большинстве случаев обеспечивает более высокий уровень безопасности, чем ожидание того, что клиенты будут контролировать все входы в систему для крупных бизнес-приложений. SSO явно сокращает количество моментов для атак, поскольку клиентам нужно реже регистрироваться и вспоминать меньше паролей. Директора могут более эффективно поддерживать меры предосторожности, такие как 2FA и надежные пароли, когда организация представляет собой единую структуру. Самое главное, что использование SSO, как правило, в любом случае безопаснее, чем его неиспользование.
img
За последний десяток лет Wi-fi-сети получили огромное распространение. Роутер сейчас нельзя найти редко в какой квартире. А подключая мобильник к своему домашнему вай-фаю, в списке можно увидеть с десяток точек доступа ближайших соседей. Вай-фай есть практически везде. Но покрытие сети не всегда бывает эффективным. В этой статье мы разберем инструмент для разработки и оптимизации Wi-fi-сетей от компании Ekahau. Ekahau Connect- это набор физических и программных инструментов для работы с сетями Wi-Fi. Назначение этого набора инструментов это планирование и разработка, анализ и оптимизация, выявление и устранение неполадок сети.Также данный инструментарий позволяет работать командой например, бригаде обслуживания сетей на выезде поддерживать связь, с инженером-проектировщиком, который работает в офисе. Решения Ekahau позволяют быстро и беспрепятственно обмениваться информацией и оперативно принимать решения по обслуживанию сетей Wi-fi. Набор Ekahau Connect включает в себя следующие инструменты: Ekahau Pro Site Survey Tooll - базовый инструмент, предназначенный для планирования, обработки данных, оптимизации и оперативного устранения проблем в сетях Wi-Fi.Имеет широчайший функционал, который позволяет использовать это решение профессионально. Несмотря на это, достаточно прост в использовании и изучении, а также достаточно быстро работает с данными. Имеется поддержка Windows и MAC OS. Производитель также заявляет поддержку всех существующих на текущий момент стандартов Wi-fi, до 6 версии включительно. Ekahau Sidekick - многофункциональный высокоточный измерительно-диагностический прибор. Имеет два радиомодуля Wi-Fi, а также встроенное оборудование и ПО для анализа спектра. Прибор используется для сбора данных покрытия сетей Wi-Fi и устранения неполадок в них. По заявкам производителя, инструмент снимает данные вдвое быстрее аналогов, а анализирует в 4-10 раз быстрее. Семь встроенных антенн позволяют оптимально проводить высокоточное исследование поведения и покрытия сети Wi-Fi. Инструмент работает с iPad, MacOS и Windows, причем имеет функцию Plug and Play. Заявлена поддержка всех актуальных стандартов Wi-Fi, в том числе Wi-Fi 6. Ekahau Survey- это первое на рынке профессиональное решение для диагностики сети Wi-Fi для iPad.Благодаря мобильной платформе, оно позволяет не таскать с собой габаритные ноутбуки, а держать весь необходимый инструментарий в планшете компании Apple.Интуитивно доступный интерфейс и простота использования дают возможность снимать данные на местах даже начинающему специалисту. Этот инструмент определяет все доступные сети и составляет их карту покрытия, с учетом силы сигнала. Ekahau Capture - технология, которая позволяет быстро и без потерь захватывает пакеты данных. Ekahau Capture позволяет сэкономить на сложном и дорогом оборудовании, а также использует простые и надежные решения для полноценного сбора данных. Инструмент легок в обращении, что дает возможность быстро провести сбор и обработку данных для определения и устранения неполадок сети Wi-Fi, даже начинающему специалисту.Для достижения оптимальной скорости и надежности работы данную программу рекомендуется использовать совместно с Ekahau Sidekick. Ekahau Cloud - как очевидно из названия, это облачная технология. Благодаря ей, сбор данных может осуществляться как в память устройства, так и в облачное хранилище. В последнем случае можно подключить для работы с данными общий доступ. Это позволит трудиться над одним проектом целой группе людей например, полевая бригада с анализаторами будет собирать данные о сети и передавать их в облако. А далее с этими данными, видя и оценивая полную картину, будут работать специалисты-аналитики. Эту опцию можно отключить, поэтому если время не критично, сбор данных можно осуществлять и в память устройства. Опять же, важно понимать, что наибольшую ценность Ekahau будет иметь на масштабных внедрениях Wi-Fi и особенно если там есть сложные условия - толстые перекрытия, помехи и так далее. Используя вышеупомянутые инструменты вы сможете избежать долгих и тяжких процедур с попыткой понимания где же точка доступа была повешена неправильно и определения правильности модели и количества этих точек.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59