😰 Осторожно - мошенники 😰

Коллеги, привет! Хочу поделиться двумя схемами, которыми сейчас пользуются мошенники для удаленщиков и ИТ-специалистов.


🎭 Утечка персональных данных с предыдущего места работы

Несколько месяцев назад мне написал «бывший руководитель» в TG, без номера, как новый контакт.

Разговор начался с “как дела”, а потом он сообщил, что произошла утечка моих перс данных.

Я начала переживать. Спасибо, что сказали. Но.. Почему мне об этом пишет руководитель, вместо отдела кадров?

Хотела перевести на английский и показать подруге. Вставляю текст в Google Translate. И... (смотрите скрин)

После моего вопроса “руководителю” контакт самоудалился 💨 А я успела снять скрин, чтобы задать вопрос в HR.

Позже узнала, что не одна я такое получала. Другие люди, другие компании - аналогичная история.

Что хотели? Не знаю.


🎭 “Вы приняты на работу! Мы отправим вам чек на 2000$ для покупки оборудования”

Тут больше про США, история знакомого программиста.

1. Вам проводят онлайн собеседование.

2. Через 1-2 дня дают оффер. Вы радуетесь.

3. Работодатель сразу предлагает прислать вам чек на ~2000$, чтобы вы положили его на свой банковский аккаунт и купили оборудование для работы.

P.S.
Здесь есть чеки, которые можно класть на счет в банке.
Деньги на баланс зачисляются сразу, НО! Если чек был недействителен, то это будет обнаружено только через 1-2 рабочих дня. И получается, что сначала вам на баланс придёт +2000$, а потом их с вас спишут и наложат штраф за фальшивый чек (без комментариев на эту тему, сама в шоке).

4. Вы кладете чек на свой банковский счет, а далее:
- Вам говорят, что дали лишние 1000$ и просят вернуть онлайн-переводом
- Вы идете на “специальный сайт” покупать оборудование

Знакомый сразу понял, что тут нечисто. Полез в гугл искать больше информации про компанию и “is it normal for a company to send you a check to buy equipment”


Этот пост - напоминание о безопасности в Интернете.
Будьте аккуратны. Не доверяйте незнакомцам 🙏

Делитесь под постом, с какими попытками обмана встречались вы 👇

🧐 Каким способом делать вызов API DaData - через Бэк или через Фронт? 🧐 Разбираем ответ на вопрос.

Большинство голосов у нас в сторону варианта “через Бэк” (Backend). Это правильный лучший вариант. Хотя и напрямую “через Фронт” тоже можно делать интеграции.


👌 Использование Backend ShipEasyGA для вызова API DaData

В данном варианте все клиентские приложения (iOS, Android, Web) взаимодействуют с внешним API DaData через Backend.

1. Клиент отправляет запрос Backend
2. Backend принимает запрос и перенаправляет его на API DaData, подставляя в него секретные ключи (пароли, токены и тп)

✅ Безопасность
✅ Централизованная логика и обработка ошибок
✅ Кэширование и оптимизация
❌ Дополнительная нагрузка на Backend
❌ Увеличение времени отклика

Большинство крупных систем (например, банковские приложения, e-commerce платформы) используют именно этот подход для работы с внешними сервисами. Это связано с тем, что он обеспечивает максимальный контроль и безопасность.


👍 Прямой вызов API DaData с Frontend

В данном варианте все клиентские приложения (iOS, Android, Web) взаимодействуют с внешним API DaData без слоя-посредника.

Клиент отправляет запрос Backend на API DaData, подставляя в него секретные ключи (пароли, токены и тп).

❌ Безопасность
❌ Централизованная логика и обработка ошибок
❌ Кэширование и оптимизация
✅ Меньшая нагрузка на backend
✅ Меньшая задержка

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


Заключение

Для системы #ShipEasyGA более оптимальным решением будет использование Backend для взаимодействия с DaData (вариант 1). Это обеспечит большую безопасность и централизованную обработку логики.

Прямые вызовы с Frontend (вариант 2) могут быть уместны только в очень простых сценариях, но они увеличивают риски безопасности и сложности в управлении.

Подробнее и с пояснениями по каждому пунктк разобрала вопрос в мини-книге, прикрепленной к посту 📚

#ИнтеграцииGA

2️⃣ главных вопроса в задачах на Интеграции от Системного Аналитика 🔽

Когда вы получили задачу на интеграцию, то должны задать 2 вопроса разработчикам внешней системы или заказчикам:

📌 Как получить API-документацию?

Без API-документации нет ясности как вообще можно взаимодействовать с внешней системой. Нет понимания даже команд, которые есть в ней.

API-документация может быть передана вам в виде ссылке на Postman-коллекцию, Swagger-коллекцию, сайт разработчика, PDF- или Word-документ.

Увы, до сих пор остается грустной правдой, что некоторые API не имеют документации и для интеграции тебе в email присылают curl-ы (примеры вызовов) нужных запросов, а дальше сами разбирайтесь. Всякое бывает 😔


📌 Как получить тестовые и боевые доступы для проверки API?

Без этого системному аналитику никуда не сдвинуться. Работа будет на ощупь 🤲

Если API-документация есть, то это прекрасно! Но часто, даже в крупных компаниях, бывают несовпадения документации и реальности. Не всегда все ошибки описаны в документации 🙁

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


Как только документация появилась на руках, то можно начать её исследования и собирать нужную для работы информацию:

