Метод Meteor против deny/allow

В Meteor, когда я предпочитаю method над правилом deny?

Мне кажется, что правила allow/deny должны быть одобрены, поскольку их цель более ясна, и каждый знает, где их искать.

Однако в книге Discover Meteor предотвращение дублирования вставки ( "дубликат", определяемый как добавление документа, свойство url уже определено в каком-либо другом документе той же коллекции), как говорят, должно определяться посредством метод (и оставленный как упражнение для читателя, глава 8.3).

Я думаю, что могу выполнить эту проверку способом, который я нахожу гораздо яснее:

Posts.deny({
    update: function(userId, post, fieldNames, modifier) {
        return Posts.findOne({ url: modifier.$set.url, _id: { $ne: post._id } });
    }
});

(N.B., если вы знаете пример, да, я добровольно отказался от того, что "только подмножество атрибутов изменено" проверьте, чтобы вопрос был более конкретным.)

Я понимаю, что есть другие операторы обновления, чем $set в Mongo, но они выглядят типизированными, и я не хочу оставлять открытое отверстие безопасности.

Итак: есть ли недостатки в моем правиле deny? Независимо, должен ли я одобрить метод? Что я получу от этого? Что я проиграю?

Ответы

Ответ 1

Обычно я стараюсь избегать субъективных ответов, но это действительно важные дебаты. Сначала я бы рекомендовал прочитать Meteor Methods vs Client-Side Operations из блога Discover Meteor. Обратите внимание, что в Edthena мы исключительно используем методы по причинам, которые должны стать очевидными.

Методы

про

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

  • Каждый метод является единственным источником правды в вашем приложении. Если вы создаете метод posts.insert, вы можете легко убедиться, что это единственный способ в вашем приложении вставить сообщения.

против

  • Методы требуют императивного стиля, и они имеют тенденцию быть подробными в отношении количества проверок, необходимых для операции.

Операции на стороне клиента

про

  • allow/deny имеет простой декларативный стиль.

против

  • Проверка схемы и разрешений на операцию update бесконечно тяжелая. Если вам нужно обеспечить соблюдение схемы, вам потребуется использовать внешнюю библиотеку, например collection2. Только эта причина должна дать вам паузу.

  • Модификации могут распространяться по всему вашему приложению. Поэтому может быть сложно определить, почему произошла конкретная операция базы данных.

Резюме

По-моему, allow/deny более эстетично, однако фундаментальная слабость заключается в обеспечении прав доступа (особенно в отношении обновлений). Я бы рекомендовал операции на стороне клиента в случаях, когда:

  • Ваша кодовая база относительно невелика, поэтому легко grep для всех экземпляров, где имеет место конкретный модификатор.

  • У вас мало разработчиков, поэтому вам не нужно все соглашаться с тем, что есть один и только один способ вставки в коллекцию X.

  • У вас есть простые правила разрешения - например. только владелец документа может изменить любой его аспект.

На мой взгляд, использование клиентских операций является разумным выбором при создании для замены allow/deny с помощью методов insert/update/remove.

обновление 6/1/16

Указатель метеора принимает положение, в котором allow/deny следует избегать.