En tant que développeur iOS principalement, je suis très nouveau à Webdev. Je cherche à Meteor et j'ai des questions concernant le routage - mes excuses s'ils sont très faciles.
J'utilise le paquet de routeur Meteor pour créer des itinéraires, mais j'aimerais avoir des pages uniquement accessibles à l'utilisateur administrateur. . J'ai donc une simple configuration d'itinéraire comme ci-dessus, mais je ne sais pas comment restreindre l'accès à la route / administrateur. est-ce aussi simple que quelque chose comme ça? Quel serait un bon moyen de limiter la route à la page / administrateur et de montrer un avertissement ou peut-être même de les rediriger vers la page / page? Merci! client.html client.js
4 Réponses :
Utilisez le paramètre et :
Le meilleur moyen de restreindre l'accès à un itinéraire est avec le routeur lui-même (plutôt que de pousser le problème à votre contrôleur). Vous avez quelques choix dans la façon dont vous faites ceci:
Vous pouvez créer la route Je suppose que vous avez un Alternativement, vous pouvez laisser votre itinéraire d'origine et utilisez-le comme: < / p> personnellement, j'aime l'option de filtrage car il est réutilisable et c'est un peu plus évident ce qui se passe. / admin ressemble à: non autorisé un modèle (code> 403 ou quelque chose d'informatif. filtre
/ admin tel qu'il était et ajoutez un filtre:
Merci d'avoir introduit la méthode des filtres. Dans votre code ci-dessus, il serait-il possible de rediriger l'utilisateur à une partie 403 dans la partie el / code> plutôt que renvoyer "non autorisé" ?
@thinklinux pas vraiment. Techniquement, il n'est pas moyen d'empêcher un utilisateur de faire quoi que ce soit sur le client (puisqu'il peut modifier le code dans son navigateur). Le mieux que vous puissiez faire est d'ajouter des contrôles côté client comme ci-dessus et Publier uniquement les données que l'utilisateur doit être autorisée à voir (contrôlée sur le serveur) et Sécuriser votre base de données mutations (autoriser / nier / etc.). Dans le pire des cas, un utilisateur pourrait d'arriver à une page d'administration mais ne pas être capable de voir ou de faire quoi que ce soit.
@Davidweldon Je suis totalement d'accord avec vous. Mais je ne veux pas que les utilisateurs aléatoires puissent voir la page d'administrateur car, bien qu'ils ne puissent pas insérer, mettre à jour, supprimer tout ce qu'ils peuvent voir des données sensibles. Vous pouvez limiter les données publiées par l'utilisateur, mais pouvez-vous le limiter par URL aussi? Par exemple, si l'utilisateur est sur la page d'accueil, il recevra certaines données, mais s'il est sur la page Admin, le serveur ne le publiera pas. Et vous ne pensez pas que l'un 307 redirige si l'utilisateur n'est pas administrateur est plus facile à faire?
@thinklinux Cela dépend de la manière dont vous configurez vos publications. Par exemple, disons dans votre itinéraire d'administration (en supposant un routeur de fer), vous obtenez vos données d'administration avec: météor.subscribe ('documentsForAdmin') . La fonction de publication côté serveur pourrait alors valider que l'utilisateur est un administrateur avant d'envoyer les documents. De plus, votre routeur pourrait valider que l'utilisateur est en effet un administrateur avant de montrer la page. Nous pouvons faire confiance au serveur pour publier uniquement les données autorisées, mais nous ne pouvons pas faire confiance au routeur car le client aurait pu corriger son code pour permettre cela.
@Davidweldon merci! Je n'ai pas pensé à ça. Je peux faire deux fonctions publiées - une pour le client et un pour les utilisateurs d'administrateur avec différentes données où je le souhaite. Il y a mon problème :)
@Davidweldon Merci beaucoup pour cette réponse de la tienne, j'ai eu une application de météore complète moi-même et sur le point de le déployer et a été choquée de voir qu'il n'existe apparemment aucun moyen de limiter initialement l'accès aux seuls testeurs. Je suppose que nous ne pouvons pas non plus restreindre l'accès aux applications météores par IP, correct? En outre, votre solution que vous avez écrite ci-dessus s'applique aussi pour le routeur de fer aussi? Ou seulement pour le paquet de routeurs météores?
Une autre solution consiste à utiliser rôles package et assurez-vous que l'utilisateur a le rôle "administrateur" avant de servir des données. alors vous pouvez vérifier les rôles comme avec une belle syntaxe: p> Si vous souhaitez gérer des comptes (créer / supprimer des rôles et ajouter / supprimer des rôles d'un utilisateur donné) J'ai créé le package comptes admin ui . Le README a un brevet rapide et quelques notes sur la manière d'intégrer cela avec d'autres packages de routage. P> $ mrt add accounts-admin-ui-bootstrap-3
Nice, c'est la façon de le faire!
Je viens d'écrire une sorte de résumé de ce paquet. Je pense que cela devrait aider: journal.gentlenode.com/meteor-13-Maning -Utilisateur-rôles
comptes-admin-ui-bootstrap-3 est un wrapper qui fait tout cela pour vous
Tout le monde ici a fait de grands points sur la manière de protéger un panneau d'administration sur le niveau du routeur. Une autre possibilité est de sauter le routeur tous ensemble. Je l'ai récemment fait avec Meteor Candy , un package d'administrateur déposé pour Meteor.
L'idée Vous pouvez créer une dicte réactive pour contenir l'état de l'interface administrative. Si vous le placez dans un paquet, vous pouvez vous assurer qu'il ne peut jamais entrer en collision avec votre code d'application. Et avec la nouvelle fonctionnalité des importations dynamiques, vous pouvez pratiquement le garder hors du client jusqu'à ce qu'il soit nécessaire. P>
Voici comment cela pourrait fonctionner: p>
<template name="adminPanel">
{{#if show}}
{{> adminPanelUI}}
{{/if}}
</template>
AdminUI = new ReactiveDict();
Meteor.defer(function () {
Blaze.render(Template.MeteorCandy, document.body);
});
Template.adminPanel.helpers({
show: function () {
if (AdminUI.get('show')) {
return true;
}
}
})