NoCode Wiki - Вклад [ru]

Публикация контейнера из реестра GitLab в Dockhost

2024-12-07T13:37:04Z

SergeySkripov: /* Полезные ссылки */

Для публикации образа контейнера из непубличного репозитория GitLab нужно выполнить следующие действия.

==== В GitLab ====
# Зайти в репозитории GitlLab в раздел Settings -> Access Tokens
# Нажимаем "Add new token" и создаем токен с правом read_registry и правами Developer. Также нужно указать дату окончания действия токена (по умолчанию стоит 1 месяц). После этой даты токен станет не активным и будет невозможно загрузить образ из репозитория.
# После создания токен нужно сохранить, т.к. он отображается только в момент создания и посмотреть его больше будет нельзя, только создать новый.
# Зайти в Deploy -> Container Registry и убедится в наличии собранного контейнера и напротив названия тега нажать на кнопку "скопировать", для копирования пути к образу.

==== В DockHost ====
# В разделе "Реестры образов" добавить реестр из вашего репозитория, обычно он выглядит так: ''<nowiki>https://registry.gitlab.com/путь_к_репозиторию</nowiki>'' (Например: ''<nowiki>https://registry.gitlab.com/skripov.com/reverse-proxy</nowiki>'').
# Выбрать реестр GitLab, указать путь к реестру, в поле "Пользователь" указать ваш логин на GitLab, в поле "Пароль" указать токен полученный на предыдущем шаге.
# В разделе "Контейнеры" добавить новый контейнер - в поле "Образ" указать путь к образу который был скопирован в GitLab (Он выглядит примерно так: registry.gitlab.com/skripov.com/reverse-proxy:main)
# При создании контейнера указать необходимые для работы порт на котором работает приложение (для веб приложений обычно используется 80)
# Войти в управление контейнером и в разделе "Логи" убедится, что контейнер успешно запустился.
# В разделе "Сетевые сервисы - Домены" добавить новый домен
# В разделе "Сетевые сервисы - Маршруты" добавить маршрут для созданного домена, который будет переадресовывать все запросы на созданный контейнер. Также нужно указать порт, который используется контейнером.

==== Тестирование ====
Теперь можно ввести в браузере адрес привязанного домена и увидеть ответ от запущенного контейнера. В логах контейнера можно проверить успешность выполнения запроса.

==== Полезные ссылки ====
* https://docs.dockhost.ru/ - документация на DockHost
* https://gitlab.com/skripov.com/reverse-proxy/ - пример конфигурации Nginx для настройки его как reverse proxy
[[Категория:DevOps]]

Заглавная страница

2024-12-07T13:35:25Z

SergeySkripov: /* Новые статьи */

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

Обсудить работу проекта можно в телеграм чате: https://t.me/skripov_nocode

Хотите стать автором? Напишите об этом в чате и вам будет создана учетная запись на проекте.

==== Новые статьи ====

* [[Публикация контейнера из реестра GitLab в Dockhost]] - инструкция как просто опубликовать свое приложение на сервисе [[Dockhost]]
* [[Обратный прокси (Reverse proxy)]] - что это такое и зачем нужно.
* [[База данных]] - описание различных СУБД и для чего их можно использовать.
* [[Верификация пользователя в Telegram_MiniApps]] - инструкция как проверить данные пользователя в MiniApps.
* [[Telegram Mini Apps на FlutterFlow]] - инструкция как получить данные пользователя Телеграм в MiniApps
* [[Участник:SergeySkripov/Можно ли сделать сложное корпоративное приложение без программистов|Можно ли сделать сложное корпоративное приложение без программистов?]]

[[Служебная:Новые страницы|Все новые статьи]]

==== Статьи по категориям ====

* [[:Категория:Appmaster|Appmaster]]
* [[:Категория:FlutterFlow|FlutterFlow]]
* [[:Категория:DevOps|DevOps]]

Публикация контейнера из реестра GitLab в DockHost

2024-12-07T13:33:37Z

SergeySkripov: SergeySkripov переименовал страницу Публикация контейнера из реестра GitLab в DockHost в Публикация контейнера из реестра GitLab в Dockhost: Название с ошибкой

#перенаправление [[Публикация контейнера из реестра GitLab в Dockhost]]

Публикация контейнера из реестра GitLab в Dockhost

2024-12-07T13:33:37Z

Проект:Отказ от ответственности

2024-12-07T13:28:19Z

SergeySkripov: Новая страница: «Чтобы Вы не нашли на этом сайте и как то это использовали полностью на Вашей ответственности.»

Чтобы Вы не нашли на этом сайте и как то это использовали полностью на Вашей ответственности.

Проект:Политика конфиденциальности

2024-12-07T13:25:45Z

SergeySkripov: Новая страница: «Все данные посетителей собирают внешние счетчики, встраиваемые элементы такие как видеоролики, картинки и т.п. Что они дальше с ними делают известно только им. Все запросы к серверу энциклопедии обрабатываются хостинг провайдером и CDN с...»

Все данные посетителей собирают внешние счетчики, встраиваемые элементы такие как видеоролики, картинки и т.п. Что они дальше с ними делают известно только им. Все запросы к серверу энциклопедии обрабатываются хостинг провайдером и [[Content Delivery Network|CDN]] сервисом [[Cloudflare]], а он вообще всё про всех знает т.к. его используют почти 20% сайтов.

Проект:Описание

2024-12-07T13:08:30Z

SergeySkripov: Новая страница: «Энциклопедия NoCode Wiki создана для того, чтобы донести сложные знания простым языком для начинающих разработчиков или людей которые хотят сделать с использованием NoCode решений приложение для себя. Здесь мы собираем всю полезную информацию о разработке н...»

Энциклопедия NoCode Wiki создана для того, чтобы донести сложные знания простым языком для начинающих разработчиков или людей которые хотят сделать с использованием NoCode решений приложение для себя.

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

Обсудить работу проекта можно в телеграм чате - https://t.me/skripov_nocode

Хотите стать автором? Напишите об этом в чате и вам будет создана учетная запись на проекте. Создавать и редактировать любые статьи может любой пользователь.

Подпишитесь на канал https://t.me/skripov_channel чтобы быть в курсе новых обновлений.

Категория:DevOps

2024-12-07T12:47:27Z

SergeySkripov: Новая страница: «В этом разделе находятся статьи связанные с DevOps»

В этом разделе находятся статьи связанные с [[DevOps]]

Публикация контейнера из реестра GitLab в Dockhost

2024-12-07T12:46:16Z

SergeySkripov:

Обратный прокси (Reverse proxy)

2024-12-07T12:45:51Z

SergeySkripov:

'''Обратный прокси (reverse proxy)''' - это сервер который ретранслирует запросы пользователя к конкретному серверу в отличии от обычного прокси, который ретранслирует запросы к любому серверу от пользователя.

== Примеры использования ==
'''[[Content Delivery Network|CDN]]''' - вы размещаете по всему миру reverse proxy, которые перенаправляют запросы к вашему основному серверу и заодно кешируют картинки, тяжелые файлы или запросы к вашему серверу. За счет этого снижается нагрузка на ваш основной сервер, а для клиентов повышается скорость загрузки файлов т.к. они будут загружаться с ближайшего сервера.

'''[[Балансировщик нагрузки (Load balancer)|Балансировщик нагрузки]]''' - если у вас используется несколько серверов приложений то reverse proxy может распределять запросы между ними, а также ограничивать количество запросов от одного клиента или по другим правилам, чтобы избежать перегрузки бэкенда.

'''[[API шлюз (API Gateway)]]''' - если у вас бэкенд на микросервисной архитектуре или части бэкенда расположены на других серверах (например статика - картинки, файлы и т.п.) то можно разделять запросы в зависимости от пути по которому обращается клиент и перенаправлять их на соответствующий сервер.

'''Для разработки''' или других сложных вариантов, таких как обход региональных ограничений. Так например можно запустить reverse proxy в нужной стране и через него делать запросы к целевому API из своего приложения.

== Приложения которые можно использовать как reverse proxy ==
* [[Nginx]]
* [[HAProxy]]
* [[Traefik]]
* [[Envoy]]
* [[Caddy]]
* [[Kong]]

== Полезные ссылки ==
* https://gitlab.com/skripov.com/reverse-proxy/ - пример конфигурации Nginx для настройки его как reverse proxy
* [[Публикация контейнера из реестра GitLab в DockHost]]
[[Категория:DevOps]]

