Comment sécuriser l'API MongoDB côté client ?

Question

Je ne veux pas que tous mes utilisateurs puissent insérer/détruire des données.

Answer 1

Bien qu'il n'y ait pas encore de moyen documenté de faire cela, voici un code qui devrait faire ce que vous voulez :

Foo = new Meteor.Collection("foo");
...
if (Meteor.is_server) {
   Meteor.startup(function () {
       Meteor.default_server.method_handlers['/foo/insert'] = function () {};
       Meteor.default_server.method_handlers['/foo/update'] = function () {};
       Meteor.default_server.method_handlers['/foo/remove'] = function () {};
   });
}

Cela désactivera les méthodes d'insertion/mise à jour/suppression par défaut. Les clients peuvent essayer d'insérer dans la base de données, mais le serveur ne fera rien, et le client remarquera et supprimera l'élément créé localement lorsque le serveur répondra.

insérer/mettre à jour/supprimer fonctionnera toujours sur le serveur. Vous devrez créer des méthodes avec Meteor.methods qui s'exécutent sur le serveur pour effectuer les écritures dans la base de données.

Tout cela va changer lorsque la branche de l'authentification débarquera. Dès lors, vous serez en mesure de fournir des validateurs pour inspecter et autoriser les écritures de la base de données sur le serveur. Voici un peu plus de détails : http://news.ycombinator.com/item?id=3825063

Answer 2

[MISE À JOUR] Il existe désormais un paquet Auth officiel et documenté qui fournit différentes solutions pour sécuriser une collection.

Au niveau CRUD :

[Serveur] collection.allow(options) et collection.deny(options). Restreint les méthodes d'écriture par défaut sur cette collection. Lorsque l'une de ces options est appelée sur une collection, toutes les méthodes d'écriture sur cette collection sont restreintes, quel que soit le paquetage non sécurisé.

Et il y a aussi insecure pour supprimer l'accès complet en écriture du client.

source : Démarrer avec Auth (merci à @dan-dascalescu)

---

[ANCIENNE RÉPONSE]

Apparemment, des travaux sont en cours sur un paquet Auth( ?) qui devrait éviter que des utilisateurs prennent le contrôle total de la base de données telle qu'elle est actuellement. Il y a aussi quelqu'un qui suggère qu'il y a une solution existante (solution de contournement) en définissant vos propres mutations (méthodes) et en les faisant échouer si elles tentent d'effectuer une action non autorisée. Je n'ai pas mieux compris mais je pense que cela sera souvent nécessaire car je doute que le Paquet Auth permette d'implémenter la logique d'authentification habituelle au niveau de la ligne mais probablement seulement sur les méthodes CRUD. Il faudra voir ce que les développeurs ont à dire.

[EDIT] J'ai trouvé quelque chose qui semble confirmer mes pensées :

Actuellement, le client a un accès complet en écriture à la collection. Il peut exécuter des commandes arbitraires de mise à jour de Mongo. Une fois que nous aurons mis en place l'authentification, vous serez en mesure de limiter l'accès direct du client à l'insertion, la mise à jour et la suppression. Nous envisageons également des validateurs et d'autres fonctionnalités de type ORM.

Sources de cette réponse :

Accéder à la base de données du côté client comme du côté serveur avec meteor

https://stackoverflow.com/questions/10100813/data-validation-and-security-in-meteor/10101516#10101516

Answer 3

Une façon plus succincte :

_.each(['collection1', 'collection2'], function(collection){
    _.each(['insert','update', 'remove'], function(method){
      Meteor.default_server.method_handlers['/' + collection + '/' + method] = function(){}
    });
});

ou pour le rendre plus idiomatique :

étendre le météore :

_.extend(Meteor.Collection.prototype, {
  remove_client_access: function(methods){
    var self = this;
    if(!methods) methods = ['insert','update','remove'];
    if(typeof methods === 'String') methods = [methods];
    _.each(methods, function(method){
      Meteor.default_server.method_handlers[self._prefix + method] = function(){}
    });
  }
});

Les appels sont plus simples :

List.remove_client_access() // restrict all
List.remove_client_access('remove') //restrict one
List.remove_client_access(['remove','update']) //restrict more than one

Answer 4

Je suis nouveau dans le domaine de Meteor, mais ce que j'ai rencontré jusqu'à présent sont ces deux points

1. Vous pouvez limiter ce à quoi un client peut accéder dans la base de données en ajoutant des paramètres à l'option find dans le serveur publish commande. Ensuite, lorsque le client appelle Collection.find({}) les résultats qui sont renvoyés correspondent à ce que serait, par exemple, le côté serveur, Collection.find({user: this.userId}) (voir aussi Publier certaines informations pour Meteor.users et plus d'informations pour Meteor.user et http://docs.meteor.com/#meteor_publish )

2. Une chose qui est intégrée (j'ai meteor 0.5.9) est que le client peut seulement update les éléments par id, sans utiliser de sélecteurs. Une erreur est enregistrée dans la console du client en cas de tentative non conforme. 403: "Not permitted. Untrusted code may only update documents by ID." (voir Comprendre "Non autorisé. Le code non fiable peut seulement mettre à jour les documents par ID." Erreur Meteor ).

Compte tenu du point 2, vous devez utiliser Meteor.methods du côté du serveur pour mettre les appels de procédure à distance à la disposition du client avec Meteor.call .