Masquer le code secret du serveur appelé par Meteor Methods

Question

J'essaie de comprendre comment cacher le code secret d'un client dans Meteor Methods. The docs seem to imply que ce qui suit est un schéma général de la façon dont cela est fait. https://guide.meteor.com/structure.html#using-require

(Notez que, selon les documents, j'utilise require au lieu d'importation, puisque import ne peut pas être utilisé dans un bloc conditionnel.)

Tout d'abord, voici une méthode définie dans un fichier appelé methods.js et importés à la fois sur le client et le serveur:

/* methods.js */ 

let ServerCode 
if (Meteor.isServer) { 
    ServerCode = require('/imports/server-code.js') 
} 

Meteor.Methods({ 
    'myMethodName': function() { 
    // ... common code 
    if (Meteor.isServer) { 
     ServerCode.secretFunction() 
    } 
    // ... common code 
    } 
}) 

en second lieu, voici le code du serveur secret /imports/server-code.js que je suis en train de ne pas envoyer au client:

/* server-code.js */ 

class ServerCode { 
    secretFunction() { 
    console.log('TOP SECRET!!!!') 
    } 
} 

const ServerCodeSingleton = new ServerCode() 
module.exports = ServerCodeSingleton 

Mais quand j'examine la source envoyé vers le navigateur client, je vois toujours mon code serveur secret, être envoyé au client:

Même quand je fais une production construire, je peux encore chercher et trouver que «TOP SECRET !! chaîne. J'ai l'impression d'être trop naïf dans ma compréhension de la façon dont fonctionne require, mais les docs de Meteor le font paraître si simple. Alors, quelle est la bonne façon de cacher le code secret qui est appelé de Meteor Methods?

Answer 1

J'ai finalement compris cela je pense.

La version courte est, ignorer ce qu'il dit ici; Je crois qu'il est incorrect ou du moins trompeur:

https://guide.meteor.com/structure.html#using-require

de ce qui est dit ici à la place:

https://guide.meteor.com/security.html#secret-code

Une explication plus est: Dans un serveur de fichiers uniquement , import le code secret et attribuez-le à une variable globale. Ensuite, dans un fichier commun , utilisez isServer (ou !isSimulation) pour faire référence de manière conditionnelle à cette variable globale.

donc mon exemple original pourrait être ré-écrit comme ceci:

/* /imports/methods.js */ 

// Note: no conditional use of require this time 

Meteor.Methods({ 
    'myMethodName': function() { 
    // ... common code 
    if (Meteor.isServer) { 
     ServerCode.secret() // <-- Defined as a global outside of this file! 
    } 
    // ... common code 
    } 
}) 

Et le code secret fichier pourrait ressembler à ceci:

/* /imports/server-code.js */ 

class _ServerCode { 
    secret() { 
    console.log("Shhhhhh, I'm secret()!") 
    } 
} 
// Here's the global variable: 
SecretCode = new _SecretCode() 

Et puis dans un server- seulement fichier il pourrait ressembler à ceci:

/* /server/server-main.js */ 

import '/imports/secret-code' // <-- declare the global 
import '/imports/methods' // <-- use the global in here 

Et puis dans un fichier client seulement il pourrait ressembler à ceci:

/* /client/client-main.js */ 

import '/imports/methods' 

//... 

Meteor.call('myMethodName') 

Maintenant, le client et le serveur peuvent tous deux exécuter certains des exactement le même code dans le corps Méthode (SEC) , tandis que certains codes secrets peuvent être uniquement serveur et ne seront pas envoyés au client. C'est un peu ennuyeux d'avoir à utiliser une variable globale, mais c'est peut-être l'option la plus propre jusqu'à ce qu'une version plus fantaisiste de import prenne en charge le chargement paresseux intégré des modules.

Answer 2

EDIT: ne tient pas compte de la réponse, ne répond pas au souhait de l'opérateur de disposer du code DRY ou des mises à jour optimistes.

Par défaut, Meteor implémente un système de chargement enthousiaste en ce qui concerne les fichiers. votre methods.js en est un exemple.

Si un fichier se trouve dans un répertoire situé n'importe où dans un dossier appelé "client", ce fichier est servi uniquement au client. de même, tout fichier sous "serveur" est servi uniquement dans le dossier. C'est ainsi que vous gérez en vous assurant qu'un fichier est servi uniquement au serveur.

Comme vous l'avez découvert, la construction "Meteor.isServer" limite seulement ce qui est exécuté dans un environnement, et non ce qui y est servi.

i mettent généralement en œuvre des méthodes Meteor comme ceci:

serveur// chemin/stuff.js:

// this is only on the server 
Meteor.methods({ 
    'getStuff': function() { 
     return "stuff"; 
    } 
}); 

client// chemin/clientStuff.js:

// this is only on the client, calling the server method 
Meteor.call('stuff', function(error, result) { 
    if (error && error.reason) { 
     alert(error.reason); 
    } 
    else { 
     // use result 
    } 
}); 

En ce qui concerne exiger, pourquoi l'utilisez-vous? Je vois que vous avez du code dans/imports, que Meteor traite comme spécial et ne charge pas avec impatience. cela me dit que vous importez explicitement ce genre de choses.

OMD a des recommandations fortes pour la structure des répertoires, des modules de ES15 et comment charger le code qui ils détaillent ici:

https://guide.meteor.com/structure.html

vous remarquerez qu'ils n'utilisent pas besoin, et spécifions modules différemment de la façon dont vous le faites.