MeteorJS App Security - PullRequest
Новая
       11

MeteorJS App Security

0 голосов
/ 27 апреля 2018

Мне было немного любопытно получить отзыв о безопасности следующей структуры:

Приложение на стороне сервера Meteor (конечно, с использованием Mongo) Метеор Мобильное приложение, я так понимаю это мини-монго

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

Это моя ответственность на уровне кода ограничить то, что сохраняется в мини-клиенте клиента? Примеры:

  • Администратор команды может добавлять / редактировать / создавать пользователей. Означает ли это, что он синхронизируется с его устройством в будущем? Если пользователь изменит свой пароль, будет ли он синхронизироваться с устройством администратора команды? Я знаю, что это хэшируется, но это не главное
  • pub / sub позволил бы мне ограничить другие страницы моими данными или данными моей команды, чтобы это помогло
  • Можно ли предположить, что если я не опубликую / подпишу, данные не будут сохранены в мини-монго на клиенте?

Это может иметь ответ: Как создать тему метеора, предназначенную для конфиденциальной информации, относящейся только к серверу (клиент не может подписаться)?

1 Ответ

0 голосов
/ 27 апреля 2018

MiniMongo в основном хранит данные, которые он получает из определенных сообщений по DDP (протокол данных Метеора). Обычно данные не кэшируются локально и восстанавливаются при каждой перезагрузке страницы, если предположить, что мы говорим о гибридном мобильном приложении, отображаемом в WebView.

Вы можете просмотреть сообщения, переданные с помощью Meteor DevTools для Chrome .

Эти сообщения (added / changed / removed) обычно отправляются через систему pub / sub . На самом деле вы несете ответственность за решение , что будет отправлено. Вы имеете полный контроль над ролями и разрешениями моделирования в вашей системе, а также над тем, кто что получает в вашей публикации, поскольку публикация инициируется вызовом функции на сервере.

Общий шаблон для этого: 

Meteor.publish('someProtectedPblication', function(/*...*/) {
  if (this.userId && someCondition(this.userId) { // check for permission
    return SomeCollection.find(someData, someFields); // return a cursor that gets synced with the user
  }
  return this.ready(); // the user is not authorized to view the data
});

Когда администратор создает пользователя , я предполагаю, что это делается с помощью вызова метода Meteor, то есть RPC . Нет никаких причин для того, чтобы данные этого пользователя (не говоря уже об их хешированном пароле) были доступны администратору на стороне клиента или сохранены в его коллекции кэшированных баз данных, если вы явно не опубликуете их для него (чего я не вижу причина, чтобы когда-либо).

Я не нахожу особого смысла в использовании мутаций MiniMongo на стороне клиента (insert / update / delete) на стороне клиента, за исключением оптимистического рендеринга пользовательского интерфейса, так как я рассматриваю защиту с помощью allow/deny правила менее безопасны и более подвержены ошибкам, и я использую методы Meteor для любой мутации.

...