Теперь всем API-токенам можно ограничивать права. На уровне всех проектов сразу, или каких-то конкретных.
Можно выдавать права только на просмотр, на полное управление или полностью закрывать доступ к сервисам.
Это доступно как администраторам, так и доп пользователям — с учетом их собственных прав. При этом админ будет видеть, кто выпустил конкретный токен. А при блокировке доп пользователя автоматически удалятся и все выпущенные им токены.
Как в нативе: эти Web API поднимут ваше веб-приложение в стратосферу
Салют, на связи Clevertec. Сейчас наша команда разрабатывает веб-версию банкинга с использованием React. С помощью Web API даем пользователям фичи, которые они привыкли получать в нативных приложениях. Отрываем от сердца список решений 😉
- Web Share API – для обмена ссылками, текстом и файлами с другими приложениями на устройстве. К примеру, удобно отправить чек об оплате в мессенджере, не покидая банковское приложение.
- Contact Picker API позволяет делиться контактами из своего списка. Можно использовать для перевода по номеру телефона. Не нужно вводить цифры вручную – поле автоматически заполнится контактом из телефонной книги.
- Media Capture and Streams API в нашем случае позволяет отсканировать QR-код с помощью камеры устройства. Нажимаешь на “Сканировать QR” – открывается окно с камерой, она считывает код и переводит пользователя в дерево платежей.
- Web OTP API открывает возможность автоматически вставлять код из смс. Например, для подтверждения оплаты на телефон приходит сообщение. Внизу экрана появляется модальное окно с подтверждением вставки. И после нажатия на “Разрешить” код отображается в поле ввода.
Подробнее про этот опыт использования Web API мы рассказали в отдельной статье. Что вы думаете о Web API, какие используете? Расскажите в комментариях, будем взаимно полезны друг другу.
Как в Авито устроено API-тестирование на Go?
В этом видео Глеб Дмитриев, инженер из команды Marketplace, рассказывает о проблемах, с которыми мы сталкивались на этапе выбора фреймворка для тестирования, и показывает, как работает наш собственный фреймворк на основе Testify.
Мы используем автотесты на всех уровнях пирамиды тестирования. Но общедоступные фреймворки и их предложенная архитектура не всегда подходят под наши технические решения. Поэтому мы выстроили свою архитектуру API-тестов и сделали свой фреймворк, который отвечает нашим требованиям по скорости, архитектуре и покрытию.
Ранее Александр Трифанов, техлид Авито, рассказал о нашем подходе к сканированию данных в API.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
В прошлом посте мы рассказали о нашем ПО Capsule для считывания, анализа и записи физиологических сигналов мозга и тела. Сегодня — про особенности интерфейса и API Neiry, которые нас радуют больше всего.
Capsule ориентирован на широкий круг пользователей. Научные коллективы могут использовать сырые потоковые или записанные мультимодальные данные для исследований. Те, кто не обладает глубокими знаниями в нейрофизиологии и смежных областях, запросто интегрируют готовые метрики на основе ЭЭГ и ФПГ в продукты.
Мы храним необработанные мультимодальные данные в формате HDF5. С готовыми метриками можно работать в понятном для продукта виде. Когнитивная нагрузка со шкалой от 0 до 100 — пожалуйста, уровень усталости или расслабления в виде численного значения — запросто.
Нужно проверить гипотезу или разработать алгоритм «с нуля»? Потоковые сырые данные до фильтрации вам в помощь! Не хотите возиться с фильтрацией сигнала? Нет проблем, вот те же данные напрямую с АЦП, но после применения валидированных фильтров.
На устройстве небольшое количество электродов для снятия ЭЭГ, но мы постарались разместить их максимально разумно: два в затылочной области, два в височных, а референтный электрод и датчик ФПГ — на лбу.
Подробности расскажем и покажем на хакатоне BCI Hack Moscow 20–22 сентября. С помощью Neiry Headband Pro и API Neiry соберем игру на Unity, будем управлять устройствами умного дома, техникой и устроим брейн-ралли! Возможно даже покажем «Нейробуханку». Приходите, будет интересно.
Привет! На связи команда Neiry Tech, мы занимаемся разработкой BCI-устройств и алгоритмов для использования с ними. Расскажем про ПО Capsule, считывающее и записывающее мозговую активность, и другие физиологические сигналы пользователя. И Capsule API — он помогает нам строить на основе классифицированных метрик и индексов итоговые приложения).
По сути Capsule — библиотека для десктопных и мобильных платформ с собственным графическим интерфейсом. Для быстродействия написали её на C++. Для Capsule API выбрали C.
Для вывода в API на разных платформах иногда пишем нативный код на Android или iOS, ну и обертку на C, чтобы API мог использовать широкий спектр разработчиков — за родным ноутом и в лаборатории.
Физиологические данные — сложные сигналы с высоким уровнем шума. Для их интерпретации нужно хорошо владеть методами цифровой обработки сигналов, погрузиться в предметную область, и как минимум понимать, чем фильтр Чебышева отличается от фильтра Баттерворта.
Головной боли добавляют особенности различных платформ — с плавающими задержками протокола BLE, или с реализацией вроде бы базовых вещей. Мы как-то обнаружили, что библиотека, занимающаяся быстрым преобразованием Фурье, нагружала новенькие Apple Silicon на 30%.
Сейчас Capsule и API позволяют работать с данными ЭЭГ и ФПГ на высоком для не лабораторного устройства уровне. Смотрим, радуемся и гордимся.
Хотите поработать с этими данными и нашим API? Присоединяйтесь к хакатону BCI Hack Moscow, регистрация до 15 сентября.
Банкам не хватает просмотрового API
У меня несколько карт в нескольких банках. И мне очень не хватает возможности вывести все балансы всех карт в своем боте и сделать механизм оповещений о приближении баланса к пороговому.
Я каждый месяц выбираю категории кешбека и переключаю карты в приложениях. Например, вкусвилл — в этом месяце он у меня на ВТБ (категория супермаркеты). Средний заказ в ВВ — 3000 рублей и важно чтобы на карте было не меньше, потому что жена заказывает без предупреждения:)
На самих картах держать большие суммы нелогично в плане безопасности и по причине высоких ставок на накопительных счетах. Поэтому на картах держится X*2, где X — средние затраты по карте за день.
Смотреть за это глазами очень неудобно и у меня глаза ленивые, забывчивые и вообще мне доверять что-то помнить нельзя. Поэтому у нас с женой частое сообщение — "Антон, пополни карту для ВВ".
Очень жду, когда у банков будет просмотровый API, чтобы я мог подтягивать баланс по картам и счетам для отслеживания и сведения балансов. Понимаю, что это может противоречить политикам безопасности, но было бы дико удобно и мне нужен только "режим просмотра".
В комментах к посту в моем тг-канале кинули ссылку на новость от ЦБ, что 2026 у крупных банков должно будет быть API, а потом у всех МФО. Жду этого, возможно, даже больше чем полностью электронные документы для езды за рулем (права, доки на авто).
Всем привет!
Я уже писал о пользе стандартизации на примере формата данных для сохранения информации о сборке - cyclonedx. А недавно в посте про работу с исключениями упоминал библиотечку для возврата ошибок в API - jdoctor.
Так вот - стандартизация добралась и сюда)
Во-первых, как выяснилось - уже с 2016 года есть стандарт "Problem Details for HTTP APIs"
Во-вторых - в Spring Boot 3, т.е. с 2021 года, появилась его имплементация. Вот неплохое описание у baeldung
Если вкратце - ответ при ошибке будет иметь стандартизированный вид похожий на такой:
{
"type": "about:blank",
"title": "Bad Request",
"status": 400,
"detail": "Invalid request content",
"instance": "/sales/calculate"
}
Библиотеки, решающие подобную задачу в Java, уже были:
уже упомянутый jdoctor
error-handling-spring-boot-starter
Но думаю, что именно данное решение - от Spring, да еще по стандарту - имеет шансы популяризовать данную практику.
Что еще хочется отметить:
стандартизация рулит) Каждый поставщик API разрабатывает формат для ответа при ошибке, каждый потребитель - специфический код для его обработки. А при этом понятно, что формат информации об ошибке мало зависит от бизнес-процесса
еще в 2018 году в Сбере формат ответа для REST был стандартизирован. Но, увы, формат отличается от RFC, а область применения ограничена взаимодействием с фронтом.
МТС представила платформу для бесшовной интеграции сервисов. Это собственная разработка компании — Интеграционная платформа (Integration Platform), которая позволяет бесшовно интегрировать сервисы в экосистему и обеспечивать их взаимодействие друг с другом.
На первом этапе платформа объединяет все API экосистемы в единый стек и позволят строить сложные интеграционные сценарии запуска сервисов, в том числе без привлечения разработчиков, через citizen developers — специалистов, которые создают сложные IT‑продукты, не имея глубинных знаний в области программирования.
Проект Integration Platform поддерживает широкий спектр индустриальных протоколов и стандартов, использует встроенные инструменты Low/No‑code и технологии искусственного интеллекта.
В ближайшее время платформой будет доступна внешним клиентам МТС, сфокусированным на модернизации ИТ‑ландшафта. Потенциальный экономический эффект от внедрения оценивается МТС в миллиарды рублей.
«Раньше создание новых продуктов требовало разработки новых API, команды искали актуальную документацию на существующие API, решения дублировались, подписание требовало согласований и обсуждений, был необходим единый реестр c полной документацией и понятным UX для подключения и публикации. Интеграционная платформа решила эту задачу. Это разработка МТС превосходит зарубежные аналоги по надежности, производительности и масштабируемости», — пояснил первый вице‑президент по технологиям МТС Павел Воронин.
Хакер под ником emo выложил в свободный доступ (при оплате) базу данных пользователей сервиса управления проектами Trello (trello.com).
Известно, что информация хакером получена с помощью запросов к официальному API сервиса, а не в результате взлома.
ИБ-исследователи выяснили, что хакер использовал открытый API Trello для связывания почтовых адресов с профилями пользователей. В итоге хакер подготовил список из 500 млн адресов электронной почты и направил их через открытый API, чтобы определить, связаны ли они с аккаунтами Trello. Злоумышленник заявил, что закупил прокси для ротации соединений и запросов через API непрерывно. После этой атаки API Trello был усилен и стал требовать аутентификации, хотя он по-прежнему доступен любому, кто создаст бесплатный аккаунт.
«У Trello был открытый API-эндпоинт, который позволял любому неаутентифицированному пользователю связать адрес электронной почты с аккаунтом Trello, — пишет emo. — Изначально я собирался отправлять эндпоинту только письма из баз данных com (OGU, RF, Breached и так далее), но потом решил продолжать [проверять] email'ы, пока не надоест».
В опубликованной хакером базе данных содержится 15 115 945 строк, включая:
адрес эл. почты;
имя/фамилия;
логин;
ссылку на аватар.
ИБ-специалисты считают, что информация из этой базы может использоваться для проведения целевых фишинговых атаках, а сам emo пишет, что данные также могут пригодиться для доксинга, так как позволяют связать email-адреса с конкретными людьми и их никами.
Чем занимаются Go-специалисты в Островке?
У нас 10 команд, использующих Go, как основной язык. Для примера возьмём команду интеграций с поставщиками отелей. Вот что делают разработчики в этой команде:
Адаптируют API различных поставщиков к внутреннему API сервиса. Внешние поставщики отелей используют разные технологии: GraphQL, XML, SOAP, WTF. В каждом API своё время ответа, свои коды ошибок и ещё много кастомного.
Поддерживают и правят существующие интеграции. Протокол сменился, или (куда реже) коды ошибок стали другие — всё надо держать в актуальном состоянии и при необходимости править.
Уменьшают технический долг. Это задачи, связанные с библиотеками и рефакторингом. Есть правило — на одну итерацию должно приходиться 75% продуктовых задач и 25% техдолговых.
Дежурят в общем чате. В нём разработчики отвечают на вопросы менеджеров. Раньше дежурств не было, на вопрос отвечал тот, кто увидел его первым. Когда поток обращений вырос, решили назначать дежурного.
Обмениваются знаниями внутри компании. В Островке есть активности, напрямую не связанные с работой. Например, канал в слаке #dev-golang и еженедельный книжный клуб.
Отдельно отмечу багфиксы, которые порой превращаются в настоящие расследования инцидентов. Кроме того, команда интеграций с поставщиками отелей сейчас переписывает легаси частей системы и разрабатывает свой линтер, о котором у нас будет отдельная статья.
Приглашаю на вебинар компании Вебмониторэкс 28 июня в 12:00, посвященный предотвращению утечек API и новым функциям в продукте «ПроAPI Структура».
Ведущие вебинара - Антон Будник, инженер продаж и Сергей Одинцов, системный аналитик Вебмониторэкс.
На этом вебинаре раскроем темы:
О предотвращении утечек API:
Основные методы взлома API
Описание рисков утечки данных через API: ключевой вопрос кибербезопасности
Изучение последствий взлома API
Разбор крупных инцидентов утечек данных через API
Методы защиты API с помощью компонента «Обнаружение утечек AP» продукта «ПроAPI Структура» платформы «Вебмониторэкс»
О новых функциях продукта «ПроAPI Структура»:
Настройка чувствительности определения роута на трафике
Очистка построенной структуры API
Создание правил для параметров роута
Кому полезно:
Специалистам, участвующим в разработке критичных для бизнеса веб-приложений
Руководителям подразделений по информационной безопасности- Специалистам Application Security Почему полезно:
Увидите пример реализации борьбы с утечками секретов и токенов на платформе «Вебмониторэкс»
Увидите новые функции защиты API на платформе «Вебмониторэкс»
Регистрируйтесь по ссылке
Скорее подписывайся на специальный Telegram-канал, в котором команда Вебмониторэкс рассказывает все об API Security, Web Security, трендовых уязвимостях и публикует анонсы об изменениях в продуктах.
Задача обеспечения безопасности REST API может быть менее очевидной, но важно помнить, что REST API используется везде, где пользователю сайта или приложения нужно предоставить данные с сервера.
Приглашаю на вебинар 30 мая в 12:00, посвященный превентивной защите REST API.
Ведущие вебинара — Вадим Шепелев, инженер по информационной безопасности Вебмониторэкс и Лев Палей, CISO Вебмониторэкс.
О чем расскажем на вебинаре:
Польза от спецификации API и как её собрать на основании трафика
Какие типы уязвимостей это позволит обнаружить
Как уменьшить поверхность атаки при помощи «ПроAPI Защита»
Регистрируйтесь по ссылке.
В наше время все больше компаний предоставляют свои возможности через API. Задача обеспечения безопасности REST API может быть менее очевидной, но важно помнить, что REST API используется везде, где пользователю сайта или приложения нужно предоставить данные с сервера.
Компания Вебмониторэкс приглашает на вебинар 30 мая в 12:00, посвященный превентивной защите REST API.
Ведущие вебинара — Вадим Шепелев, инженер по информационной безопасности Вебмониторэкс и Лев Палей, CISO Вебмониторэкс.
О чем расскажем на вебинаре:
Польза от спецификации API и как её собрать на основании трафика
Какие типы уязвимостей это позволит обнаружить
Как уменьшить поверхность атаки при помощи «ПроAPI Защита»
Кому полезно:
Специалистам, участвующим в разработке критичных для бизнеса веб-приложений
Руководителям подразделений по информационной безопасности
Специалистам Application Security
Почему полезно:
Актуальная проблема защиты REST API обусловлена участившимися атаками на веб-ресурсы российских компаний
Регистрируйтесь по ссылке.
Google сообщила разработчикам, что начинает взимать плату за использование Gemini API. С 30 мая 2024 года платным становится доступ к Gemini 1.5 Pro, с 14 мая плата будет взиматься за использование Gemini 1.0 Pro.
Вместе с этим компания ещё раз напомнила про более доступный тариф Gemini 1.5 Pro. В рассылке для разработчиков подчёркивается, что платным становится только доступ к языковой модели через API, в Google AI Studio с нейросетями можно будет работать бесплатно.
Найти все API — важная задача в процессе выстраивания их успешной защиты. Поэтому, имея сведения о структуре своих API, вы уже окажетесь на шаг впереди злоумышленников. А что делать с этой информацией?
Компания Вебмониторэкс ответит на этот и другие вопросы на своем вебинаре 16 мая.
Теорию подкрепит практический кейс заказчика.
О чем расскажем на вебинаре:
- На что обратить внимание при обеспечении безопасности API в современных условиях. - Изменения в инфраструктуре. Что дальше?
- Защита и управление API. Почему это важно.
- Подходы по защите API. От зрелости к эффективности: Знать. Защищать. Не допускать. - Реализация на платформе «Вебмониторэкс»: компоненты для защиты и управления API.
Ведущий вебинара — Лев Палей, CISO Вебмониторэкс. Специальный гость — Кирилл Ильин, CISO «СберАвто». Он честно и открыто расскажет о задачах, практике и результатах защиты API в своей компании.
Кому полезно:
- Специалистам, участвующим в разработке критичных для бизнеса веб-приложений
- Руководителям подразделений по информационной безопасности
- Специалистам Application Security
Почему полезно:
- Узнаете о современной концепции управления API
- Увидите пример ее реализации на платформе «Вебмониторэкс»
- Услышите от CISO об успешном опыте защиты и управления API на примере компании «СберАвто»
Регистрируйтесь по ссылке.
Вебинар про защиту API 16 мая в 12:00
В очередной раз убедились, что сила Хабра — в сообществе. Сторонние разработчики не только попробовали на практике наш YandexGPT API, но и даже создали для него SDK, который теперь доступен всем в опенсорсе с хорошей документацией.
Обо всём этом они рассказали в своей статье на Хабре. Рекомендую почитать.
Вебмониторэкс приглашает вас 17 апреля в 12:00 (мск) на вебинар, во время которого мы раскроем тему значимости обеспечения безопасности API в современных условиях.
Ведущие вебинара - Лев Палей, CISO и Сергей Одинцов, системный аналитик Вебмониторэкс.
Расскажем об изменении ландшафта угроз и отражении этих изменений в OWASP API Security.
Подробно рассмотрим обеспечение безопасности веб-приложений в наиболее атакуемых отраслях (телекоммуникационные компании и интернет платформы).
Покажем, как платформа «Вебмониторэкс» решает задачи по защите веб-приложений и API.
Почему полезно:
- Узнаете о новых уязвимостях в OWASP API Security и вариантах их эксплуатации
- Получите рекомендации по защите своих API
- Увидите примеры, иллюстрирующие изменения OWASP API Security
Продолжительность вебинара 1 час 30 минут!
Регистрируйтесь на вебинар по ссылке.
Интересно, читают ли посты на Хабре. Вот сейчас и проверим — у нас две хорошие новости про YandexGPT.
Во-первых, мы открыли API — теперь для всех пользователей в режиме превью. Это значит, что вы сможете использовать возможности нашей языковой модели в своих решениях.
Во-вторых, готовимся к запуску бета-тестирования новых возможностей Алисы на базе YandexGPT 2. Чтобы записаться в бета-тестеры, нужно отправить заявку на сайте.
Обновление библиотеки WT Amo CRM для Joomla v.1.2.0
Небольшая нативная PHP библиотека для создания интеграций Joomla и Amo CRM. Для разработчиков.
Что нового?
Joomla 5 ready. Работа библиотеки успешно протестирована с Joomla 5.
Удаление старого refresh token. В параметры плагина добавлена кнопка для удаления старого refresh-токен из базы данных.
Языковые константы. Параметры плагина переделаны на использование языковых констант Joomla. Добавлена английская локализация.
Как тестировать internal методы и классы в C# — InternalsVisibleToAttribute
![[assembly: InternalsVisibleToAttribute("YourProject.UnitTests")]](https://habrastorage.org/getpro/habr/upload_files/2a6/066/368/2a6066368f2394a9024ee57a5504259f.jpg "[assembly: InternalsVisibleToAttribute(\"YourProject.UnitTests\")]")
Представьте, что вы разрабатываете библиотеку, которой будут пользоваться тысячи людей ?. Чтобы убедиться в стабильности — нужно всё хорошенько покрыть тестами. Все мы любим инкапсуляцию, верно (я надеюсь)? Поэтому мы не разрешаем использовать всё подряд из нашей сборки, а с умом используем модификаторы доступа и позволяем использовать только public классы и методы.
В C#, есть 7 модификаторов доступа, основные:
- private — доступ только внутри текущего класса
- protected — доступ внутри текущего и дочерних классов
- public — классы и методы доступны где угодно, также из сборок, использующих текущую
- internal — публичный API, внутри текущей сборки. Как public, но нет доступа из сборок использующих текущую
- остальные можно посмотреть тут
Но, C# — не JavaScript, и для тестов создаётся отдельная сборка, а internal методы в ней не доступны.
Чтобы тестировать internal функциональность, нужно использовать атрибут InternalsVisibleToAttribute, и в качестве параметра указать имя тестовой сборки. Тогда все internal методы и классы будут доступны для тестирования.
[assembly: InternalsVisibleToAttribute("YourProject.UnitTests")]