Обратный прокси (Reverse proxy)

2024-12-07T12:35:07Z

SergeySkripov: Новая страница: «'''Обратный прокси (reverse proxy)''' - это сервер который ретранслирует запросы от конкретного сервера в отличии от обычного прокси, который ретранслирует запросы от любого сервера к пользователю. == Примеры использования == '''CDN''' - вы размещаете...»

'''Обратный прокси (reverse proxy)''' - это сервер который ретранслирует запросы от конкретного сервера в отличии от обычного прокси, который ретранслирует запросы от любого сервера к пользователю.

== Примеры использования ==
'''[[Content Delivery Network|CDN]]''' - вы размещаете по всему миру reverse proxy, которые перенаправляют запросы к вашему основному серверу и заодно кешируют картинки, тяжелые файлы или запросы к вашему серверу. За счет этого снижается нагрузка на ваш основной сервер, а для клиентов повышается скорость загрузки файлов т.к. они будут загружаться с ближайшего сервера.

'''[[Балансировщик нагрузки (Load balancer)|Балансировщик нагрузки]]''' - если у вас используется несколько серверов приложений то reverse proxy может распределять запросы между ними, а также ограничивать количество запросов от одного клиента или по другим правилам, чтобы избежать перегрузки бэкенда.

'''[[API шлюз (API Gateway)]]''' - если у вас бэкенд на микросервисной архитектуре или части бэкенда расположены на других серверах (например статика - картинки, файлы и т.п.) то можно разделять запросы в зависимости от пути по которому обращается клиент и перенаправлять их на соответствующий сервер.

'''Для разработки''' или других сложных вариантов, таких как обход региональных ограничений. Так например можно запустить reverse proxy в нужной стране и через него делать запросы к целевому API из своего приложения.

== Приложения которые можно использовать как reverse proxy ==
* [[Nginx]]
* [[HAProxy]]
* [[Traefik]]
* [[Envoy]]
* [[Caddy]]
* [[Kong]]

== Полезные ссылки ==
* https://gitlab.com/skripov.com/reverse-proxy/ - пример конфигурации Nginx для настройки его как reverse proxy
* [[Публикация контейнера из реестра GitLab в DockHost]]

Публикация контейнера из реестра GitLab в Dockhost

2024-12-06T16:52:20Z

SergeySkripov: Новая страница: «Для публикации образа контейнера из непубличного репозитория GitLab нужно выполнить следующие действия. ==== В GitLab ==== # Зайти в репозитории GitlLab в раздел Settings -> Access Tokens # Нажимаем "Add new token" и создаем токен с правом read_registry и правами Developer. Также нужно указать д...»

База данных

2024-10-30T11:22:32Z

SergeySkripov:

Обычно базой данных называют какую либо СУБД (Систему Управления Базами Данных).

Основное предназначение СУБД это хранение данных, добавление, изменение и поиск. В большинстве случаев пользователь никогда не подключается напрямую к СУБД, а использует для этого промежуточный сервер ([[бэкенд]]), который отвечает за контроль доступа к данным и преобразование их в нужный формат.

Преимущество СУБД перед обычным хранением данных в файлах в том, что они обладают механизмом "индексирования", что позволяет им быстрее находить нужные записи и не использовать полный перебор всех хранимых записей.

СУБД делят на несколько типов исходя из того как они работают.

==== Реляционные (SQL) СУБД ====
Один из самых старых и популярных типов СУБД. Позволяют выполнять запросы сразу по нескольким таблицам с множеством условий. В таких СУБД данные связываются между собой по идентификатору записи. Для работы с данными необходимо предварительно создать структуру таблиц и каждому полю в таблице задать свой тип. Т.е. если при создании таблицы было создано поле типа "число", то записать в него "строку" уже не получится, а менять тип столбца не всегда возможно т.к. могут быть потеряны данные, которые не смогут сконвертироваться в новый тип.

Например для указания адреса может быть использована такая структура таблиц:

Страна - содержит название страны и уникальный ключ записи (id)

Город - список городов, у каждой записи есть отдельная колонка в которой сохраняется id страны, вместо указания ее полного названия.

Улица - список улиц, у каждой записи аналогично есть отдельная колонка с id города.

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

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

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

'''MariaDB (бывшая MySQL)''' - используется в основном в веб проектах т.к. достаточно простая в обслуживании.

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

'''MS SQL/Oracle Database''' - СУБД корпоративного класса, используются только крупными компаниями.

'''SQLite''' - встраиваемая СУБД, не используется в клиент-серверной архитектуре и используется для хранения и обработки данных у пользователя, например в браузере или мобильном приложении. Для работы СУБД не требуется отдельного приложения т.к. вся БД находится в одном файле на устройстве пользователя.

==== Документоориентированные (NoSQL) СУБД ====
В таких БД нет четкой структуры хранения, а сами записи хранятся как документы ([[JSON]]) и могут быть вложены друг в друга.

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

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

'''MongoDB''' - одна из самых популярных NoSQL СУБД, ее используют GitHub, Foursqaure, CNN и др. Достаточно простая в обслуживании и масштабировании.

У MongoDB есть дополнительный особенный тип коллекций - Time-Series, который оптимизирован для хранения событий - показаний счетчиков, истории цен и т.п. записей в которых всегда присутствует дата события. Такие коллекции позволяют выполнять быстрые запросы использующие расчеты (сумма, количество, среднее значение и т.п.) и диапазоны времени.

'''Elasticsearch''' - обычно используется как временное хранилище предварительно обработанных данных, отличается высокой скоростью работы за счет хранения данных в оперативной памяти сервера и позволяет делать сложные запросы. Полезно использовать как промежуточную БД между реляционной СУБД и пользователем если используются очень сложные или частые одинаковые запросы.

'''[[Cloud Firestore]]''' - особенностью этой СУБД является возможность напрямую подключать пользователя к БД, т.к. она обладает встроенным механизмом разграничения доступа к документам. Применяется в простых мобильных приложениях, когда нужно хранить пользовательские данные - заметки, чаты, задачи, игровые данные и т.п., а также если отсутствует необходимость в полноценном бэкенде.

Нельзя установить на своем сервере т.к. является частью [[BaaS]] платформы [[Firebase]].

'''Google Cloud Datastore''' - СУБД которая позволяет создавать неограниченные по размеру БД при этом сохраняя стабильное время ответа на запросы. Является частью [[IaaS]] платформы [[Google Cloud]] и не доступна для установки на собственный сервер.

'''Redis''' - хранит данные в виде пар ключ-значение, позволяет получать сразу несколько записей по совпадающей части ключа. Используется как кеширующая БД т.к. работает очень быстро за счет хранения всех данных в оперативной памяти сервера. Не используется как основная БД для хранения данных. Используется в высоконагруженных проектах, для того чтобы снять нагрузку с основной БД или ускорить время ответа для частых одинаковых запросов (курс валюты, погода и т.п.).

Заглавная страница

2024-10-30T11:00:19Z

SergeySkripov: /* Новые статьи */

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

Обсудить работу проекта можно в телеграм чате: https://t.me/skripov_nocode

Хотите стать автором? Напишите об этом в чате и вам будет создана учетная запись на проекте.

==== Новые статьи ====

* [[База данных]] - описание различных СУБД и для чего их можно использовать.
* [[Верификация пользователя в Telegram_MiniApps]] - инструкция как проверить данные пользователя в MiniApps.
* [[Telegram Mini Apps на FlutterFlow]] - инструкция как получить данные пользователя Телеграм в MiniApps
* [[Участник:SergeySkripov/Можно ли сделать сложное корпоративное приложение без программистов|Можно ли сделать сложное корпоративное приложение без программистов?]]

[[Служебная:Новые страницы|Все новые статьи]]

==== Статьи по категориям ====

* [[:Категория:Appmaster|Appmaster]]
* [[:Категория:FlutterFlow|FlutterFlow]]

База данных

2024-10-30T10:30:27Z

SergeySkripov: Новая страница: «Обычно базой данных называют какую либо СУБД (Систему Управления Базами Данных). Основное предназначение СУБД это хранение данных, добавление, изменение и поиск. В большинстве случаев пользователь никогда не подключается напрямую к СУБД, а использует...»

Обычно базой данных называют какую либо СУБД (Систему Управления Базами Данных).