1. Оглавление
2. Авторизация и аутентификация
3. Тестовые доступы, если еще не получили
4. Рекомендации по использованию API
5. Список методов, необходимых для реализации ваших интеграционных сценариев
6. Общие требования к обработке ошибок

Подробнее про исследование API внешних систем расскажу в следующих постах 😎

#ИнтеграцииGA

🧑‍🔬 Исследование API внешней системы: инструкция 🧑‍🔬

Исследование API внешней системы - основной шаг при работе с задачами интеграцию систем.

Поэтому, как только API-документация или её подобие получены, можно начинать аналитику по задаче. До этого задачу стартовать практически нереально.

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

----------------------

Инструкция по исследованию API:

◽️1. Оглавление
Найти разделы, в которых потенциально есть информация по следующим пунктам из этой инструкции.

◽️2. Авторизация и аутентификация, ограничения
Все запросы скорее всего будут иметь ограничения по доступу. Важно понять механизм авторизации и описать программистам какие параметры надо будет хранить в конфигурациях, что отправлять в хранилище ключей и подобное.

◽️3. Тестовые доступы, если еще не получили
Нужны для проверки как реально работает API через Postman или другой инструмент, и насколько API соответствует документации.

◽️4. Рекомендации по использованию
Примеры сценариев использования. Это не всегда есть в API-документации. Но если есть, то считайте, что задача почти готова. Предложенный сценарий интеграции надо адаптировать под бизнес-процессы текущего проекта.

◽️5. Список методов, необходимых для реализации ваших интеграционных сценариев
На этапе знакомства с документацией сильно вчитываться не надо. Главное понять, что методов для реализации бизнес-процессов текущего проекта достаточно.

◽️6. Общие требования к обработке ошибок
Коды ответов, структура сообщений, сценарии.

----------------------

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

#ИнтеграцииGA

🧑‍🔬 Исследование API: пример для DaData 🧑‍🔬

В предыдущем посте опубликовала инструкцию по исследованию API-документации. Теперь хочу показать как она работает на практике для проекта #ShipEasyGA.

----------

◽️1. Оглавление
В онлайн-документации DaData сначала показывается общий справочник всех API. В нем нам могут подойти:

🟢 Разбор адреса из строки («стандартизация»)
🟢 Автодополнение при вводе («подсказки»)
🟢 Геокодирование для определения координат адреса, если их не будет в основном API по стандартизации адресов.

Внутри документации по отдельным API есть собственное содержание, под заголовком:
+ Как вызвать
+ Что в ответе
+ Коды качества
+ Примеры
+ Ограничения
+ Стоимость

Так устроено оглавление в DaData. Еще пример подобной структуры: Авито.


◽️2. Авторизация и аутентификация, ограничения

На всех страницах API-документации 🟢, в разделе “Как вызвать”, вы найдете стандарте стандартную фразу:

Чтобы вызвать метод, и подтвердите почту.

Часто бывает отдельный раздел “Аутентификация”, “Начало работы” как в Авито, или подобный, где описаны эти требования.

Также обращаю внимание на разделы “Ограничения” и “Стоимость”. Через них можем понять, что API платный, и у нас есть расходы на работу системы, которые нужно согласовывать с бизнесом.

Для платных API всегда важно подумать над алгоритмом работы: про минимизацию количества вызовов за счет хранения части данных у нас (кэширование).


◽️3. Тестовые доступы

Для DaData тестовый доступ отсутствует. Если хочешь пользоваться API, то только боевая площадка.

В таком случае рекомендуется завести два аккаунта: для тестирования и боевой. Но это не всегда удобно. Смотреть по ситуации.


◽️4. Рекомендации по использованию

Смотрим раздел “Как вызвать” в документации DaData, где нам предлагают примеры запросов и ответов. Это максимум, который можем найти для DaData.

Но некоторые системы, особенно платежные, предлагают готовый сценарий интеграции. Посмотрите на пример документации от СберПэй. Осталось адаптировать предложенное под нашу систему.


◽️5. Список методов, необходимых для реализации ваших интеграционных сценариев

В DaData у нас просто три разных страницы 🟢, которые могут подойти. Пока я на этапе первичной аналитики, то считаю, что 3 метода подходят, но надо будет финализировать этот список.


◽️6. Общие требования к обработке ошибок

В DaData дают “Коды ответа на запрос” на отдельных страницах документации 🟢, но не всегда.

В СберПэй подробно расписаны примеры ошибок на каждый запрос.

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

А иногда это вообще опускают и не делают. Всякое бывает 😁

----------


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

👉 Далее перехожу к тестированию API-методов, выделенных в п.5.
Тестирование помогает понять, как работает API и убедиться, что все соответствует документации.
Это нужно, чтобы после передачи задачи в разработку программисты не сталкивались с проблемами неработоспособности внешних систем и задача не вставала.

#ИнтеграцииGA

🔥 Новое практическое руководство по Postman - с нуля до результатов 🔥

Один из первых и основных шагов при работе систеных аналитиков с задачами на интеграции — проверка API внешней системы.

Основной инструмент для тестирования и документирования API: Postman.

Если вы еще не использовали его в работе, хотите освоить или получить дополнительную практику, то я подготовила подробную инструкцию с картинками для вас 🧡

В ней вы найдете следующие API DaData:

▫️ Разбор адреса из строки («стандартизация»)
▫️ Автодополнение при вводе («подсказки»)
▫️ Геокодирование

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

Больше всех подходит "Автодополнение при вводе («подсказки»)". Его и будем использовать для дальнейшей работы 🙂

#ИнтеграцииGA