J'ai une application ASP.NET MVC, qui permet de télécharger la structure de la société à l'aide du fichier CSV. On m'a posé des questions sur la possibilité d'automatiser cette fonction à l'aide de Script PowerShell.Créer CSV dans PowerShell est facile, mais je n'ai pas d'idée de télécharger sur ASP.NET.
Mon premier choix était d'utiliser WebClient, mais j'ai un problème d'authentification - dans MVC, nous utilisons des formulaires authentification.J'ai lu ici que c'est possible, mais si ma formulaire de connexion change, je devrai envoyer un script mis à jour au client. Je voudrais omettre le code de mangue sur le côté du client.
La deuxième option consiste à citer le contrôleur séparé et à utiliser dans le jeton d'autorisation informatique, mais je ressemble à "inventer une roue à nouveau", car je devrais écrire tout le code responsable de l'authentification.
Puis-je améliorer l'une des options ci-dessus? Ou peut-être qu'il y a un meilleur choix?
3 Réponses :
Que diriez-vous d'utiliser un canal latéral?
Il y a deux approches. Vous l'envoyez soit sur le serveur Web du client de temps en temps, ou le serveur Web télécharge les données de votre part.
Pour l'envoi de données, FTP sur SSL devrait être suffisamment sécurisé. Voici un exemple sur la façon de commander FTP avec PowerShell. Ftp / ssl est Assez facile pour configurer pour IIS.
Pour recevoir des données, publiez simplement le CSV sur votre propre site Web. Configurez un script sur le serveur Web du client qui télécharge de temps en temps CSV de temps en temps. Si le CSV ne doit pas être accessible à personne mais que le client, nécessite un Certificat client .
Mais j'ai besoin de cette autre voie. Le client génère des CSV avec la structure de la société et la téléchargez sur mon serveur.
Hein? Juste inverser les rôles?
Comment puis-je découvrir que la société téléchargée Fichier sur FTP? Morover, je devrai créer un certificat pour chaque entreprise, créer un dossier par entreprise, etc. Il est difficile de gérer.
Je le ferais probablement comme ça:
Le problème est avec l'authentification. Https n'est que le protocole
Mon mauvais que je n'ai pas lu, devinez que vous pouvez toujours appeler wget ou quelque chose à soumettre au formulaire de connexion et à stocker le cookie afin que vous puissiez ajouter ultérieurement sur la demande, si vous souhaitez un nom de var volatil sur le client télécharge une configuration. fichier à l'avance.
Vous pourriez peut-être utiliser le service Web existant à l'aide de la cmdlet Pour la première invocation, vous spécifiez l'URL de la page de connexion et simulerait une connexion Web de formulaires en fournissant Nom d'utilisateur et mot de passe dans le Dans la deuxième requête, vous utilisez votre URL de téléchargement de données, le paramètre Bien sûr, vous devez stocker le nom d'utilisateur / mot de passe de l'automatisation à utiliser quelque part, mais c'est toujours nécessaire pour l'automatisation sans surveillance. Une approche slick éventuelle pour atténuer cela serait d'utiliser des informations d'identification basées sur le certificat client plutôt que d'une authentification de formulaire Web. Invoke-reposmethod , mais cela pourrait prendre deux invoques distincts. Pour les deux invocations, vous aurez probablement besoin de dire -method post . Il est possible de tout faire avec WebClient, mais la cmdlet peut être plus facile à décrire. Je n'ai pas vraiment essayé cela, mais cela pourrait ressembler à ceci: -Gody Paramètre et utilisation -SessionVariables Pour capturer et stocker le contexte pour effectuer la ou les demandes suivantes authentifiées. -websession pour alimenter le contexte établi par la première demande et -body télécharger votre CSV. Notez que vous avez besoin du signe du dollar sur la variable de la zone de session du second, mais pas le premier.
Je vais essayer cette solution. +1 pour l'idée
Avez-vous besoin de savoir quelle personne d'une entreprise a téléchargé un fichier? Sinon, pourquoi ne pas simplement créer une API Web HTTPS et utiliser une simple "apkeey". Fournissez à chaque entreprise un script qui a leur "apikey" et le lien API de repos, et vous êtes prêt à partir.
Pour des raisons de sécurité, je pense oui. Je pensais à la clé de l'API pour tout le monde, mais je ne suis pas sûr que si c'est une bonne idée