Основное предназначение СУБД это хранение данных, добавление, изменение и поиск. В большинстве случаев пользователь никогда не подключается напрямую к СУБД, а использует для этого промежуточный сервер ([[бэкенд]]), который отвечает за контроль доступа к данным и преобразование их в нужный формат.

Преимущество СУБД перед обычным хранением данных в файлах в том, что они обладают механизмом "индексирования", что позволяет им быстрее находить нужные записи и не использовать полный перебор всех хранимых записей.

СУБД делят на несколько типов исходя из того как они работают.

==== Реляционные (SQL) СУБД ====
Один из самых старых и популярных типов СУБД. Позволяют выполнять запросы сразу по нескольким таблицам с множеством условий. В таких СУБД данные связываются между собой по идентификатору записи. Для работы с данными необходимо предварительно создать структуру таблиц и каждому полю в таблице задать свой тип. Т.е. если при создании таблицы было создано поле типа "число", то записать в него "строку" уже не получится, а менять тип столбца не всегда возможно т.к. могут быть потеряны данные, которые не смогут сконвертироваться в новый тип.

Например для указания адреса может быть использована такая структура таблиц:

Страна - содержит название страны и уникальный ключ записи (id)

Город - список городов, у каждой записи есть отдельная колонка в которой сохраняется id страны, вместо указания ее полного названия.

Улица - список улиц, у каждой записи аналогично есть отдельная колонка с id города.

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

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

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

'''MariaDB (бывшая MySQL)''' - используется в основном в веб проектах т.к. достаточно простая в обслуживании.

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

'''MS SQL/Oracle Database''' - СУБД корпоративного класса, используются только крупными компаниями.

'''SQLite''' - встраиваемая СУБД, не используется в клиент-серверной архитектуре и используется для хранения и обработки данных у пользователя, например в браузере или мобильном приложении. Для работы СУБД не требуется отдельного приложения т.к. вся БД находится в одном файле на устройстве пользователя.

==== Документоориентированные (NoSQL) СУБД ====
В таких БД нет четкой структуры хранения, а сами записи хранятся как документы (JSON) и могут быть вложены друг в друга.

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

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

'''MongoDB''' - одна из самых популярных NoSQL СУБД, ее используют GitHub, Foursqaure, CNN и др. Достаточно простая в обслуживании и масштабировании.

У MongoDB есть дополнительный особенный тип коллекций - Time-Series, который оптимизирован для хранения событий - показаний счетчиков, истории цен и т.п. записей в которых всегда присутствует дата события. Такие коллекции позволяют выполнять быстрые запросы использующие расчеты (сумма, количество, среднее значение и т.п.) и диапазоны времени.

'''Elasticsearch''' - обычно используется как временное хранилище предварительно обработанных данных, отличается высокой скоростью работы за счет хранения данных в оперативной памяти сервера и позволяет делать сложные запросы. Полезно использовать как промежуточную БД между реляционной СУБД и пользователем если используются очень сложные или частые одинаковые запросы.

'''[[Cloud Firestore]]''' - особенностью этой СУБД является возможность напрямую подключать пользователя к БД, т.к. она обладает встроенным механизмом разграничения доступа к документам. Применяется в простых мобильных приложениях, когда нужно хранить пользовательские данные - заметки, чаты, задачи, игровые данные и т.п., а также если отсутствует необходимость в полноценном бэкенде.

Нельзя установить на своем сервере т.к. является частью BaaS платформы Firebase.

'''Google Cloud Datastore''' - СУБД которая позволяет создавать неограниченные по размеру БД при этом сохраняя стабильное время ответа на запросы. Является частью IaaS платформы Google Cloud и не доступна для установки на собственный сервер.

'''Redis''' - хранит данные в виде пар ключ-значение, позволяет получать сразу несколько записей по совпадающей части ключа. Используется как кеширующая БД т.к. работает очень быстро за счет хранения всех данных в оперативной памяти сервера. Не используется как основная БД для хранения данных. Используется в высоконагруженных проектах, для того чтобы снять нагрузку с основной БД или ускорить время ответа для частых одинаковых запросов (курс валюты, погода и т.п.).

Заглавная страница

2024-10-19T09:44:21Z

SergeySkripov:

Участник:SergeySkripov

2024-10-18T17:48:00Z

SergeySkripov:

==== Мои статьи ====

* [[Участник:SergeySkripov/Можно ли сделать сложное корпоративное приложение без программистов|Можно_ли_сделать_сложное_корпоративное_приложение_без_программистов]]

==== Полезные ссылки для управления MediaWiki ====

* [[MediaWiki:Sidebar]]

Участник:SergeySkripov/Можно ли сделать сложное корпоративное приложение без программистов

2024-10-18T17:45:26Z

SergeySkripov: Новая страница: «Я занимаюсь разработкой с использование ноукод инструментов с 1998 года. Да, уже в то время появился MS Access, который позволял сделать небольшую учетную систему с многопользовательским доступом. В начале 2000х годов приложение на MS Access работало в десятке м...»

Я занимаюсь разработкой с использование ноукод инструментов с 1998 года. Да, уже в то время появился [[MS Access]], который позволял сделать небольшую учетную систему с многопользовательским доступом. В начале 2000х годов приложение на MS Access работало в десятке магазинов крупной торговой сети бытовой техники и электроники (более 50тыс. SKU), оно обеспечивало учет остатков, учет продаж, контроль за ценами и обмен данными с другими магазинами сети для отображения остатков. В целом это не плохой инструмент для того, чтобы быстро и без программирования сделать свою базу данных для учета чего угодно на предприятии, но с одной проблемой, он доступен пользователям только в локальной сети организации.

В последние годы стало появляться очень много [[ноукод]] инструментов и даже появилась целая индустрия ноукод разработки, но к сожалению большинство инструментов это костыли для решения какой-то одной задачи или просто ориентированы на простые веб/мобильные приложения без сложной логики.

Зачем вообще нужен [[ноукод]]?

Ноукод разработка позволяет в короткие сроки сделать сложное приложение для управления бизнес процессами внутри компании или взаимодействия с клиентами, а также снизить стоимость поддержки. Проще говоря можно за месяц сделать свою [[CRM]] под свои бизнес процессы, а не перестраивать их под готовую систему.

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

На сколько сложное приложение можно сделать?

