Синхронизация с 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 с использованием хэширования для повышения безопасности.

Термины:

Пространство в DIS – набор системных таблиц в DIS для одного и того же проекта

Системная таблица – таблица, подключенная к конкретному проекту и служащая его формой ввода (одной из форм ввода)

Таблица-связка – таблица для реализации связей "многие-ко-многим" между двумя таблицами (как минимум с двумя внешними ключами)

Создание и хранение 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

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

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

Классический вызов создания/копирования проекта, изменений не требуется

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

Создание hash-паролей при создании/копировании проектов:

Из запроса POST /api/v1/projects (создание) или POST /api/v2/admin/ops/project/create (копирование) берутся данные:
- id проекта
- id тенанта
Из вызова запроса берутся данные:
- id пользователя, создающего/копирующего проект
Из БД берутся данные:
- id всех админов системы
- id всех админов тенанта (по id тенанта)
- Пароль пользователя, создающего/копирующего проект
- Массив ролей (сразу все):
  - "read"
  - "write"
  - "change"
Для каждой связки "id проекта – id пользователя – роль" создается свой hash-пароль и записывается в таблицу связку (количество созданных записей равно произведению количества id (пользователей и админов), количества id проектов и количества ролей)

Передача данных о новом проекте в DIS:

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

Передача данных о новой таблице проекта из DIS:

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

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

Необходимо добавить в информацию об источнике новые параметры:
- 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 при создании/копировании проекта:

Данные для подключения (credentials), id, название (name) и external_link берутся из ответа на запрос POST {передать данные в FB для создания там нового источника для системной таблицы} – из DIS. Driver = dis

Источник создается автоматически – вызывается запрос POST /api/v2/admin/source запросом POST {передать данные в FB для создания там нового источника для системной таблицы}

Связь источника с проектом:

Все источники с driver = dis должны быть связаны с конкретным проектом

Связь – "один-ко-многим": у одного проекта много системных таблиц. у каждой системной таблицы только один проект

Для этого предлагается добавить в таблицу с источниками поле для привязки к проекту (не добавлено в проект, а является формой ввода проекта)

Маппинг имеющихся проектов

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

~~МАППИ~~Н~~Г!!!~~еобходимо запустить мапперы для всех имеющихся проектов – для каждого проекта выполнить запросы:

На создание hash-паролей

На передачу данных о новом проекте в DIS

На создание источников с таблицей в DIS

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

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

При удалении проекта необходимо:

Удалить все связанные с ним DIS-источники

Удалить все записи с hash-паролями, содержащие в сеьбе id этого проекта

Отправить запрос в API DIS – DELETE {удалить все связанные формы ввода}:
- В запросе передается id проекта на удаление

При удалении источника, являющегося формой ввода в DIS (связанного с этим проектом, см. выше) необходимо отправить запрос в API DIS – DELETE {удалить форму ввода}:

В запросе передается id источника на удаление

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

Интерфейс

Новая иконка для проектов из DIS – таблица с надписью "DIS" внутри. Референс:

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

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

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

При выполнении запроса GET /api/v1/sources/list/{projectId} дополнительно передавать все источники из DIS, которые являются формами ввода данного проекта (связаны с этим проектом, см. выше) независимо от наличия у пользователя доступа к источнику.

Открытие источника DIS в диспетчере данных

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

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

При выполнении запроса GET /api/v2/source/{sourceId}/tables может прийти ошибка доступа с бэкенда. В таком случае необходимо показывать пустое окно без таблиц и выдавать всплывающую ошибку с текстом с бэкенда

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

При вызове запроса, если идет обращение к источнику с driver = dis проверять список записей в таблице-связке пользователя, вызвавшего запрос, с проектом, из которого вызван запрос:

Если найдена запись с ролью "read" или "write", то возвращаем стандартный ответ

Иначе (найдена только запись "change" или не найдено ничего) возвращаем ошибку доступа с текстом: "Для вашей роли недоступен просмотр или выбор данных из данного источника"