GunDB аутентификация пользователей и хранение данных среди пользователей

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

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

Я искал Gun, поскольку он позволяет лучше использовать приложение в смысле совместной работы. Однако у меня есть следующие вопросы:

Аутентификация пользователя

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

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

Хранилище данных

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

Что меня интересует, так это то, какие данные на самом деле хранятся на клиенте? Это только те данные, к которым он / она имеет доступ, или это копия всего набора данных, к которому клиент может получить доступ только к тому, к чему у него / нее есть доступ?

Сохранение ваших данных

Когда у меня будет производственная система, работающая с большим количеством данных, как я смогу управлять своими потоками данных и / или помогать своим клиентам в решении проблем, возникающих в системе?

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

Моя главная задача - правильно синхронизировать их локальное хранилище.

Это все мои вопросы на данный момент.

Заранее большое спасибо за разъяснение этих вопросов.

С наилучшими пожеланиями,

Источник

1 ответ

(Ответ Марк Надаль на Github: https://github.com/amark/gun/issues/398)

@ рад слышать от тебя! Спасибо, что, наконец, прыгнул в обсуждение!:D

Аутентификация пользователя,

это в настоящее время в альфа. Если вы еще не видели эти ссылки, проверьте их:

Если вы уже это сделали, хотели бы (А) провести альфа-тестирование и помочь продвинуться вперед или (Б) услышать любые конкретные вопросы, которые у вас есть по этому поводу. Этот поток также является более подробным обсуждением альтернативных идей безопасности API: #321 .

Хранилище данных.

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

Это делает данные небезопасными? Нет, шифрование должно обеспечивать его безопасность, даже если кто-то / все хранит его, шифрование делает его безопасным. (См. [Вставить ссылку на (1)] для получения дополнительной информации).

Техническое обслуживание.

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

Источник
Другие вопросы по тегам