Skip to main content

Синхронизация с DIS: создание, удаление, обновление, сохранение данных

Бизнес-требования

От Fastboard:

  • При создании/копировании/перемещении проекта отправляем запрос в DIS на создание там источника (области + main таблицы для проекта)
  • Создаем автоматически источник в FB, связанный с этой пустой таблицей в DIS
  • У таких источников будет новый параметр link с урлом таблицы в DIS
  • Отправляем запрос на все права для пользователя-создателя проекта, а также всех админов в системе
  • При отправке запроса на все права на бэке хэшируем связку из пароля пользователя и его прав доступа, хэш передаем в DIS
  • При удалении также не забываем отправить запрос на удаление в DIS
  • При входе в диспетчер данных отдавать список не только источников, доступных пользователю, но и источников из DIS для данного проекта
  • При создании новых пользователей в FB отправлять данные о пользователях в DIS
  • В своих черновиках у пользователей автоматически есть все 3 роли для доступа

От DIS:

  • На каждый проект в FB создается пространство с как минимум одной системной таблицей
    • Таблицы в таких пространствах отличаются от таблиц в других пространствах. Они закреплены за проектом и доступны в FB в рамках этого проекта
  • Таблица становится источником этого проекта. Остальные таблицы, созданные в этом пространстве, автоматически становятся источниками этого проекта
  • FB отдает данные пользователей, имеющих доступ к формам ввода. Необходимо сохранять эти данные и проверять доступность по этим данным при попытке пользователя получить доступ к форме ввода
  • При получении информации о создании нового пользователя в FB заводить ему учетку в DIS с новым уровнем доступа – Fastboard
  • При входе пользователя с учеткой Fastboard обязательно должны быть получены:
    • Роль пользователя (текущая)
    • Хэш-пароль для подтверждения доступа и роли

Примерная структура таблицы-связки пользователей с таблицами в DIS:

  • id пользователя
  • id таблицы
  • Роль пользователя
  • Хэш-пароль для входа этого пользователя в эту таблицу с этой ролью

Решение

Синхронизация создания, изменения и удаления данных пользователей и проектов в Fastboard с системой DIS по API с использованием хэширования для повышения безопасности.

Создание и хранение hash-паролей

Системная логика (бэкенд)

Создание:

  • Новая функция для хэширования паролей для сохранения безопасности при их передаче в API DIS
  • На входе функция получает:
    • id пользователя (можно массивом)
    • id проекта (можно массивом)
    • Роль из списка (одна или несколько массивом):
      • "read" для "Просмотреть форму ввода" 
      • "write" для "Ввести данные в форму ввода"
      • "change" для "Редактировать форму ввода"
    • Пароль пользователя (можно массивом)
  • На выходе функция предоставляет hash-пароль (или массив hash-паролей), который сохраняется в системной таблице и может быть запрошен отдельным запросом

Хранение:

  • Предполагается существование отдельной таблицы-связки между пользователями и проектами
  • В таблице должны быть следующие поля:
    • id пользователя
    • id проекта
    • Роль из списка:
      • "read" для "Просмотреть форму ввода" 
      • "write" для "Ввести данные в форму ввода"
      • "change" для "Редактировать форму ввода"
    • hash-пароль

Создание/изменение пользователей

Системная логика (бэкенд)

  • Новый запрос POST {передать данные нового пользователя в DIS}.
    • Выполняется в API DIS
    • В запросе передаётся:
      • Логин созданного пользователя
    • Обязательно должна выполняться проверка на роль пользователя – вызывать такой запрос может только пользователь с ролью "Администратор системы" или "Администратор тенанта"
    • Триггер запроса – создание пользователя в Fastboard

  • Новый запрос PATCH {обновить данные пользователя в DIS}.
    • Выполняется в API DIS
    • В запросе передаётся:
      • Старый логин пользователя
      • Новый логин пользователя
    • Обязательно должна выполняться проверка на роль пользователя – вызывать такой запрос может только пользователь с ролью "Администратор системы" или "Администратор тенанта"
    • Триггер запроса – смена логина пользователя в Fastboard

Создание/копирование проектов

Системная логика (фронтенд)

    Классический

  • Привызов создании или я/копированиия проекта, в систезменений выполняе ть запрос в API Fastboard – POST {передать данные на бэкенд FB для создания пространства с таблицами в DIS}, который передаёт в себе:
    • id проекта (нового или копии)
    • Массив id пользователей:
      • создателя
      • всех пользователей-администраторов системы и администраторов тенанта, в котором создается/копируется

        этот

         проект

        • для этого выполняется запрос на бэкенд для получения списка пользователей с указанными ролями
    • Массив ролей (все из списка):
      • "read"
      • "write"
      • "change"

