Je construis une API de repos pour un site Web DotNetNuke 6, faisant appel à la structure des services basée sur MVC de DNN. Cependant, je n'ai aucun arrière-plan dans l'authentification, je ne suis même pas sûr de savoir où commencer.
Fondamentalement, nous voulons que nos clients puissent faire des demandes d'obtention des données de leur portail et que nous voulons des clients ( Mais pas tous) Pour pouvoir poster des mises à jour simples sur leurs données utilisateur. P>
J'essaie de rechercher des informations, mais que je ne suis pas sûr de ce que je cherche. DNN a des connexions et des rôles différentes, mais je ne suis pas sûr que si ou comment ils sont en compte. J'ai entendu parler de choses comme Oauth mais que je comprends bien cela est au niveau le plus fondamental. Je ne sais pas si c'est ce dont j'ai besoin ou non et si ou si vous appliquez à DNN. Quelqu'un peut-il me dire dans la bonne direction? P>
J'ai créé un module uniquement pour ce service, et j'ai ajouté deux autorisations spéciales pour cela: "Apiget" et "APIPOST". Je les ai attribués à certains rôles de test / comptes de test dans DNN. J'ai écrit un attribut d'autorisation personnalisé qui, étant donné l'ID de module, vérifie si l'utilisateur actuel a la permission nécessaire (par des rôles ou directement). Autant que je puisse dire, l'identifiant de l'onglet est sans importance dans mon cas. P> Il semble fonctionner à la fois avec un navigateur Web (basé sur le compte DNN, je suis connecté) et avec un script PHP que Envoie une demande HTTP avec un nom d'utilisateur / mot de passe de compte. p> L'attribut Authorize: p> Le contrôleur:
("MyTest" est le point final pour obtenir et poster) p>
4 Réponses :
Le cadre de services dans DNN est ce que vous êtes après. Il vous permet de fournir une API de repos qui se branche directement dans la sécurité DNN. P>
Voici quelques articles pour vous aider à démarrer: P>
Note, il y a une différence dans DNN 6 et DNN 7 lors de l'utilisation du cadre de services: P>
La manière principale que vous attachez un service dans le cadre de services DNN dans les autorisations DNN consiste à associer les autorisations avec une instance de module. C'est-à-dire que vous aurez besoin d'utilisateurs de votre service pour identifier quel module d'appel entre / environ (en envoyant un moduleID et TABID dans la demande [en-têtes, une chaîne de requête, des cookies, formulaire]), vous pouvez alors indiquer quelles autorisations Ils ont besoin de ce module pour prendre une action particulière sur le service. P>
Vous pouvez utiliser l'attribut Vous voudrez également ajouter l'attribut Si vous n'avez pas de module qui associe naturellement ses autorisations avec votre service, vous pouvez en créer un seul à cet effet, seuls à s'exposer comme un utilitaire de gestion des autorisations. P>
Une fois que vous avez compris la pièce d'autorisation ci-dessus, DNN prendra soin de l'authentification à l'aide de vos formulaires Cookie (c'est-à-dire des scénarios AJAX, ou via l'authentification de base ou de la digère (pour les scénarios de non-Ajax). Cela dit, si vous faites non-Ajax, vous devrez déterminer un moyen de valider le jeton anti-falsification uniquement lorsqu'il s'applique. P> prise en charge code> de votre service et transmettre une liste délimitée par des virgules de noms de module, afin de vous assurer que seuls vos propres modules sont autorisés. Ensuite, ajoutez l'attribut code> dnnmoduleautoriser code> au niveau du service ou de l'action individuelle pour indiquer quelle autorisation à l'utilisateur a besoin sur ce module. Dans votre cas, vous pouvez également ajouter l'attribut
allowanonymous code> sur les actions code> Obtenir CODE> Actions et avoir un
dnnmoduleautoriser code> sur le service, pour le
Publier code> méthodes (et autre chose). Notez que vous ne pouvez pas mettre l'attribut
allowanonymous code> sur le contrôleur; Il remplacera les autorisations mises à l'action, ce qui rendra impossible de rendre des actions plus restrictives. P>
validateantantIforgeryToken code> sur le
POST CODE> Actions, pour protéger contre les attaques CSRF. P>
J'ai compris comment écrire un module DNN avec des autorisations personnalisées. Mais je suis nouveau à DNN et je ne suis toujours pas clair sur la manière dont nos clients seront authentifiés lors de la connexion de manière programmatique à l'API et de la manière dont cela passe avec le module. Je n'ai aucune idée où Ajax entre en jeu. Pourriez-vous être plus précis?
Le exemple de projets code> dans github.com/bdukes/ Concevoir-a-mobile-activation-API a un module et une application Windows Phone
Je voulais juste noter que l'attribut DnnmoduleAuthorize prend un paramètre PermisKey pour des autorisations personnalisées afin que vous puissiez faire des choses comme ceci: On ne semble pas fournir votre propre message d'erreur Avec cela, vous pouvez donc envelopper votre corps de méthode comme ça et laisser l'attribut permission personnalisé: p>
Je voulais juste ajouter à @Richards Commentaire pour utiliser le L'attribut complet doit être: p> le quitter vide ne fait rien comme indiqué ici ici: https://github.com/dnnsoftware/Dnn.Platform/blob/f4a5924c7cc8226cfe79bbc92357ec1a32165ada/DNN%20Platform/ Bibliothèque / Sécurité / Autorisations / PermissionProvider.cs # L810 P> P> [dnnmoduleautorize (permissionkey = "deletedata")] code> pour les autorisations personnalisées.
Intéressant que vous devez passer accesslevel = Modifier, pour faire fonctionner la permission, je suppose que la permission de Permisky devrait fonctionner seul, peut être DNN besoin de l'améliorer
Vérifiez que cela pourrait être utile Stackoverflow.com/Questtions/12222527 / ...