API *

Встречайте, вот и Go 1.18, а с ней – первый релиз долгожданной реализации дженериков, наконец-то готовых к реальному использованию в продакшене. Дженерики – это весьма востребованная возможность, давно вызывающая жаркие споры в сообществе Go. С одной стороны, самые голосистые беспокоятся по поводу сложности, которую привносят дженерики. Их страшит неизбежная эволюция Go, которая доведет его либо до многословия как в энтерпрайз-версии Java, со своими обобщенными фабриками, либо, самое страшное, превратит Go в вырожденный HaskellScript, где if-ы придется заменить монадами. Положа руку на сердце, оба этих опасения могут быть преувеличенными. С другой стороны, поборники дженериков считают, что дженерики критически важны для масштабного внедрения чистого кода, пригодного для многоразового использования.

Автор этой статьи не принимает ни одну из сторон в данных дебатах и не дает рекомендаций, где и в каких случаях использовать дженерики в Go. Напротив, эта статья призвана осветить запутанный случай с дженериками в Go с третьей стороны: с точки зрения системных программистов, которые воодушевлены не дженериками как таковыми, а мономорфизацией и тем, как она может сказаться на производительности. Нас таких десятки. Десятки! И мы все имеем изъявить некоторое серьезное разочарование.

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

Всем привет. Как часто вам нужно разрабатывать сотни авто тестов и предоставлять заинтересованным лицам отчеты с результатами? Лично мне очень часто. В этом мне помогает Anna.

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

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

Скорее всего вы знаете, что такое Confluence и для чего он нужен. Если нет, коротко скажем, что это пространство/сайт, где вы копите все знания о вашей деятельности в организации. То есть, например, выполняя какой-либо проект, параллельно ведете свой раздел в Confluence, чтобы новый сотрудник смог быстрее в нем разобраться. Также это мощный инструмент для различной аналитики, ведения статистики, но, если вам потребуются дополнительные инструменты и «фишки», нужно будет их оплатить, так как они не будут доступны в бесплатной версии.

Специалист Neoflex из подразделения Big Data Solutions рассказывает о проблеме, с которой он столкнулся:

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

Зная такие инструменты как Selenium и язык программирования Python, мною была написана рекурсивная функция от нужного отдела по всем его дочерним объектам. В ходе выполнения наткнулся на большое количество проблем: например, отсутствие id в url, принадлежность одной страницы другому разделу, медленная работа, несоответствие стилей и т.д. Вся работа строилась на простом алгоритме: проходить все страницы, сохранять необходимый текст в тегах в html файл для дальнейшего преобразования в DOCX. Почему пришлось отказаться от данного подхода:

Всем привет!

Данная статья является гайдом по построению REST прокси поверх существующих gRPC сервисов. После прочтения данного материала можно будет вызывать любой из существующих gRPC сервисов используя стандартный REST API, а так же получить полную документацию в swagger формате.

Недавно нужно было написать API автотесты - запросы Post с большим количеством параметров в теле, в том числе вложенные JSON объекты, массивы , массивы JSON объектов. Многие параметры не обязательные, а значит - большое количество наборов тестовых данных.

Дано: Датапровайдер - для многократного запуска тестов, тестовые данные в таблице Excel.

Что бы сформировать тело первого запроса пришлось создать несколько классов, через сеттеры присваивать значения переменным в классе и из базового класса формировать JSON, который и использовался как тело запроса. И вдруг оказалось, что все написанное никак не получится переиспользовать для других эндпоинтов. Тогда и решил написать метод, который будет превращать таблицу Excel в JSON объект без всяких там классов и правок в коде. Нужно только придерживаться некоторых правил при составлении таблицы.

Итак! Для получения данных из таблицы использовал, как обычно, Fillo. Название столбца будет ключом, значения в столбце, собственно, значениями ключа в запросе. Строка таблицы - один набор тестовых данных.

В данной статье мы рассмотрим систему аутентификации пользователей и внешних систем в личном кабинете через сервер аутентификации Blitz Identity Provider. 

Согласно требованиям проекта, который мы рассмотрим здесь в качестве примера, взаимодействие клиентской и серверной частей должно происходить по Rest API, реализованном на микрофреймворке Slim. Для авторизации пользователей необходимо провести интеграцию с сервером аутентификации Blitz Identity Provider, который в свою очередь интегрирован с внутренней системой единого входа заказчика (SSO). Это мастер-система, определяющая возможность доступа и уровень доступа пользователя для личного кабинета является Blitz. Поэтому при каждой авторизации пользователя в системе обновляется уровень доступа по данным из Blitz. 

Данные в личный кабинет должны приходить из систем хранения информации (ERP и SRM) и управления учетными записями пользователей, также использующие Rest Api Личного кабинета. Эти системы должны проходить аутентификацию напрямую в ЛК.

Содержание:

Описание системы Blitz Identity Provider и протокола авторизации OAuth 2.0

Схема работы личного кабинета с Blitz

Аутентификация React-приложения в системе

Аутентификация внешних систем

Есть стереотип, что финансы — это консервативная сфера, где нет места айтишному веселью. Взять хотя бы швейцарские банки, где до сих пор используется ПО, написанное на Коболе: скука, стресс и ответственность за чужие миллионы.

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

Как и любой финтех, Росбанк уже не просто банк, а целая сеть связанных и не очень услуг, продуктов и сервисов. Большинство из них развёрнуты в сторону клиентов, но есть и те, что смотрят в светлые глаза сотрудников IT-департамента. Про них сегодня и пойдёт речь. А точнее, про команду автоматизации инфраструктурных задач и их основной продукт — внутренний портал MyGTSSpace.

