9
votes

Accéder à la fonction.Caller sur NODEJS

J'ai une tâche qui dépend de la fonction.Caller à la santé de la mentale qu'un appelant est autorisé.

Selon cette URL, l'appelant est pris en charge dans tous les grands navigateurs ... et tous mes tests de l'unité passent:

https: //developer.mozilla. org / fr-nous / docs / web / javascript / référence / global_objects / fonction / appelant

Cependant, Nodejs rejette toutes les tentatives d'accès à la fonction.Caller (le rapporte comme null).

Je suis ouvert aux suggestions pour faire ce travail sur Nodejs ... Je détesterais que ce cadre ne fonctionne que sur les navigateurs.

Merci!


8 commentaires

Non, n'utilisez pas fonction.Caller , il est obsolète pour des raisons bien connues. Et n'essayez pas de fonder des contrôles de santé de santé ou des «autorisations» sur cette propriété. Qu'essayez-vous d'empêcher en fait ?


Qu'est-ce que j'essaie d'empêcher? Essayer d'utiliser l'objet.defineProperty Setters / getters tels qu'ils bloquent l'accès aux propriétés que nous définissons comme privés. Ils ne devraient être accessibles que si accédez à une méthode de l'objet. Nous vérifions donc la fonction.Caller et comparez-la à notre liste des méthodes d'objet enregistrées et permettent l'accès à la propriété si l'appelant est une méthode d'objet enregistrée. Fondamentalement, un cadre d'application des propriétés publiques / privées telles que les propriétés publiques et privées de Java. (Et ça marche - sauf pour échouer dans Nodejs, Phantomjs, Jenkins, etc ...)


N'essayez pas. JavaScript n'est pas Java, accepte cela. Vous n'obtenez pas de sécurité à travers cela, et je parierais qu'il ne rend pas votre code plus utilisable ou plus rapide.


Bergi, vos deux points sont valides. Mais je ne serais pas un ingénieur si je ne voulais pas voir si cela pourrait être fait. :-) Et pour certains cas d'utilisation, il peut s'agir d'un compromis souhaitable. De toute évidence, ce n'est pas une solution pour les cas d'utilisation normale. Cela en est moins sur la sécurité pure et plus sur la conservation des développeurs d'une chaussette avec des trucs avec des trucs, ils ne devraient pas avoir avec désinvolture.


Pourquoi ne pouvez-vous pas simplement utiliser Variables locales standard avec des méthodes privilégiées ? Ou souligner les noms de propriété? À des fins académiques, vous voudrez peut-être consulter ces idées . L'utilisation d'un «cadre» entier rendra probablement vos cours plutôt lents, j'éviterais une telle production.


si (ceci! == cela) jette une nouvelle erreur ("mauvaise manière");


ou si (! (cette instanceof Classfunction)) lancer une nouvelle erreur ("mauvaise manière");


Cette solution ici semble fonctionner bien: Stackoverflow.com/Questtions/16697791/...


4 Réponses :


-3
votes

Vous pouvez utiliser arguments.callee.caller code> pour faire référence à l'appelant. Cependant, je crois que c'est (toujours) obsolète (bien que son élimination éventuelle puisse causer un problème pour certains cas, voir Ici pour cette discussion) et vous manquez également sur certaines optimisations de compilateur / interprète.

Exemple: P>

function foo() {
  bar();
}

function bar() {
  console.log(arguments.callee.caller.name);
}

foo();

// outputs: foo


5 commentaires

Oui; En essayant de résoudre ce problème, j'ai vu et essayé des arguments.Callee.caller; Également non pris en charge dans Nodejs.


-1. bar.caller === arguments.callee.caller est ce que l'OP utilise déjà, et il dit qu'il ne fonctionne pas. En utilisant arguments.callee ne fait que le pire, en fait.


@ user2094063 L'exemple que j'ai donné des œuvres pour moi dans le nœud v0.10.x et v0.11.x.


Bonjour, certaines informations supplémentaires; Idemsepoke dans mon message d'origine: l'appelant est disponible en nœudjs, mais n'est pas disponible pour accéder à l'appelant lors de l'utilisation d'un option.defineProperty Setter / getter!


@Michael Voir ma réponse ci-dessous. J'ai fourni une solution de contournement pour Nodejs



0
votes

Parce que fonctionner.caller fonctionne dans Nodejs, mais échoue lorsque combiné avec Object.defineProperty Getters / Setters, je vais considérer cela un bogue dans Nodejs, plutôt qu'un choix de NodeJs de ne pas prendre en charge la fonction.Caller. < / p>


0 commentaires

14
votes

Le package NPM de l'appelant-ID le rend aussi simple que PIE: https: //www.npmjs .com / colis / appelant-id de la DOCS:

var callerId = require('caller-id');

// 1. Function calling another function
function foo() {
    bar();
}
function bar() {
    var caller = callerId.getData();
    /*
    caller = {
        typeName: 'Object',
        functionName: 'foo',
        filePath: '/path/of/this/file.js',
        lineNumber: 5,
        topLevelFlag: true,
        nativeFlag: false,
        evalFlag: false
    }
    */
}


3 commentaires

Soyez conscient que si vous utilisez cette solution, vous ne devez pas l'utiliser dans un chemin de code à chaud, car les performances ne seront pas ce à quoi vous pourriez vous attendre (ce module génère (la partie coûteuse) et analyse des traces de pile). De plus, ce module n'est pas un remplacement complet de .caller car il ne vous fait pas référence à la fonction d'appelant réelle .


N'a pas fonctionné pour moi (sur Nodejs). A montré le nom de fichier du paquet lui-même. Cette solution a fonctionné ici bien: Stackoverflow. com / questions / 16697791 / ...


J'ai fait un coup d'œil rapide au code source de ce module 3D-Parti, il utilise la fonction.Caller derrière les scènes pour vous, cela ne résout rien, car la fonction.caller est obsolète. Voir: Github.com/pixelsandbytes/caller-id/ blob / maître / lib / ...



0
votes

Je suis plutôt en retard à cette fête mais j'essayais également d'utiliser des arguments.caller et après beaucoup d'essais et d'erreurs, il est possible si vous utilisez un prototype.

Cela ne fonctionne pas: < Pré> xxx

mais à l'aide de prototype à la place, il fait:

classe myClass {

} xxx > Ceci est fonctionnellement identique. Je n'ai aucune idée de la raison pour laquelle on est empêché par le nœud et l'autre n'est pas, mais il s'agit d'une solution de contournement de travail dans le nœud 6.0.


0 commentaires