Программисты — удалённая работа в Санкт-Петербурге

Создание программы. Разработка с нуля. 1. Общие сведения Цель проекта: Разработать серверное приложение, которое будет принимать RTSP‑поток с камеры, ретранслировать его клиентам через собственный RTSP‑сервер и предоставлять REST‑API для управления списком камер, пользователями и их правами. Основной сценарий использования: Камера имеет собственный RTSP‑поток (например, rtsp://admin:[Email скрыт]/1/1). Сервер (например, с IP 192.168.1.200) подключается к камере, получает поток и ретранслирует его по новому URL, например, rtsp://192.168.1.200/camera1/<token>. Клиент (например, VLC или ffplay) подключается к серверу по указанному URL и получает поток. Система должна поддерживать авторизацию и разграничение прав для доступа к разным камерам. Через REST‑API возможно добавление, удаление и редактирование камер, а также управление пользователями и их правами. 2. Функциональные требования 2.1 RTSP‑прокси Подключение к камере: Сервер должен выступать как RTSP‑клиент, подключаться к камере по заданному URL (с учётными данными) и получать поток (DESCRIBE, SETUP, PLAY). Ретрансляция потока: Принятые RTP‑пакеты с камеры должны передаваться через RTSP‑сервер. Внешним клиентам (RTSP‑клиентам) сервер предоставляет SDP‑описание и RTP‑пакеты по новому URL, например: rtsp://192.168.1.200/camera1/<token> Поддержка нескольких камер: Приложение должно поддерживать одновременную работу с несколькими камерами, идентифицируемыми по уникальным именам (например, camera1, camera2 и т.д.). 2.2 Авторизация и разграничение прав Аутентификация пользователей: Пользователь при входе (через API) вводит логин/пароль, сервер проверяет данные и выдает постоянный токен (API‑key), который используется для последующих запросов. Права доступа: Каждый пользователь имеет набор прав (например, просмотр потоков, редактирование настроек камер). Для каждой камеры можно определить, кто имеет право на просмотр, изменение и т.д. Проверка токена: RTSP‑сервер и API‑сервер должны проверять переданный токен и разрешать или запрещать доступ к конкретной камере на основании прав пользователя. 2.3 API для управления Управление камерами: Эндпоинты для добавления, редактирования и удаления записей о камерах (URL, имя, параметры подключения, описание, привязка к пользователям и т.д.). Управление пользователями: Эндпоинты для регистрации, аутентификации, редактирования и удаления пользователей. Возможность назначения прав доступа (например, просмотр, редактирование, управление конкретными камерами). Логирование и мониторинг: API должен вести логирование запросов и событий (подключения, ошибки и т.д.). 3. Нефункциональные требования Производительность: Приложение должно обрабатывать одновременное подключение множества RTSP‑клиентов (минимум 50–100 одновременных потоков) без существенных задержек. Безопасность: Все API‑запросы должны быть защищены (например, HTTPS для API, а RTSP‑сервер может использовать авторизацию на уровне токенов). Масштабируемость: Архитектура должна предусматривать возможность масштабирования (например, горизонтальное масштабирование или кластеризацию). Надёжность: Приложение должно корректно обрабатывать ошибки подключения к камерам, ошибки ретрансляции и недоступность базы данных. Лёгкость поддержки: Код должен быть хорошо документирован, покрыт тестами, иметь модульную архитектуру. 4. Архитектура системы 4.1 Компоненты RTSP‑Клиент / Прокси: Подключается к камерам, получает поток, осуществляет аутентификацию на стороне камеры. Преобразует полученные RTP‑пакеты в формат, пригодный для ретрансляции. RTSP‑Сервер: Обслуживает подключения внешних клиентов. Возвращает SDP‑описание и передает RTP‑пакеты клиентам. Привязывает подключение к определённой камере (например, по пути /camera1/<token>). API‑Сервер: REST‑API для управления камерами и пользователями. Обработка запросов на добавление, удаление, изменение данных. Реализация аутентификации и проверки прав доступа. База данных: Хранение информации о камерах (URL, имя, параметры) и пользователях (логин, пароль, токен, права доступа). 4.2 Взаимодействие компонентов Прокси-секция: При старте приложения сервер считывает список камер из базы данных. Для каждой камеры создается RTSP‑клиент, который подключается к камере и получает поток. Полученный поток сохраняется в объекте (ServerStream), используемом RTSP‑сервером для ретрансляции. RTSP‑Сервер: Клиент подключается к RTSP‑серверу по URL вида rtsp://192.168.1.200/camera1/<token>. Сервер проверяет токен и, если доступ разрешен, возвращает SDP‑описание и начинает передачу RTP‑пакетов из ServerStream. API‑Сервер: Предоставляет REST‑API для управления камерами и пользователями. При входе пользователя (login) сервер проверяет учетные данные и возвращает постоянный токен. При последующих запросах сервер проверяет токен и разрешает операции в соответствии с правами пользователя. 5. Технологический стек Язык программирования: Go RTSP‑библиотека: gortsplib/v4 HTTP API: Стандартный пакет net/http или фреймворки (Echo, Gin) База данных: PostgreSQL, SQLite или другая СУБД (опционально с ORM, например, GORM) Аутентификация: Реализация на основе постоянного токена (API‑key) с хранением в базе Логирование: Стандартный log или сторонние библиотеки (zap, logrus) 6. Пример API эндпоинтов POST /login Вход пользователя. Запрос: JSON с полями username и password. Ответ: Токен, который используется для последующих запросов. GET /cameras Получение списка камер. Доступ: Пользователь с правом на просмотр. POST /cameras Добавление новой камеры. Доступ: Пользователь с правом на редактирование. PUT /cameras/{id} Редактирование параметров камеры. Доступ: Пользователь с правом на редактирование. DELETE /cameras/{id} Удаление камеры. Доступ: Пользователь с правом на редактирование. GET /users Получение списка пользователей (только для администратора). POST /users Создание нового пользователя с указанием прав доступа. PUT /users/{id} и DELETE /users/{id} Редактирование или удаление пользователя. 7. Требования к безопасности Все API‑запросы должны проверять токен, передаваемый в заголовке (например, Authorization: Bearer <token>). Токен должен быть постоянным (не JWT, а уникальный API‑ключ), который не меняется при обновлении прав доступа. При обращении к RTSP‑серверу, сервер должен проверять, имеет ли пользователь (по токену) право на доступ к конкретной камере. Для API‑сервера рекомендуется использовать HTTPS для защиты данных. 8. План разработки Прототипирование RTSP‑прокси: Реализовать подключение к камере через gortsplib. Получать поток и ретранслировать его через RTSP‑сервер. Проверить работоспособность через VLC/ffplay. Реализация API‑сервера: Создать REST‑API для управления камерами и пользователями. Реализовать эндпоинты для login и CRUD операций. Интеграция модулей: Объединить RTSP‑прокси и API‑сервер в одно приложение. Добавить модуль аутентификации и проверки прав для RTSP‑подключений. Тестирование: Провести нагрузочное тестирование RTSP‑потока. Протестировать работу API, корректность выдачи токенов и проверки прав. Провести тестирование безопасности (например, попытки несанкционированного доступа). Документация и деплой: Подготовить документацию по API и RTSP‑подключениям. Настроить процесс деплоя (например, Docker‑контейнеры) для удобного развертывания. 9. Итог Цель: Создать RTSP‑прокси с возможностью ретрансляции потоков с камер, а также API‑сервер для управления камерами и пользователями с авторизацией на основе постоянных токенов.