Carment - финтех сервис созданный в партнерстве с Visa (https://www.businesswire.com/news/home/20231107564749/en/Whillet-Collaborates-with-Visa-to-Introduce-Carment-A-Next-Level-Instant-Payment-Platform-for-the-U.S.-Used-Car-Market) на ноукод платформе [[AppMaster]]. Были сделаны интеграции с несколькими банками и KYC/KYB провайдерами. Все это сделано полностью без единой строчки кода со стороны бэкенда (фронтенд классическое приложение на [[VueJS]]). На разработку бэкенда, настройку [[CI/CD]] и публикацию на своих серверах в облаке [[Google]] ушло чуть больше 300 часов.

Учетная система для аутстаф компании - учет нанятых работников, все данные по ним включая данные по легализации, учет работающих на проектах, используемое жилье, корпоративный автотранспорт, учет отработанных часов и т.п. На разработку [[Бэкенд|бэкенда]] и [[Фронтенд|фронтенда]] ушло около 200 часов. Проект полностью сделан на платформе AppMaster.

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

Для кого будет полезна разработка приложения на ноукоде?

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

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

Для компаний работающих с клиентами - личные кабинеты клиентов, запись и заказ услуг или товаров, отображение статусов работ и т.п.

Для стартапов - можно за 1-2 месяца сделать сложное приложение и протестировать гипотезу не уходя в классическую разработку на год.

Какой ноукод инструмент выбрать?

На рынке профессиональной ноукод разработки есть несколько крупных решений на которых можно сделать сложное приложение.

[[Mendix]] - создан в 2005 году, в 2018 приобретен компанией Siemens за $730млн. Фактически это [[LowCode]] решение т.к. часть логики можно/нужно писать кодом. Тарификация осуществляется за каждого пользователя системы.

[[Xano]] - позволяет сделать сложный [[бэкенд]] к которому потом по [[API]] можно подключить [[фронтенд]] или [[мобильное приложение]] (например с использование [[FlutterFlow]]).

[[Directual]] - также разработка бэкенда и несложного веб приложения.

[[AppMaster]] - единственное решение на рынке на котором можно сделать бэк, фронт и мобильное приложение (с автоматической публикацией в маркетах).

Почему я использую AppMaster для разработки.

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

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

Вторая важная причина - бэкенд работает с СУБД [[PostgreSQL]] и можно использовать весь функционал [[SQL]] запросов - JOIN, вычисляемы поля, оконные функции и т.п.

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

Четвертое - мобильные приложения которые не нужно обновлять в сторах. Суть в том, что при каждом запуске мобильного приложения всегда загружается самая свежая конфигурация приложения (экраны и логика). Т.е. достаточно один раз установить приложение на устройства сотрудников и все дальнейшие изменения будут применяться при каждом запуске. Не надо заново проходить модерацию в сторах и т.п. Естественно при таком решении приходится немного пожертвовать дизайном приложения, но для корпоративных задач этого более чем достаточно.
[[Категория:Статья]]
[[Категория:Appmaster]]

Appmaster Авторизация и аутентификация

2024-10-18T17:33:21Z

SergeySkripov: Новая страница: «Для того, чтобы пользователи приложения получали данные которые предназначаются только для них и не могли получить доступ к чужим данным и тем более изменить их нужно удостоверится, что пользователь, который прислал запрос не выдает себя за другого. ''...»

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

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

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

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

В чем смысл - логин и пароль имеют не ограниченный срок жизни и если пользователь будет при каждом запросе передавать свой логин и пароль, то увеличиваются шансы на их перехват или утечку. И если кто-то получит к ним доступ, то сможет бесконечно долго ими пользоваться. Вместо этого в БД записывается "сессия" пользователя с уникальным кодом "токеном", который может быть отозван в любое время и имеет ограниченный срок жизни. Также в сессию можно записать любые дополнительные данные такие как браузер, ip адрес, приложение через которое пользователь зашел или любые другие которые могут быть полезны для работы.

Пример работы таких "сессий" можно увидеть в мессенджерах, соцсетях или банковских приложениях - они показывают с какого устройства кто и когда заходил и позволяют прервать это соединение.
[[Файл:Appmaster Auth UserSession.png|центр|безрамки|1000x1000пкс]]

В AppMaster есть готовые БП которые помогают зарегистрировать пользователя и аутентифицировать.

'''Регистрация'''

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

На выходе БП мы получаем профиль зарегистрированного пользователя (User) и токен сессии который нужно сохранить на клиентской стороне и использовать для дальнейших запросов.
[[Файл:Appmaster BP User Sign-up.png|центр|безрамки|1000x1000пкс]]

'''Аутентификация'''

Очень похожа на регистрацию выше, но не создает нового пользователя, а проверяет есть ли существующий с таким логином и паролем и если есть то возвращает профиль (User) и токен сессии.
[[Файл:Appmaster BP User Sign In.png|центр|безрамки|1000x1000пкс]]

'''Выход'''

Когда пользователь заканчивает работу в приложении или хочет войти под другим пользователем он должен прервать текущую сессию. Для это также есть отдельный БП. Он проверяет, какой пользователь вызвал этот БП, получает текущую сессию и завершает ее.
[[Файл:Appmaster BP User Logout.png|центр|безрамки|1000x1000пкс]]

По умолчанию вышеописанные БП уже привязаны к своим эндпоинтам и можно их сразу использовать.
[[Файл:Appmaster Endpoints User Auth.png|центр|безрамки|1000x1000пкс]]

Для тестирования можно использовать Swagger консоль в которой можно видеть какие запросы к серверу отправляются.
[[Категория:Appmaster]]

Файл:Appmaster Endpoints User Auth.png

2024-10-18T17:30:02Z

SergeySkripov:

Файл:Appmaster BP User Logout.png

2024-10-18T17:29:08Z

SergeySkripov:

Файл:Appmaster BP User Sign In.png

2024-10-18T17:27:51Z

SergeySkripov:

Файл:Appmaster BP User Sign-up.png

2024-10-18T17:27:03Z

SergeySkripov:

Файл:Appmaster Auth UserSession.png

2024-10-18T17:26:20Z

SergeySkripov:

Appmaster Веб - Страницы и Шаблоны

2024-10-18T17:23:13Z

SergeySkripov: Новая страница: «мини Назначение основных разделов редактора веб приложений: - '''Elements''' - набор элементов которые можно использовать на страницах - '''Elements Tree''' - отображение иерархии элементов на выбранной странице - '''Navigations''' - используется для созд...»

[[Файл:Appmaster Web Pages.png|мини]]
Назначение основных разделов редактора веб приложений:

- '''Elements''' - набор элементов которые можно использовать на страницах

- '''Elements Tree''' - отображение иерархии элементов на выбранной странице

- '''Navigations''' - используется для создания и управлением страницами. Через него можно создавать новые страницы приложения и переключаться между существующими.

- '''Layouts''' - позволяет создавать шаблоны страниц и использовать их на других страницах.

- '''Assets''' - это раздел для хранения файлов необходимых для отображения страниц - иконки, картинки, файлы (фото, видео, музыка и т.п.)

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

В разделе бизнес процессов можно использовать триггеры, которые будут срабатывать при разных событиях связанных со страницей - Создание/Сборка/Обновление/Уничтожение.

После выбора нужной страницы можно перейти в раздел Elements Tree и начать работать с элементами страницы - редактировать/удалять.

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

При редактировании шаблона используется функционал аналогичный редактированию страницы - выбирается нужный шаблон и через ''Elements'' и ''Elements Tree'' добавляются элементы в шаблон.

В шаблоне есть один системный контейнер - Page Container, в этом контейнере будет отображаться содержимое страниц, которые будут использовать этот шаблон.

Все элементы шаблона глобально доступны на всех страницах использующих этот шаблон, например модальные окна или элементы.
[[Категория:Appmaster]]

Файл:Appmaster Web Pages.png

2024-10-18T17:20:28Z

SergeySkripov:

Верификация пользователя в Telegram MiniApps

2024-10-11T10:14:17Z

SergeySkripov:

После запуска приложения в [[Telegram MiniApps]] становятся доступны данные пользователя, который запустил приложение, но для того чтобы быть уверенным, что они не подделаны, необходимо убедится, что они получены именно от Телеграмма.

Процесс валидации описан в документации на странице: https://core.telegram.org/bots/webapps#validating-data-received-via-the-mini-app

Телеграм отдает строку с параметрами сессии в виде пар [[Ключ-Значение|ключ=значение]] разделенных знаком &.
chat_instance=-987654321&chat_type=private&auth_date=1728578319&hash=da928ae18a63cb17d5db7457247ec7b7201ddb9e28636c140131542a218ed341&user={"id":12345687,"first_name":"Иван","last_name":"Иванов","username":"iiva","language_code":"ru","allows_write_to_pm":true}
Сначала нужно разобрать полученную строку на массив пар ключ=значение, а после этого каждую пару также разделить отдельно на ключ и значение, сохранить их в новый массив для того, чтобы с ними можно было потом работать.

Для разделения используется блок Split с параметром Separator=&, он отдаст нам массив строк в которых будут пары ключ=значение, после этого мы проходим в цикле по всем строкам полученного массива и еще раз через блок Split разделяем их с параметром Separator='='. В результате на каждой итерации мы будем получать массив из двух элементов - название параметра (ключ) и значение, которые нам нужно сохранить в отдельный массив.
[[Файл:TG MiniApps initData verification split.png|центр|1000x1000пкс]]
'''Результат'''
chat_instance: -987654321
chat_type: private
auth_date: 1728578319
hash: da928ae18a63cb17d5db7457247ec7b7201ddb9e28636c140131542a218ed341
user: {"id":12345687,"first_name":"Иван","last_name":"Иванов","username":"iiva","language_code":"ru","allows_write_to_pm":true}
В зависимости от параметра нам нужно выполнять с ними разные действия.

В параметре user хранится строка с [[JSON]] в котором содержатся данные о пользователе Телеграм. Строка приходит в формате безопасном для передачи в URL, поэтому для дальнейшей работы с ней её нужно раскодировать. После этого мы десериализуем её в модель данных, а также сохраняем в массив Ключ-Значение.

Остальные параметры мы также сохраняем в массив Ключ-Значение, а само название параметра (ключ) сохраняем в отдельный массив [[String array]] т.к. он нам в дальнейшем понадобится для формирования подписи.

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

В результате работы цикла у нас получилось два массива:

1. Массив пар ключ-значение содержащий параметры пользователя.

2. Массив строк с ключами
[[Файл:TG MiniApps initData verification create array.png|центр|безрамки|1000x1000пкс]]

==== Проверка подписи ====
Проверка подписи заключается в том, чтобы мы подписали полученные данные своим [[Токен|токеном]] от бота и сравнили результат с хешем полученным из параметров. Но подпись совпадет только в том случае, если подписываемая строка в точности совпадает. Для этого в соответствии с документацией требуется отсортировать все полученные параметры по алфавиту, соединить их в строки ключ=значение, а эти строки соединить через разделитель "перенос строки". Т.е. каждая пара должна быть на новой строке.

Для этого мы делаем сортировку по алфавиту массива строк с ключами через блок [[Sort Array]].

После этого в цикле проходим по отсортированному массиву и берем из массива пар ключ-значение пару соответствующую этому ключу, объединяем ее в строку и добавляем в новый массив, в котором будут лежать строки в нужном порядке.
[[Файл:TG MiniApps initData verification sort array.png|центр|безрамки|1000x1000пкс]]

После окончания цикла, нам нужно собрать из полученного массива одну строку состоящую из значений разделенных переносом строки. Для этого используем блок [[Join Strings]], но т.к. символ переноса строки является спецсимволом, он будет экранирован в дальнейшем т.е. вместо \n он будет заменен на \\n. Чтобы этого избежать мы передадим строку в формате текста в котором просто поставим пустой перенос. Чтобы уменьшить количество блоков можно значение указать сразу на входе блока To String, т.к. блок Join Strings в значение параметра Separator может получать только значение типа String.

На данном этапе мы сформировали правильную строку идентичную тому какой она была в момент подписания токеном бота на стороне телеграмма.

Проверка подписи осуществляется в два этапа.

Сначала нужно создать ключ, для этого в блок [[Crypto: HMAC Sign]] нужно передать в параметр Key строку "WebAppData", в параметр Value токен бота. Обе строки нужно предварительно сконвертировать в типа "байты" используя блок [[To Bytes]]. В параметре Hash Type необходимо выбрать тип - sha256.

На втором этапе мы выполняем тоже самое действие только в параметры блока Key нужно передать полученный ключ на предыдущем шаге из поля Signature, а в параметр Value строку, которую до этого собрали из массива, её также нужно сконвертировать в байты.

Полученную подпись конвертируем в шестнадцатеричную систему используя блок [[Bytes to HEX String]]. Теперь нам нужно сравнить полученную строку с хешем полученным в самом начале из параметров полученных от телеграмма. Если строки совпадают, значит полученные данные пользователя пришли от источника который знает токен вашего бота, т.е. телеграмма.
[[Файл:TG MiniApps initData verification HMAC Sign.png|центр|безрамки|1000x1000пкс]]

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

[https://wiki-files.skripov.com/original/Appmaster_BP_TG_InitData.svg Посмотреть БП целиком]
[[Категория:Appmaster]]
[[Категория:Telegram]]

Файл:Appmaster BP TG InitData.svg

2024-10-11T10:07:19Z

SergeySkripov:

Верификация пользователя в Telegram MiniApps

2024-10-11T01:04:26Z

SergeySkripov:

После запуска приложения в [[Telegram MiniApps]] становятся доступны данные пользователя, который запустил приложение, но для того чтобы быть уверенным, что они не подделаны, необходимо убедится, что они получены именно от Телеграмма.

Процесс валидации описан в документации на странице: https://core.telegram.org/bots/webapps#validating-data-received-via-the-mini-app

Телеграм отдает строку с параметрами сессии в виде пар [[Ключ-Значение|ключ=значение]] разделенных знаком &.
chat_instance=-987654321&chat_type=private&auth_date=1728578319&hash=da928ae18a63cb17d5db7457247ec7b7201ddb9e28636c140131542a218ed341&user={"id":12345687,"first_name":"Иван","last_name":"Иванов","username":"iiva","language_code":"ru","allows_write_to_pm":true}
Сначала нужно разобрать полученную строку на массив пар ключ=значение, а после этого каждую пару также разделить отдельно на ключ и значение, сохранить их в новый массив для того, чтобы с ними можно было потом работать.

Для разделения используется блок Split с параметром Separator=&, он отдаст нам массив строк в которых будут пары ключ=значение, после этого мы проходим в цикле по всем строкам полученного массива и еще раз через блок Split разделяем их с параметром Separator='='. В результате на каждой итерации мы будем получать массив из двух элементов - название параметра (ключ) и значение, которые нам нужно сохранить в отдельный массив.
[[Файл:TG MiniApps initData verification split.png|центр|1000x1000пкс]]
'''Результат'''
chat_instance: -987654321
chat_type: private
auth_date: 1728578319
hash: da928ae18a63cb17d5db7457247ec7b7201ddb9e28636c140131542a218ed341
user: {"id":12345687,"first_name":"Иван","last_name":"Иванов","username":"iiva","language_code":"ru","allows_write_to_pm":true}
В зависимости от параметра нам нужно выполнять с ними разные действия.

В параметре user хранится строка с [[JSON]] в котором содержатся данные о пользователе Телеграм. Строка приходит в формате безопасном для передачи в URL, поэтому для дальнейшей работы с ней её нужно раскодировать. После этого мы десериализуем её в модель данных, а также сохраняем в массив Ключ-Значение.

Остальные параметры мы также сохраняем в массив Ключ-Значение, а само название параметра (ключ) сохраняем в отдельный массив [[String array]] т.к. он нам в дальнейшем понадобится для формирования подписи.

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

В результате работы цикла у нас получилось два массива:

1. Массив пар ключ-значение содержащий параметры пользователя.

2. Массив строк с ключами
[[Файл:TG MiniApps initData verification create array.png|центр|безрамки|1000x1000пкс]]

==== Проверка подписи ====
Проверка подписи заключается в том, чтобы мы подписали полученные данные своим [[Токен|токеном]] от бота и сравнили результат с хешем полученным из параметров. Но подпись совпадет только в том случае, если подписываемая строка в точности совпадает. Для этого в соответствии с документацией требуется отсортировать все полученные параметры по алфавиту, соединить их в строки ключ=значение, а эти строки соединить через разделитель "перенос строки". Т.е. каждая пара должна быть на новой строке.

Для этого мы делаем сортировку по алфавиту массива строк с ключами через блок [[Sort Array]].

После этого в цикле проходим по отсортированному массиву и берем из массива пар ключ-значение пару соответствующую этому ключу, объединяем ее в строку и добавляем в новый массив, в котором будут лежать строки в нужном порядке.
[[Файл:TG MiniApps initData verification sort array.png|центр|безрамки|1000x1000пкс]]

После окончания цикла, нам нужно собрать из полученного массива одну строку состоящую из значений разделенных переносом строки. Для этого используем блок [[Join Strings]], но т.к. символ переноса строки является спецсимволом, он будет экранирован в дальнейшем т.е. вместо \n он будет заменен на \\n. Чтобы этого избежать мы передадим строку в формате текста в котором просто поставим пустой перенос. Чтобы уменьшить количество блоков можно значение указать сразу на входе блока To String, т.к. блок Join Strings в значение параметра Separator может получать только значение типа String.

На данном этапе мы сформировали правильную строку идентичную тому какой она была в момент подписания токеном бота на стороне телеграмма.

Проверка подписи осуществляется в два этапа.

Сначала нужно создать ключ, для этого в блок [[Crypto: HMAC Sign]] нужно передать в параметр Key строку "WebAppData", в параметр Value токен бота. Обе строки нужно предварительно сконвертировать в типа "байты" используя блок [[To Bytes]]. В параметре Hash Type необходимо выбрать тип - sha256.

На втором этапе мы выполняем тоже самое действие только в параметры блока Key нужно передать полученный ключ на предыдущем шаге из поля Signature, а в параметр Value строку, которую до этого собрали из массива, её также нужно сконвертировать в байты.

Полученную подпись конвертируем в шестнадцатеричную систему используя блок [[Bytes to HEX String]]. Теперь нам нужно сравнить полученную строку с хешем полученным в самом начале из параметров полученных от телеграмма. Если строки совпадают, значит полученные данные пользователя пришли от источника который знает токен вашего бота, т.е. телеграмма.
[[Файл:TG MiniApps initData verification HMAC Sign.png|центр|безрамки|1000x1000пкс]]

Важно! В случае если токен бота будет известен третьим лицам, они смогут сформировать подпись и передать данные любого пользователя в ваше приложение т.е. войти от имени любого пользователя. Для дополнительной безопасности, можно использовать одноразовые коды или отправлять подтверждения в бота пользователю т.к. злоумышленник не сможет получить к ним доступ.
[[Категория:Appmaster]]
[[Категория:Telegram]]

Верификация пользователя в Telegram MiniApps

2024-10-11T00:55:58Z

SergeySkripov:

После запуска приложения в [[Telegram MiniApps]] становятся доступны данные пользователя, который запустил приложение, но для того чтобы быть уверенным, что они не подделаны, необходимо убедится, что они получены именно от Телеграмма.

Процесс валидации описан в документации на странице: https://core.telegram.org/bots/webapps#validating-data-received-via-the-mini-app

Телеграм отдает строку с параметрами сессии в виде пар [[Ключ-Значение|ключ=значение]] разделенных знаком &.
chat_instance=-987654321&chat_type=private&auth_date=1728578319&hash=da928ae18a63cb17d5db7457247ec7b7201ddb9e28636c140131542a218ed341&user={"id":12345687,"first_name":"Иван","last_name":"Иванов","username":"iiva","language_code":"ru","allows_write_to_pm":true}
Сначала нужно разобрать полученную строку на массив пар ключ=значение, а после этого каждую пару также разделить отдельно на ключ и значение, сохранить их в новый массив для того, чтобы с ними можно было потом работать.

Для разделения используется блок Split с параметром Separator=&, он отдаст нам массив строк в которых будут пары ключ=значение, после этого мы проходим в цикле по всем строкам полученного массива и еще раз через блок Split разделяем их с параметром Separator='='. В результате на каждой итерации мы будем получать массив из двух элементов - название параметра (ключ) и значение, которые нам нужно сохранить в отдельный массив.
[[Файл:TG MiniApps initData verification split.png|центр|1000x1000пкс]]
'''Результат'''
chat_instance: -987654321
chat_type: private
auth_date: 1728578319
hash: da928ae18a63cb17d5db7457247ec7b7201ddb9e28636c140131542a218ed341
user: {"id":12345687,"first_name":"Иван","last_name":"Иванов","username":"iiva","language_code":"ru","allows_write_to_pm":true}
В зависимости от параметра нам нужно выполнять с ними разные действия.

В параметре user хранится строка с [[JSON]] в котором содержатся данные о пользователе Телеграм. Строка приходит в формате безопасном для передачи в URL, поэтому для дальнейшей работы с ней её нужно раскодировать. После этого мы десериализуем её в модель данных, а также сохраняем в массив Ключ-Значение.

Остальные параметры мы также сохраняем в массив Ключ-Значение, а само название параметра (ключ) сохраняем в отдельный массив [[String array]] т.к. он нам в дальнейшем понадобится для формирования подписи.

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

В результате работы цикла у нас получилось два массива:

1. Массив пар ключ-значение содержащий параметры пользователя.

2. Массив строк с ключами
[[Файл:TG MiniApps initData verification create array.png|центр|безрамки|1000x1000пкс]]

==== Проверка подписи ====
Проверка подписи заключается в том, чтобы мы подписали полученные данные своим [[Токен|токеном]] от бота и сравнили результат с хешем полученным из параметров. Но подпись совпадет только в том случае, если подписываемая строка в точности совпадает. Для этого в соответствии с документацией требуется отсортировать все полученные параметры по алфавиту, соединить их в строки ключ=значение, а эти строки соединить через разделитель "перенос строки". Т.е. каждая пара должна быть на новой строке.

Для этого мы делаем сортировку по алфавиту массива строк с ключами через блок [[Sort Array]].

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

После окончания цикла, нам нужно собрать из полученного массива одну строку состоящую из значений разделенных переносом строки. Для этого используем блок [[Join Strings]], но т.к. символ переноса строки является спецсимволом, он будет экранирован в дальнейшем т.е. вместо \n он будет заменен на \\n. Чтобы этого избежать мы передадим строку в формате текста в котором просто поставим пустой перенос. Чтобы уменьшить количество блоков можно значение указать сразу на входе блока To String, т.к. блок Join Strings в значение параметра Separator может получать только значение типа String.

На данном этапе мы сформировали правильную строку идентичную тому какой она была в момент подписания токеном бота на стороне телеграмма.
[[Файл:TG MiniApps initData verification sort array.png|центр|безрамки|1000x1000пкс]]

Проверка подписи осуществляется в два этапа.

Сначала нужно создать ключ, для этого в блок [[Crypto: HMAC Sign]] нужно передать в параметр Key строку "WebAppData", в параметр Value токен бота. Обе строки нужно предварительно сконвертировать в типа "байты" используя блок [[To Bytes]]. В параметре Hash Type необходимо выбрать тип - sha256.

На втором этапе мы выполняем тоже самое действие только в параметры блока Key нужно передать полученный ключ на предыдущем шаге из поля Signature, а в параметр Value строку, которую до этого собрали из массива, её также нужно сконвертировать в байты.

Полученную подпись конвертируем в шестнадцатеричную систему используя блок [[Bytes to HEX String]]. Теперь нам нужно сравнить полученную строку с хешем полученным в самом начале из параметров полученных от телеграмма. Если строки совпадают, значит полученные данные пользователя пришли от источника который знает токен вашего бота, т.е. телеграмма.
[[Файл:TG MiniApps initData verification HMAC Sign.png|центр|безрамки|1000x1000пкс]]

Важно! В случае если токен бота будет известен третьим лицам, они смогут сформировать подпись и передать данные любого пользователя в ваше приложение т.е. войти от имени любого пользователя. Для дополнительной безопасности, можно использовать одноразовые коды или отправлять подтверждения в бота пользователю т.к. злоумышленник не сможет получить к ним доступ.
[[Категория:Appmaster]]
[[Категория:Telegram]]

Заглавная страница

2024-10-11T00:45:54Z

SergeySkripov:

Верификация пользователя в Telegram MiniApps

2024-10-11T00:39:59Z

SergeySkripov:

После запуска приложения в [[Telegram MiniApps]] становятся доступны данные пользователя, который запустил приложение, но для того чтобы быть уверенным, что они не подделаны, необходимо убедится, что они получены именно от Телеграмма.

Процесс валидации описан в документации на странице: https://core.telegram.org/bots/webapps#validating-data-received-via-the-mini-app

Телеграм отдает строку с параметрами сессии в виде пар [[Ключ-Значение|ключ=значение]] разделенных знаком &.

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

Для разделения используется блок Split с параметром Separator=&, он отдаст нам массив строк в которых будут пары ключ=значение, после этого мы проходим в цикле по всем строкам полученного массива и еще раз через блок Split разделяем их с параметром Separator='='. В результате на каждой итерации мы будем получать массив из двух элементов - название параметра (ключ) и значение, которые нам нужно сохранить в отдельный массив.
[[Файл:TG MiniApps initData verification split.png|центр|1000x1000пкс]]

В зависимости от параметра нам нужно выполнять с ними разные действия.

В параметре user хранится строка с [[JSON]] в котором содержатся данные о пользователе Телеграм. Строка приходит в формате безопасном для передачи в URL, поэтому для дальнейшей работы с ней её нужно раскодировать. После этого мы десериализуем её в модель данных, а также сохраняем в массив Ключ-Значение.

Остальные параметры мы также сохраняем в массив Ключ-Значение, а само название параметра (ключ) сохраняем в отдельный массив [[String array]] т.к. он нам в дальнейшем понадобится для формирования подписи.

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

В результате работы цикла у нас получилось два массива:

1. Массив пар ключ-значение содержащий параметры пользователя.

2. Массив строк с ключами
[[Файл:TG MiniApps initData verification create array.png|центр|безрамки|1000x1000пкс]]

==== Проверка подписи ====
Проверка подписи заключается в том, чтобы мы подписали полученные данные своим [[Токен|токеном]] от бота и сравнили результат с хешем полученным из параметров. Но подпись совпадет только в том случае, если подписываемая строка в точности совпадает. Для этого в соответствии с документацией требуется отсортировать все полученные параметры по алфавиту, соединить их в строки ключ=значение, а эти строки соединить через разделитель "перенос строки". Т.е. каждая пара должна быть на новой строке.

Для этого мы делаем сортировку по алфавиту массива строк с ключами через блок [[Sort Array]].

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

После окончания цикла, нам нужно собрать из полученного массива одну строку состоящую из значений разделенных переносом строки. Для этого используем блок [[Join Strings]], но т.к. символ переноса строки является спецсимволом, он будет экранирован в дальнейшем т.е. вместо \n он будет заменен на \\n. Чтобы этого избежать мы передадим строку в формате текста в котором просто поставим пустой перенос. Чтобы уменьшить количество блоков можно значение указать сразу на входе блока To String, т.к. блок Join Strings в значение параметра Separator может получать только значение типа String.

На данном этапе мы сформировали правильную строку идентичную тому какой она была в момент подписания токеном бота на стороне телеграмма.
[[Файл:TG MiniApps initData verification sort array.png|центр|безрамки|1000x1000пкс]]

Проверка подписи осуществляется в два этапа.

Сначала нужно создать ключ, для этого в блок [[Crypto: HMAC Sign]] нужно передать в параметр Key строку "WebAppData", в параметр Value токен бота. Обе строки нужно предварительно сконвертировать в типа "байты" используя блок [[To Bytes]]. В параметре Hash Type необходимо выбрать тип - sha256.

На втором этапе мы выполняем тоже самое действие только в параметры блока Key нужно передать полученный ключ на предыдущем шаге из поля Signature, а в параметр Value строку, которую до этого собрали из массива, её также нужно сконвертировать в байты.

Полученную подпись конвертируем в шестнадцатеричную систему используя блок [[Bytes to HEX String]]. Теперь нам нужно сравнить полученную строку с хешем полученным в самом начале из параметров полученных от телеграмма. Если строки совпадают, значит полученные данные пользователя пришли от источника который знает токен вашего бота, т.е. телеграмма.
[[Файл:TG MiniApps initData verification HMAC Sign.png|центр|безрамки|1000x1000пкс]]

Важно! В случае если токен бота будет известен третьим лицам, они смогут сформировать подпись и передать данные любого пользователя в ваше приложение т.е. войти от имени любого пользователя. Для дополнительной безопасности, можно использовать одноразовые коды или отправлять подтверждения в бота пользователю т.к. злоумышленник не сможет получить к ним доступ.
[[Категория:Appmaster]]
[[Категория:Telegram]]

Верификация пользователя в Telegram MiniApps

2024-10-11T00:38:09Z

SergeySkripov: Новая страница: «После запуска приложения в Telegram MiniApps становятся доступны данные пользователя, который запустил приложение, но для того чтобы быть уверенным, что они не подделаны, необходимо убедится, что они получены именно от Телеграмма. Процесс валидации описан...»

После запуска приложения в [[Telegram MiniApps]] становятся доступны данные пользователя, который запустил приложение, но для того чтобы быть уверенным, что они не подделаны, необходимо убедится, что они получены именно от Телеграмма.

Процесс валидации описан в документации на странице: <nowiki>https://core.telegram.org/bots/webapps#validating-data-received-via-the-mini-app</nowiki>

Телеграм отдает строку с параметрами сессии в виде пар [[Ключ-Значение|ключ=значение]] разделенных знаком &.

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

Для разделения используется блок Split с параметром Separator=&, он отдаст нам массив строк в которых будут пары ключ=значение, после этого мы проходим в цикле по всем строкам полученного массива и еще раз через блок Split разделяем их с параметром Separator='='. В результате на каждой итерации мы будем получать массив из двух элементов - название параметра (ключ) и значение, которые нам нужно сохранить в отдельный массив.
[[Файл:TG MiniApps initData verification split.png|центр|безрамки|1000x1000пкс]]

В зависимости от параметра нам нужно выполнять с ними разные действия.

В параметре user хранится строка с [[JSON]] в котором содержатся данные о пользователе Телеграм. Строка приходит в формате безопасном для передачи в URL, поэтому для дальнейшей работы с ней её нужно раскодировать. После этого мы десериализуем её в модель данных, а также сохраняем в массив Ключ-Значение.

Остальные параметры мы также сохраняем в массив Ключ-Значение, а само название параметра (ключ) сохраняем в отдельный массив [[String array]] т.к. он нам в дальнейшем понадобится для формирования подписи.

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

В результате работы цикла у нас получилось два массива:

1. Массив пар ключ-значение содержащий параметры пользователя.

2. Массив строк с ключами
[[Файл:TG MiniApps initData verification create array.png|центр|безрамки|1000x1000пкс]]

==== Проверка подписи ====
Проверка подписи заключается в том, чтобы мы подписали полученные данные своим [[Токен|токеном]] от бота и сравнили результат с хешем полученным из параметров. Но подпись совпадет только в том случае, если подписываемая строка в точности совпадает. Для этого в соответствии с документацией требуется отсортировать все полученные параметры по алфавиту, соединить их в строки ключ=значение, а эти строки соединить через разделитель "перенос строки". Т.е. каждая пара должна быть на новой строке.

Для этого мы делаем сортировку по алфавиту массива строк с ключами через блок [[Sort Array]].

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

После окончания цикла, нам нужно собрать из полученного массива одну строку состоящую из значений разделенных переносом строки. Для этого используем блок [[Join Strings]], но т.к. символ переноса строки является спецсимволом, он будет экранирован в дальнейшем т.е. вместо \n он будет заменен на \\n. Чтобы этого избежать мы передадим строку в формате текста в котором просто поставим пустой перенос. Чтобы уменьшить количество блоков можно значение указать сразу на входе блока To String, т.к. блок Join Strings в значение параметра Separator может получать только значение типа String.

На данном этапе мы сформировали правильную строку идентичную тому какой она была в момент подписания токеном бота на стороне телеграмма.
[[Файл:TG MiniApps initData verification sort array.png|центр|безрамки|1000x1000пкс]]

Проверка подписи осуществляется в два этапа.

Сначала нужно создать ключ, для этого в блок [[Crypto: HMAC Sign]] нужно передать в параметр Key строку "WebAppData", в параметр Value токен бота. Обе строки нужно предварительно сконвертировать в типа "байты" используя блок [[To Bytes]]. В параметре Hash Type необходимо выбрать тип - sha256.

На втором этапе мы выполняем тоже самое действие только в параметры блока Key нужно передать полученный ключ на предыдущем шаге из поля Signature, а в параметр Value строку, которую до этого собрали из массива, её также нужно сконвертировать в байты.

Полученную подпись конвертируем в шестнадцатеричную систему используя блок [[Bytes to HEX String]]. Теперь нам нужно сравнить полученную строку с хешем полученным в самом начале из параметров полученных от телеграмма. Если строки совпадают, значит полученные данные пользователя пришли от источника который знает токен вашего бота, т.е. телеграмма.
[[Файл:TG MiniApps initData verification HMAC Sign.png|центр|безрамки|1000x1000пкс]]

Важно! В случае если токен бота будет известен третьим лицам, они смогут сформировать подпись и передать данные любого пользователя в ваше приложение т.е. войти от имени любого пользователя. Для дополнительной безопасности, можно использовать одноразовые коды или отправлять подтверждения в бота пользователю т.к. злоумышленник не сможет получить к ним доступ.
[[Категория:Appmaster]]
[[Категория:Telegram]]

Файл:TG MiniApps initData verification HMAC Sign.png

2024-10-11T00:36:43Z

SergeySkripov:

Файл:TG MiniApps initData verification sort array.png

2024-10-11T00:33:11Z

SergeySkripov:

Файл:TG MiniApps initData verification create array.png

2024-10-11T00:27:24Z

SergeySkripov:

Файл:TG MiniApps initData verification split.png

2024-10-11T00:23:31Z

SergeySkripov:

Заглавная страница

2024-09-26T09:44:31Z

SergeySkripov:

Категория:Appmaster

2024-09-26T09:42:29Z

SergeySkripov: Новая страница: «Статьи связанные ноукод платформой Appmaster»

Статьи связанные ноукод платформой Appmaster

Appmaster Web - Расположение элементов

2024-09-26T09:41:44Z

SergeySkripov: Новая страница: «Для расположения элементов на странице нужно использовать Flex Container. Контейнеры можно вкладывать друг в друга и использовать направление переноса для создания строк или столбцов. мини мини В разделе Layout на...»

Для расположения элементов на странице нужно использовать Flex Container. Контейнеры можно вкладывать друг в друга и использовать направление переноса для создания строк или столбцов.
[[Файл:AppmasterWebContainers.png|мини]]
[[Файл:AppmasterWeb LayoutOptions.png|мини]]

В разделе Layout настроек контейнера можно задавать следующие параметры:

- '''Direction''' - направление расположения элементов в контейнере - горизонтальное/вертикальное, а также менять порядок элементов в обратную сторону (reverse)

- '''Align''' - выравнивание по горизонтали - по правому/левому краю, середине или по ширине.

- '''Justify''' - выравнивание по вертикали - по верхнему/нижнему краю, центру или можно растянуть по всей высоте равномерно или с прижатием к краям.

- '''Gap''' - задает расстояние между элементов

- '''Wrap''' - нужно ли переносить элементы внутри контейнера, по умолчанию все элементы будут выстроены в одну строку или столбец и будут поджиматься не зависимо от их размеров для того, чтобы поместиться в размеры контейнера. Если задан перенос, то элементы которые не помещаются в размер родительского контейнера будут перенесены на следующий ряд.
[[Категория:Appmaster]]

Файл:AppmasterWeb LayoutOptions.png

2024-09-26T09:40:21Z

SergeySkripov:

Файл:AppmasterWebContainers.png

2024-09-26T09:39:30Z

SergeySkripov:

Категория:FlutterFlow

2024-09-26T09:33:14Z

SergeySkripov: Новая страница: «Статьи связанные с разработкой на FlutterFlow»

Статьи связанные с разработкой на FlutterFlow

Telegram Mini Apps на FlutterFlow

2024-09-26T09:32:29Z

SergeySkripov:

'''Telegram MiniApps''' это веб сайты или веб приложения, которые отображаются внутри приложения Telegram и позволяют взаимодействовать с интерфейсом и данными мессенджера.

Документация для MiniApps находится тут: https://core.telegram.org/bots/webapps

Для того, чтобы из FlutterFlow взаимодействовать с методами Telegram нужно добавить в Headers сгенерированного сайта скрипт телеграмма.

<code><script src="https://telegram.org/js/telegram-web-app.js"></script></code>

Редактирование заголовков в веб приложении находится в разделе '''Settings->WebDeployment->Custom Headers'''
[[Файл:FlutterFlow Telegram script.png|1000px|центр|безрамки]]

Для получения данных из Telegram Client нужно использовать Custom Actions.

Пример получения данных пользователя:

''// Automatic FlutterFlow imports''

''import '/backend/schema/structs/index.dart';''

''import '/flutter_flow/flutter_flow_theme.dart';''

''import '/flutter_flow/flutter_flow_util.dart';''

''import '/custom_code/actions/index.dart'; // Imports other custom actions''

''import '/flutter_flow/custom_functions.dart'; // Imports custom functions''

''import 'package:flutter/material.dart';''

''// Begin custom action code''

''// DO NOT REMOVE OR MODIFY THE CODE ABOVE!''

''import 'dart:js' as js;''

''Future<String?> tgInitData() async {''

'' // Add your function code here!''

'' return js.context['Telegram']['WebApp']['initData'].toString();''

''}''

В результате выполнения Custom Action вернет строку с данными пользователя в виде:

<code>user=%7B%22id%22%3A38325274%2C%22first_name%22%3A%22%D0%A1%D0%B5%D1%80%D0%B3%D0%B5%D0%B9%22%2C%22last_name%22%3A%22%D0%A1%D0%BA%D1%80%D0%B8%D0%BF%D0%BE%D0%B2%22%2C%22username%22%3A%22skripov%22%2C%22language_code%22%3A%22ru%22%2C%22allows_write_to_pm%22%3Atrue%7D&chat_instance=7108251674217944838&chat_type=supergroup&auth_date=1727340618&hash=b4eaf17f4b5f2ba6cd82c743cba25eabb26a33830aca6071c6f53b318317a4a0</code>

Эту строку дальше необходимо разобрать и [https://core.telegram.org/bots/webapps#validating-data-received-via-the-mini-app валидировать] на бэкенде, т.к. злоумышленник может ее подделать. Суть валидации - это сравнение значения в поле hash с подписью всех полученных в строке данных токеном бота, именно по этой причине это нужно делать на бэкенде или облачной функции, чтобы у пользователя не было доступа к токену вашего бота из которого запускается MiniApp.

Другие доступные объекты и методы MiniApps описаны в документации: https://core.telegram.org/bots/webapps#initializing-mini-apps
[[Категория:FlutterFlow]]
[[Категория:Telegram]]

Telegram Mini Apps на FlutterFlow

2024-09-26T09:20:41Z

SergeySkripov:

Telegram Mini Apps на FlutterFlow

2024-09-26T09:19:52Z

SergeySkripov: Новая страница: «'''Telegram MiniApps''' это веб сайты или веб приложения, которые отображаются внутри приложения Telegram и позволяют взаимодействовать с интерфейсом и данными мессенджера. Документация для MiniApps находится тут: https://core.telegram.org/bots/webapps Для того, чтобы из FlutterFlow взаимод...»

'''Telegram MiniApps''' это веб сайты или веб приложения, которые отображаются внутри приложения Telegram и позволяют взаимодействовать с интерфейсом и данными мессенджера.

Документация для MiniApps находится тут: https://core.telegram.org/bots/webapps

Для того, чтобы из FlutterFlow взаимодействовать с методами Telegram нужно добавить в Headers сгенерированного сайта скрипт телеграмма.

<code><script src="https://telegram.org/js/telegram-web-app.js"></script></code>

Редактирование заголовков в веб приложении находится в разделе '''Settings->WebDeployment->Custom Headers'''
[[Файл:FlutterFlow Telegram script.png|центр|безрамки]]

Для получения данных из Telegram Client нужно использовать Custom Actions.

Пример получения данных пользователя:

''// Automatic FlutterFlow imports''

''import '/backend/schema/structs/index.dart';''

''import '/flutter_flow/flutter_flow_theme.dart';''

''import '/flutter_flow/flutter_flow_util.dart';''

''import '/custom_code/actions/index.dart'; // Imports other custom actions''

''import '/flutter_flow/custom_functions.dart'; // Imports custom functions''

''import 'package:flutter/material.dart';''

''// Begin custom action code''

''// DO NOT REMOVE OR MODIFY THE CODE ABOVE!''

''import 'dart:js' as js;''

''Future<String?> tgInitData() async {''

'' // Add your function code here!''

'' return js.context['Telegram']['WebApp']['initData'].toString();''

''}''

В результате выполнения Custom Action вернет строку с данными пользователя в виде:

<code>user=%7B%22id%22%3A38325274%2C%22first_name%22%3A%22%D0%A1%D0%B5%D1%80%D0%B3%D0%B5%D0%B9%22%2C%22last_name%22%3A%22%D0%A1%D0%BA%D1%80%D0%B8%D0%BF%D0%BE%D0%B2%22%2C%22username%22%3A%22skripov%22%2C%22language_code%22%3A%22ru%22%2C%22allows_write_to_pm%22%3Atrue%7D&chat_instance=7108251674217944838&chat_type=supergroup&auth_date=1727340618&hash=b4eaf17f4b5f2ba6cd82c743cba25eabb26a33830aca6071c6f53b318317a4a0</code>

Эту строку дальше необходимо разобрать и [https://core.telegram.org/bots/webapps#validating-data-received-via-the-mini-app валидировать] на бэкенде, т.к. злоумышленник может ее подделать. Суть валидации - это сравнение значения в поле hash с подписью всех полученных в строке данных токеном бота, именно по этой причине это нужно делать на бэкенде или облачной функции, чтобы у пользователя не было доступа к токену вашего бота из которого запускается MiniApp.

Другие доступные объекты и методы MiniApps описаны в документации: https://core.telegram.org/bots/webapps#initializing-mini-apps

Файл:FlutterFlow Telegram script.png

2024-09-26T08:41:43Z

SergeySkripov:

Заглавная страница

2024-09-26T08:33:47Z

SergeySkripov:

Файл:Josh-berquist- 4sWbzH5fp8-unsplash.jpg

2024-09-24T23:07:51Z

SergeySkripov:

Участник:SergeySkripov

2024-09-24T23:05:14Z

SergeySkripov: Новая страница: «MediaWiki:Sidebar»

[[MediaWiki:Sidebar]]