Системная логика (бэкенд)

  • Н

    Совый запрос POST {передать данныие нhash-паролей бэкенд FB дляпри созданияи/копировании проектов:

    • Из запространства сPOST таблицами в DIS} /api/v1/projects– (создатьние) нили POST /api/v2/admin/ops/project/create (копирование) беруются данные:
      • id проекта
      • id тенанта
    • Из вызова запиросьа вберутся тдаблицнные-связке:
      • id пользователя, создающего/копирующего проект

    • Из БД берутся данные:

      • id всех админов системы
      • id всех админов тенанта (по id тенанта)
      • Пароль пользователя, создающего/копирующего проект
      • Массив ролей (сразу все):
        • "read"
        • "write"
        • "change"
    • Для каждой связки "id проектами в– рамках FB (для доступа к источникам DIS).
      • В запросе передаётся:
        • id пользователя (можно– массивом)
        • id проекта (можно массивом)
        • Роль из списка (одна или несколько массивом):
          • "read" для "Просмотреть форму ввода" 
          • "write" для "Ввести данные в форму ввода"
          • "change" для "Редактировать форму ввода"
      • Запрос вызывает функцию создания hash-пароля
        • Для каждого указанного пользователя берется из БД его пароль и" создается нсвовый hash-пароль дли записывается кв таждой блицуникальной связки "id_пользователя – id_проекта – роль"у (количество hash-созданных запаролисей на выходе равно произведению количества id (пользователей и админов), количества id прользектователей наи количества ролей)

        Передача данных о idновом проектов на количество ролей в запросе)

        • DIS:

      • Для каждой связки "id_пользователя – id_проекта – роль" проверяется наличие записи в БД. Если запись существует, перезаписывать hash-пароль (выполнять функцию) НЕ требуется
    • На фронтенд функция ничего не возвращает
    • Триггер запроса – вызов с фронтенда
    • Новый запрос POST {передать данные в DIS для создания там нового пространства для проекта и его системной таблицы}.
      • Выполняется в API DIS
      • В запросе передаётся:
        • id проекта (нового или копии)
        • id создателя (пользователя)
        • Массив hash-парсвязолейк: для
          • id пользователя
            • для р
          • Ролейь из списка:
            • Просмотреть"read" форму ввода
            • Ввести"write" данные в форму ввода
            • Редактировать"change" форму ввода
          • Список id всех пользователей-администраторов системы и администраторов тенанта, в котором создается/копируется этот проект
          • Массив массивов hash-паролей для всех админов для ролей:
            • Просмотреть форму ввода
            • Ввести данные в форму ввода
            • Редактировать форму ввода
        • В ответ приходит массив с данными для подключения источника:
          • Название = "DIS_{Название проекта}"
          • СУБД
          • Хост
          • Порт
          • База данных
            • Логин и пароль равны логину и hash-паролю уровня "Редактировать форму ввода" пользователя-создателя
          • url пространства
        • Обязательно должна выполняться проверка на роль пользователя – вызывать такой запрос может только пользователь с возможностью создавать проекты (аналитик/разработчик/любой админ)
        • Триггер запроса – высоздание/копирование с фпроекта
      • Дантныен да илия запроса POSTсобираются {перследующим образом:
        • id проекть данные на бэкенд= FB дляid созданного/копиярованного проекта
        • В массив id пользователей входят:
          • id пользователя, создающего/копирующего проект
          • id всех пользователей, являющихся админами
          • Для каждого id пользователя собираются 3 объекта для каждой роли:
            • "read" 
            • "write" 
            • "change"
          • Для каждого объекта с id пользователя и ролью из таблицы-связки берется hash-пароль для доступа к этому проекту

      Изменения в источниках:

      • Необходимо добавить в информацию об источнике новые параметры:
        • external_link – ссылка на DIS (может быть пустой)
        • driver – добавить новое возможное значение: "dis". Логика обработки аналогична СУБД PostgreSQL. Источники с таким драйвером доступны для ВСЕХ пользователей в своём проекте
      • Необходимо модифицировать запросы POST /api/v2/admin/source (создание), GET /api/v2/admin/source/{sourceId} (получение данных источника), PUT /api/v2/admin/source/{sourceId} (обновление) параметрами:
        • external_link
        • project_id – id проекта, к которому привязан DIS-иствочник (может быть пустой)

      Создание источника с таблицамией в DIS}DIS при создании/копировании проекта:

     

 

 

МАППИНГ!!!

Удаление проектов

Получение списка источников при входе в диспетчер данных

Системная логика (фронтенд)

Классическое получение списка проектов

Back to top