Разделение пользовательских данных DocumentDb

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

Я предполагаю, что грубый дизайн будет:

  • Аутентифицировать пользователя и создать новый/получить существующий идентификатор пользователя
  • При вставке документа введите идентификатор пользователя в документ.
  • При чтении документа/коллекции документов запрос, где идентификатор пользователя документа = текущий идентификатор пользователя

Я создаю приложение AngularJs и в настоящее время использую базу данных Azure Sql в сочетании с мобильными службами Azure.

Мобильные службы обрабатывают аутентификацию пользователя, а также сегрегацию пользовательских данных на стороне сервера с помощью функций javascript сценария данных:

e.g.

function insert(item, user, request) {
  item.userId = user.userId;
  request.execute();
}

Любые предложения о том, как можно безопасно отделить пользовательские данные от AngularJS с помощью DocumentDB?


person j3r3m7    schedule 04.09.2014    source источник
comment
Так что пенни просто упал на то, как это должно быть реализовано. Мобильные службы Azure используют Express для предоставления как встроенного API для Sql, так и функций пользовательского API. Таким образом, очевидным путем будет написать собственный API с использованием js, который использует Express для доступа к DocumentDB под учетными данными пользователя, прошедшего проверку подлинности Azure. Когда у меня будет работающий источник, я отвечу на свой вопрос и опубликую здесь.   -  person j3r3m7    schedule 08.09.2014


Ответы (1)


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

Как правило, я бы относился к DocumentDB так же, как вы относитесь к любому другому хранилищу данных. Ваш клиент (AngularJS) звонит в вашу серверную службу, а не напрямую в ваше хранилище данных. Серверная часть проверяет запрос клиента (т. е. утверждает, что пользователь прошел проверку подлинности и может касаться определенной части данных), прежде чем делегировать какую-либо работу вашему хранилищу данных.

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

Ознакомьтесь с этой записью блога о пользователях и разрешениях DocumentDB: http://blogs.msdn.com/b/cloud_solution_architect/archive/2014/12/09/permissions-in-azure-documentdb.aspx

person Andrew Liu    schedule 04.09.2014
comment
Привет, спасибо за ответ. Да, я ищу недостающий бит серверной службы. С мобильными службами вы получаете их бесплатно для грубых данных в таблицах Sql. Возможно, на данный момент было бы уместно создать пользовательские конечные точки API в мобильной службе, а затем преобразовать их позже, если Microsoft предоставит встроенные операции. - person j3r3m7; 05.09.2014
comment
Знаете... Мне бы очень хотелось, чтобы в мобильные службы Azure была добавлена ​​поддержка DocumentDB! Вы можете проголосовать за поддержку DocumentDB на форуме обратной связи Azure Mobile Services: feedback.azure.com/forums/216254-mobile-services/suggestions/ - person Andrew Liu; 05.09.2014