Облачный сервис с безграничными возможностями: Бот или не бот - вот в чем вопрос.

Друзьям и коллегам, привет!

Недавно опубликовал на Хабр новую статью с разбором моего Web3-мессенджера. В ней описал личный кейс: как внедрить децентрализованные Web3 технологии и монетизировать внутренние функции приложения без подключения классических платежных систем. Почитать можно здесь: https://habr.com/ru/articles/1052088/

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

Создав так называемых "юзер-ботов" (user-bots), я снабдил платформу дополнительными функциями. В моей реализации такой "Бот" - это полноценный внешний сервис, который имеет точку входа - Endpoint на стороннем облаке и строгий протокол взаимодействия через его API.

В таких популярных приложениях как Telegram или WhatsApp, боты представляют собой отдельные сущности, которые привязываются к основному аккаунту пользователя. Кстати, вопреки расхожему мнению, один аккаунт в Telegram может создать через BotFather не безграничное число ботов, а строго до 20 штук (до 40 для Premium-пользователей).

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

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

• Полный контроль и безопасность окружения: бот изолирован и работает строго в рамках правил реального пользователя.

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

• Готовая монетизация: в профиле каждого пользователя уже прописаны платежные данные в виде Web3-кошелька. Соответственно, они автоматически доступны и боту, если тот реализует платные услуги.

РЕАЛИЗАЦИЯ НА БЭКЕНДЕ

Ниже упрощенный код класса реализующий передачу сообщений на Endpoint:

public async Task<string> ExecuteCommand(string cmd, string uid, string token, string url)
{
    using var client = new HttpClient();
    client.DefaultRequestHeaders.Authorization = new ("Bearer", token);
    
    var body = new StringContent(JsonConvert.SerializeObject(new { data = cmd, user_id = uid }), Encoding.UTF8, "application/json");
    var res = await client.PostAsync(url, body);
    var json = JObject.Parse(await res.Content.ReadAsStringAsync());

    return json["success"]?.Value<bool>() == true 
        ? json["data"]?.ToString() 
        : $"Error: {json["error"]}";
}  

Рабочий шаблон внешнего Endpoint сервиса:

<?php
session_start();
header('Content-Type: text/html; charset=utf-8');

//AUTHENTICATION BEGIN

$allowedToken   = 'super-secret-token';
$providedToken  = '';

if (isset($_SERVER['HTTP_AUTHORIZATION'])) {
    if (preg_match('/Bearer\s+(.+)/i', $_SERVER['HTTP_AUTHORIZATION'], $m)) {
        $providedToken = trim($m[1]);
    }
}

if (empty($providedToken) || $providedToken !== $allowedToken) {
    echo json_encode(['success' => false, 'error' => 'error token']);
    exit;
}

//AUTHENTICATION END

$rawInput = file_get_contents('php://input');
$userData = json_decode($rawInput, true); 

echo json_encode(['success' => true, 'data' => 'Bot answer: ' . $userData['data'] ?? null]);

?>

ВЫВОД

Используя описанную концепцию, можно в теории реализовать любой сервис не изменяя при этом основное приложение. Всё что нужно сделать, построить бот!

Очевидно, что для практического применения такого подхода необходимо обеспечить высокий уровень безопасности: внедрить защиту от SSRF (через валидацию URL и фильтрацию локальных хостов), настроить лимиты для предотвращения DoS-атак (проверяя размер заголовков и длину полученной строки), и так далее.

Всем успехов в разработке!

Благодарю за внимание.