Как я реализовал авторизацию в приложение Mini Apps Telegram или почему многие Mini App имеют дыры в безопасности?
Всем привет! Как насчет того чтоб перенять мой опыт?
Сегодня я хочу затронуть две темы, о одной из них мало информации в открытых источниках. Первое - это как я реализовал защиту в Telegram на REST API. Второе - это какие дыры есть в Mini App Telegram.
Вводные данные
Я разрабатываю Mini App в Telegram, это такая штука открывающаяся внутри бота и есть внутрение приложение Telegram.
Стояла задача разработать приложение с админкой, тратить время на развертывание сервера, налаживание и его защиту не было времени. Нужна оперативная работа.
Изучив возможные варианты, выбрал Strapi - это OpenSource проект написанный на Node.js. Развернуть можно как в облаке так и локально. Имеет поддержку русского языка.
Так выглядит админка Strapi
Если в общем, то мой стек используемых инструментов выглядит следующим образом:
Telegram App ( Библиотека )
Strapi ( Админ панель + REST API )
PostgreSQL ( База данных )
Next.js ( Само приложение )
Стек технологий
Решение с защитой что я предлагаю подойдет каждому. Главное понять его принцип.
Как я защищал REST API? Валидация данных
Когда пользователь открывает веб-приложение через Telegram, ваше приложение получает начальные данные от самого Telegram, такие как идентификатор пользователя и его имя. Чтобы убедиться, что эти данные подлинные и не были изменены, используется специальный процесс проверки.
Преобразование данных: Приложение преобразует начальные данные в удобный формат.
Создание строки для проверки: Из всех параметров (кроме специального hash) создается отсортированная строка.
Создание секретного ключа: С помощью токена вашего бота создается секретный ключ.
Создание цифровой подписи: Используя секретный ключ и строку параметров, создается цифровая подпись.
Сравнение подписей: Приложение сравнивает созданную подпись с полученной от Telegram. Если они совпадают, данные подлинные.
Этот процесс помогает убедиться, что данные, полученные от Telegram, не были изменены, обеспечивая безопасность вашего приложения и его пользователей.
После успешной валидации я генерировал JWT токен для пользователя и он становился полноценным пользователем в моей системе.
Далее можно с ним делать что угодно 😏 - ну допустим заблокировать его, дать права админа и т.д.
А сам пользователь имеет полный доступ к возможностям приложения. Но вне телеграма он ничего не сделает.
Какие дыры есть в приложениях и почему?
Не буду показывать на конкретном примере, но большинство разработчиков не умеют или не хотят защищать свои приложения, а чисто привязывают все к Telegram ID ( ID вашего аккаунта ) и так и живут.
Telegram ID состоит из цифр и перебрать его методом подбора не составит труда и получить доступ к аккаунту в Mini App.
Зачастую этим грешат новые приложения или не опытные разработчики, например в Telegram Apps Store ваше приложение проверяют на наличие этой защиты.
Кроме того нужно учесть что само приложение не должно никоем образом отображаться в поисковиках, если все взаимодействие выстроено на основе телегерама. Приложения же имеют свой адрес и могут индексироваться, не забывайте выключать!
Кроме всего этого можно запретить вне телеграма заходить в ваше приложение тем же способом что описан выше.
Как же защитить приложение и пользователей?
Не важно на каком языке вы пишите, телеграм уже сделал для вас подсказку, осталось ей воспользоваться.
Оставлю ссылку здесь на данный раздел - Документация Telegram
Итого
Я надеюсь эта статья поможет тем кто хочет или уже занимается разработкой WebApp на Telegram. Если все еще осталось что-то не понятно, то пишите смело - будем вместе разбираться:)
Если у вас так же останутся вопросы или предложения или вы просто захотите поделиться своим приложением, то пишите! Всегда рад пообщаться с читателями 😁
Все же так делают, не так ли?
Скуфа не пускают в IT?
Мне 37 лет и я скуф.
Будем считать, что пока да.
Я уже несколько месяцев не пью. И месяц как начал избавляться от лишнего веса.
В общем посмотрел я на все эти IT шные специальности, на солнечные острова, на нежные попы малолетних проституток из Юго-Восточной Азии, на свежий кокоин, собранный девственницами в Колумбии в лунную ночь.
И тоже захотел. А то вокруг мрачный Питер, денег хватает только на проституток из Средней Азии и на пиво по акции из Пятерочки.
Погуглил курсы, и понял, что ничего не понял. Кто то пишет восторг, был дурочком, прошел курс в Сайлент что то там, и уже на Бали. Типа берут сразу же, вокруг гарантии трудоустройства. И прочее. Ни работа, а мечта.
Но беда в том, что английский не мой вариант, в математике и написании кода. В общем не моя тема.
И решил пойти в продажи IT. Благо опыт в продажах есть.
Шлю всем резюме, написал сопроводительное письмо большое.
А отклика нет. Даже отказов.
В отпуске планирую позвонить сам. И всех достать с вопросом "почему скуфа в IT не пускает?"
Кто что посоветует
Олдскулы свело: операторы Собела и Канни
Операторы Собела и Канни, как мы писали в предыдущем посте, стали первыми мощными инструментами, сыгравшими огромную роль в развитии CV.
Почему?
Оператор Собела помогает выявить изменения яркости в изображении, что позволяет находить края объектов.
Как это работает? Допустим, у вас есть фотография, и вы хотите найти на ней границы всех объектов. Оператор Собела берет небольшие области изображения (обычно 3x3 пикселя) и проверяет, как меняется яркость в горизонтальном и вертикальном направлениях. Результат получается за счет применения специальных матриц, называемых фильтрами Собела, которые и выделяют эти изменения.
Оператор Канни — это уже более сложный инструмент для выделения границ. Разработанный Джоном Канни в 1986 году, этот метод до сих пор считается одним из лучших для выявления краев на изображениях.
Оператор Канни использует несколько этапов для достижения точного результата:
Фильтрация шума
Первым делом изображение сглаживается с помощью фильтра Гаусса, чтобы уменьшить шум.
Поиск градиентов
Затем вычисляются градиенты изображения, чтобы определить изменения яркости.
Подавление немаксимумов
Далее проверяется, какие из найденных границ являются локальными максимумами.
Двойная пороговая обработка
В конце применяется двойной порог для выделения сильных и слабых границ, а затем проводится соединение краев.
Даже сейчас операторы Собела и Канни остаются важными инструментами в арсенале ML-инженеров. Их эффективность и простота делают их незаменимыми для многих задач, от предварительной обработки изображений до анализа в реальном времени.
А примеры кода на Python для операторов Собела и Канни вы можете посмотреть по этой ссылке.
Кто чем занимается в разработке и как с ними общаться: подробный гайд
Из кого состоит команда разработки, кто в нее входит кроме программистов, за какие области отвечает каждый из участников и по каким поводам стучаться к ним в личку
Меня зовут Сергей Горшунов. Я веду блог о финансах
Однажды в жизни каждого человека наступает момент знакомства с такой сферой, как разработка. Причины могут быть совершенно разными: реклама во время подкаста на YouTube, устройство на работу в компанию, где есть IT-отдел, чтение новостей, приход нового человека в компанию друзей и так далее.
Не всем нужно знать, кто такие эти разработчики и чем они занимаются, но для тех, кому все-таки понадобилось понимание специфики работы этих людей, мы подготовили гайд. В нем расскажем об участниках команды разработки, их задачах, по каким поводам к ним обращаться и как понять, о чем они говорят.
Команда разработки в лицах
К счастью, у большинства проектов за все не отвечает один единственный человек, похожий на Шиву. Команда разработки на то и команда, что в ее состав входит целый коллектив.
Владелец продукта или PO (Product Owner) — это тот, кто занимается управлением продукта. Он является связующим звеном между заказчиком и командой, выступая за интересы первого. На нем лежит подготовка требований по функционалу, постановка задач в бэклог, определение приоритетности выполнения и так далее.
Проектный менеджер или PM (Project Manager) — это управляющий проекта, а не продукта, в отличии от РО. Он координирует действия команды, следит за сроками и контролирует выполнение проекта. РМ дает РО данные о проекте, а РО ему о продукте.
Тимлид — это руководитель команды разработчиков. Его задача в организации работы и контроле за происходящим. Так как он курирует процесс разработки, принимает ключевые решения и помогает подчиненным, то ему нужно понимать во всем. В его компетенции входит как фронт, так и бэк.
Фронтенд разработчик или фронтендер (frontend developer) — это тот, кто наводит красоту и делает нашу с вами жизнь лучше. Он отвечает за части сайта или приложения, с которыми взаимодействует пользователь. Фронтендер берет за основу работу дизайнера и превращает ее в визуальную часть сайта. Правильность отображения кнопок, текста, картинок и других элементов — ответственность фронтенд разработчика.
Бэкенд разработчик или бэкендер (backend developer) — это боец невидимого фронта, работающий над внутренней частью сайта или приложения. Он обеспечивает правильное выполнение команд от пользователя. Если фронт отвечает за правильное подсвечивание и отображение кнопки, то бэк за действие, которое произойдет при нажатии.
UI/UX дизайнер — это создатель плана сайта или приложения с точки зрения визуального наполнения. Дизайнер продумывает логику взаимодействия пользователя с продуктом, размещает контент и после передает свое творение разработчикам.
QA-инженер или тестировщик — это ответственный за проверку работы. Он ищет всевозможные ошибки и сообщает о них. Так как проблемы могут касаться разных частей сайта или приложения, то взаимодействует тестировщик практически со всей командой. Он даже может предложить новое решение для улучшения клиентского опыта или повышения продаж.
DevOps-инженер — это тот, кто упрощает взаимодействие между разработчиками, тестировщиками и менеджерами, ускоряет разработку за счет автоматизации части процессов. Девопс также отвечает за работу сервера и должен гарантировать непрерывность работы. Задача у него непростая, поэтому для понимания сути его работы желательно иметь базовые знания в программировании.
Этот список профессий далеко не исчерпывающий и может включать себя и других сотрудников, но мы остановимся на наиболее популярных и известных, ведь именно с ними проще всего столкнуться в реальной жизни.
Цикл разработки: кто, что и когда делает
Первое знакомство с командой прошло успешно, так что самое время посмотреть на ее жизнь в естественной среде.
Не вникая в процесс разработки, может показаться, что создание ПО происходит по единому скрипту. Однако все не так просто — методологий и принципов разработки существует достаточно много. Чтобы не углубляться в эти нюансы, мы пройдемся по верхам, сформируем общее понимание этапов разработки ПО и расскажем, кто и когда вступает в игру.
Подготовка и планирование
Владелец продукта:
собирает данные о клиентах, рынке и конкурентах;
получает информацию от заказчика;
готовит список целей и определяет задачи;
согласует план проекта с РМ.
Проектный менеджер:
систематизирует собранные данные;
фиксирует задачи и требования от РО и совместно с РО расставляет приоритеты;
согласовывает техническое задание;
готовит план проекта.
Тимлид:
консультирует РО и РМ по технической части;
определяет, что можно реализовать, а что нет;
участвует в формировании задач с точки зрения технической реализации;
определяет технологии и инструменты;
оценивает необходимые ресурсы и время для выполнения поставленных задач;
проверяет и утверждает техническое задание.
Проектирование
Тимлид:
определяет основу архитектуры;
консультирует других участников команды;
принимает ключевые решения по части разработки.
UI/UX дизайнер:
формирует прототип сайта;
готовит основные части;
наращивает дополнительные по мере внесения правок;
финализирует дизайн интерфейса.
Проектный менеджер:
следит за выполнением работ командой и соответствием установленным требованиям.
Разработчики:
помогают дизайнеру с подготовкой прототипа;
вносят правки с точки зрения возможности реализации прототипа.
Разработка
Фронтенд разработчик:
создает внешние части сайта по прототипу от дизайнера.
Бэкенд разработчик:
создает внутреннюю (серверную) часть сайта и работает с базами данных (БД).
Тимлид:
координирует работу разработчиков и помогает со сложными задачами.
DevOps-инженер:
работает над автоматизацией части процессов разработки и обеспечением ее непрерывности.
Тестирование
QA-инженер:
ищет ошибки и передает данные о них разработчикам.
Разработчики:
воспроизводят найденные тестировщиком баги;
исправляют ошибки.
Тимлид:
координирует работу разработчиков и тестировщиков;
помогает со сложными проблемами.
Развертывание
DevOps-инженер:
развертывает приложения на сервере — вывод ПО на сервер с локального хранения (без этого пользователи не смогут взаимодействовать с ПО);
настраивает инфраструктуру — подготовка к началу работы серверов и других технических компонентов;
управляет CI/CD процессами — обеспечение непрерывного процесса разработки, тестирования и развертывания.
Бэкенд разработчик:
принимает участие в настройке серверной части и настройке взаимодействия с базами данных.
Проектный менеджер:
контролирует работу команды и следит за процессами.
Тимлид:
следит за развертыванием, обеспечивает его корректность и помогает другим членам команды.
Поддержка и обновление
Разработчики:
исправляют баги;
разрабатывают и внедряют новые функции.
QA-инженер:
ищет ошибки и передает их разработчикам.
Тимлид:
помогает в решении сложных проблем, которые не удалось разрешить на уровне разработчиков и тестировщиков.
Владелец продукта:
дает обратную связь от заказчика и пользователей;
формирует задачи по новому функционалу;
определяет приоритетность задач.
Проектный менеджер:
организует работы по поддержке и обновлению ПО командой.
Документация
Тимлид:
создает и обновляет техническую документацию кода с описанием технологий, инструментов и библиотек.
Разработчики:
комментируют код и обновляют данные при изменениях.
Проектный менеджер:
следит за актуальностью документации и своевременным обновлением.
Владелец продукта:
готовит документацию для пользователей.
Кому и когда писать
Если в вашем проекте вы не состоите в команде разработки, но вам нужно коммуницировать с ней, то вы можете воспользоваться нашей шпаргалкой с темами и примерами вопросов, которые можно задать.
Тимлид
По техническим возможностям и ограничениям.
«Какие новые функции будут реализованы в будущем?»
«Какие метрики используются для оценки стабильности работы ПО?»
«Есть ли ограничения, которые нужно учитывать при планировании нового функционала?»
Владелец продукта
По функциям, приоритетам задач, дорожной карте и обратной связи от пользователей.
«Можно ли добавить функцию N?»
«Какие функции будут запущены в следующем квартале?»
«Когда будет реализована функция N»?
«Какой план развития у проекта?»
«Развитие каких функций сейчас в приоритете?»
Проектный менеджер
По срокам, графикам, обновлениям, статусам, координации задач и сотрудников.
«Какой сейчас график релизов?»
«Есть ли сейчас задержки по задачам и будет ли реализован новый функционал в срок?»
«Какой сейчас статус у разработки?»
Фронтенд разработчик
По изменениям визуала и интерактивных элементов.
«Можем ли мы поменять фото на главной на анимацию?»
«Как лучше реализовать всплывающие окна?»
«Насколько сложно будет поменять дизайн на сайте?»
«Сильно ли скажется на скорости загрузки внедрение новых анимированных блоков?»
Бэкенд разработчик
По новому функционалу и получению данных.
«Можем ли мы подключить новую аналитику?»
«Можно ли настроить выгрузку определенных данных о действиях пользователей?»
«Как долго будет устраняться баг?»
UI/UX дизайнер
По дизайну, брендингу и улучшению пользовательского опыта.
«Нужно ли нам адаптировать дизайн страницы для повышения конверсий?»
«Как нам оформить новые функции для выделения их среди старых?»
«Мы хотим добавить новый блок, будет ли он удобен для пользователей или нужно подкорректировать?»
QA-инженер
По тестированию новых функций, ошибкам, стабильности и качеству работы ПО.
«У нас запланирована рекламная кампания на следующей неделе, есть ли баги, которые еще не исправлены?»
«Есть ли ошибки, о которых нужно знать?»
«Сколько времени уйдет на тестирование новой версии сайта?»
DevOps-инженер
По стабильности работы сервера, мониторингу производительности системы.
«Выдержит ли сайт повышенную нагрузку при проведении маркетинговой кампании?»
«Можем ли мы настроить мониторинг для отслеживания производительности системы?»
«Что нужно сделать для повышения устойчивости к нагрузке при наплыве пользователей?»
Как понять IT-шника
Если вы раньше не общались с представителями IT-сообщества в разрезе работы, то в ходе беседы можете почувствовать себя иностранцем. IT-сфера наполнена собственной терминологией, которую сложно понять без надлежащего опыта. Для вас мы собрали краткий список с популярными словами, которые помогут не потерять нить разговора и стать своим хотя бы на базовом уровне.
Прод — рабочая версия продукта.
Релиз (залить на прод) — выпустить рабочую версию продукта.
Стейдж — среда для тестирования, которая полностью копирует прод.
Баг-репорт — отчет об ошибке.
Проджект — менеджер проекта.
Мок — имитация реального объекта при проведении тестирования.
Спека/дока — документ с техническими требованиями для разработки и тестирования.
Ассайнить — поручить задачу.
Аттач — файл, который прилагается к сообщению.
Грумить — приводить в порядок.
Деплой (развертывание) — совокупность действий, которые делают ПО готовым к использованию на сервере.
Коммит, коммитить — фиксация изменений кода в системе контроля версии (git).
Комплитить — завершить задачу.
Мерджить — объединять изменения от разных программистов в одном проекте.
Патч — временное дополнение к коду.
Пушить — загрузить код в git.
Ребут — перезагрузка.
Темплейт — шаблон.
Фича — функция.
Футер, подвал — элемент сайта в его нижней части.
Хедер — элемент сайта в верхней части.
Бэклог — список задач, которые нужно сделать в будущем.
Спринт — интервал времени, за который нужно выполнить определенный список задач.
Сторя — корневая задача.
Таск, таска — задача.
Апрув, апрувить — согласовать.
Пинговать — напоминать.
Сможете найти на картинке цифру среди букв?
Справились? Тогда попробуйте пройти нашу новую игру на внимательность. Приз — награда в профиль на Пикабу: https://pikabu.ru/link/-oD8sjtmAi
Даже гуру ошибаются: истории великих фейлов в ML
Все мы знаем, что учиться на ошибках — это часть процесса, и даже самые именитые эксперты в области ML не застрахованы от промахов.
Именно так Эндрю Ын, один из основателей Coursera и гуру deep learning, в начале своей карьеры столкнулся с проблемой, когда тестовые данные случайно включились в тренировочный набор. Модель выдавала потрясающие результаты, но на новых данных показывала себя просто отвратительно. Это заставило Эндрю внедрить более строгие методы валидации и часто напоминать себе и своим коллегам о важности корректного разбиения данных.
И он не одинок в своих проблемах. Джеффри Хинтон, легенда в мире DL, однажды создал слишком сложную архитектуру нейросети для простой задачи. Модель переобучилась и показала плохие результаты на тесте, что заставило его пересмотреть подход к выбору архитектуры. Хинтон осознал, что баланс между сложностью модели и задачей — ключ к успеху.
Следом за Хинтоном, Ян ЛеКун столкнулся с проблемой исчезающих градиентов в глубоких сетях. Эта проблема затрудняла обучение и приводила к неэффективности. Разработав методы использования ReLU активаций, ЛеКун решил эту проблему и понял важность выбора правильных функций активации.
Илон Маск, продвигая технологии автономного вождения в Tesla, тоже столкнулся с ошибками. Система распознавания объектов неправильно классифицировала дорожные знаки и пешеходов, что привело к инцидентам. Это заставило Tesla улучшить алгоритмы и добавить дополнительные уровни валидации, показывая, что тщательная проверка в реальных условиях необходима.
Заключает наш список Джефф Дин из Google, который работал над масштабируемостью ML-систем. В одном из проектов команда столкнулась с проблемами обработки big data, что привело к созданию новых распределенных систем, таких как MapReduce и TensorFlow. Так Дин понял, что для успешного внедрения ML необходимы масштабируемые системы.
Вот так вот. Даже гуру не застрахованы от промахов, но именно через них они и становятся гуру.