Разработка интуитивно понятного и удобного RESTful API — непростая задача. Она даже может оказаться весьма сложной задачей, если это ваша первая попытка. Планирование управления жизненным циклом вашего API, скорее всего, будет казаться второстепенным. Однако во всяком случае развитие вашего API весьма вероятно.

Поэтому в этом посте я хотел бы предложить пошаговый подход к развитию ваших API, даже если это не было запланировано сразу.

Меня зовут Рустам, и я техлид в компании Distillery. Мы занимаемся разработкой мобильных приложений и веб-сервисов. Хочу рассказать, как мы с коллегами решили немного поэкспериментировать с технологией GraphQL

Для начала о том, что такое GraphQL. Это язык запросов для API, который разработали в Facebook в 2012 году. Он позволяет клиентам запрашивать ограниченное множество данных, в которых они нуждаются. GraphQL использует строго типизированный протокол, и все операции с данными проверяются в соответствии со схемой. 

Это хороший вариант для проектов, в которых разным типам клиентов (например, мобильному приложению и сайту) нужны разные наборы данных. С GraphQL мы заранее описываем схему запроса и ответа, а клиент сам указывает, какие данные ему необходимы. 

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

В целом у GraphQL есть несколько сильных сторон:

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

Подробнее с проектом можно ознакомиться на его сайте или, напрмер, по ссылкам на хабре. Состояние проекта - Apache инкубация. Так как java NLP сообщество весьма ограничено, продукт имеет небольшое, но достаточно активное количество пользователей.    

Привет, Хаброжители! Стартовала весенняя распродажа от издательства «Питер».

Эту статью также можно было бы назвать «Чего по науке нельзя делать с GraphQL».

Читая различные посты в блогах и руководства, мы узнаем, что существует некий правильный способ работы с GraphQL. Но вдруг там о чем-то не упоминается? Потому, что какие-то вещи невозможно реализовать, либо потому, что та или иная реализация – это «очень плохая идея»?

Давайте немного повеселимся и поиграем с GraphQL нетрадиционным образом. Я не призываю вас реализовывать какие-либо из идей, изложенных здесь, и им определенно не место в продакшен-коде (но, если вы совершенно уверены в том, что делаете – почему нет). В этой статье я просто продемонстрирую несколько экспериментов, которые сам проделал с GraphQL. Некоторые из них – просто классные фокусы. Другие могут вам по-настоящему пригодиться. Мне же все они кажутся потрясающими.

Если вы приняли решение внедрить систему управления проектами – а особенно, если вы делаете это впервые, то наверняка задаетесь вопросом: как сделать все правильно, минимизировать ошибки, прийти именно к тому результату, который ожидаете?

Прежде всего, нужно понимать, что внедрение информационной системы управления проектами (ИСУП) существенно отличается от внедрения других классов информационных систем. Если вы внедряете, например, систему биллинга, или финансового учета или систему управления складом – то ваше внедрение в некотором смысле обречено на успех. В определенный момент возврат к прежним инструментам становится невозможным, а без использования нового инструмента бизнес попросту остановится. В итоге внедренная система будет работать, даже если процессы настроены не оптимально, и дефекты латаются на ходу.

С ИСУП все не так однозначно: эффекты от внедрения наступают далеко не сразу, видны не на всех уровнях управления, в умах пользователей возникают сомнения, а нужно ли это все, ведь работали как-то раньше, и неплохо работали.

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

В это пример я буду рассматривать только парсинг и валидацию токенов что уже пришли в мое API в Authorization хедере. Для генерации токенов, регистрации пользователей и прочего SSO есть много готовых решений которые легко установить или даже устанавливать не надо. Например, Auth0, Keyckloak, IdentityServer4. В пример е буду работать с Tapir который может использовать в качестве бекенда http4s, Akk HTTP, Netty, Finatra, Play, ZIO Http, Armeria. Я буду использовать Tapir + Http4s.

Сталкиваясь с атаками на веб-ресурсы, администраторы пытаются перекрыть вредоносный трафик настройками веб-сервера, установкой Rate Limit, созданием правил блокировок или ограничением доступа по IP из списка стран. Эти действия требуют навыков и не всегда приводят к ожидаемым последствиям.

В статье расскажу, как обеспечить быструю и качественную защиту веб-приложений и API от большей части угроз OWASP Top-10 с использованием бесплатной версии Nemesida WAF Free.

«Заставь дурака Богу молиться — он лоб разобьёт»

Здравствуйте! Хочу поделиться накипевшим - головной болью интеграции с API сторонних приложений. В этой статье - c авторизацией для API достаточно популярной amoCRM, без кода и лишних деталей.

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

Я поделюсь практическим опытом нашей компании в защите e-commerce приложений и продемонстрирую реальные кейсы противодействия парсинга и бот-атакам. 

В рамках статьи я сосредоточусь на атаках, которые относятся к типу Scraping по классификации OWASP. Детальную классификацию автоматизированных угроз веб-приложениям можно изучить в документе OWASP Automated Threats to Web Applications. Конечно, противодействие бот-атакам данного типа позволит остановить и другие автоматизированные атаки, но в нашей практике мы видим, в основном, именно атаки типа price scraping – автоматизированный сбор информации о товарах и ценах, или парсинг цен. Я не рассматриваю юридические и морально-этические вопросы парсинга цен в данной статье.

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