Le site en question est site interne à l'entreprise ou je travail.
Comme l'utilisateur se connecte une première fois à l'application que je développe,
On m'a demandé à ce qu'il puisse se connecter automatiquement sur le deuxième site.
(Comme je l'avait déjà fait avec du VBA, je pensais que cela serait aussi facile)
bacelar a écrit:
Si le site autorise le "crawling", il y a de grosse chance qu'il dispose aussi d'une API dédiée aux "consultations automatiques", type REST ou autre.
C'est à dire utiliser HTTPWebRequest ? La form du second site utilise une methode Post
J'avais également essayé de faire un truc du style (que j'ai repris d'un site):
Dim Request As HttpWebRequest = CType(WebRequest.Create("https://www...."), HttpWebRequest)
Request.Method = "POST"
Dim postData As String = "UserName=***;Password=***"
Dim byteArray As Byte() = Encoding.UTF8.GetBytes(postData)
Request.ContentType = "application/x-www-form-urlencoded"
Request.ContentLength = byteArray.Length
Dim dataStream As Stream = Request.GetRequestStream()
dataStream.Write(byteArray, 0, byteArray.Length)
dataStream.Close()
Dim Response As WebResponse = Request.GetResponse()
'Console.WriteLine(((HttpWebResponse)response).StatusDescription)
dataStream = Response.GetResponseStream()
Dim Reader As StreamReader = New StreamReader(dataStream)
Dim responseFromServer As String = Reader.ReadToEnd()
MsgBox(responseFromServer)
Reader.Close()
dataStream.Close()
Response.Close()
Le problème c'est que j'obtiens une erreur "La partie connecté n'a pas répondu convenablement"
EDIT : Le Problème c'est que dans le POST envoyé il y a un élément qui s'appelle "_RequestVerificationToken" et qui change à chaque fois.
1/ Je ne comprends pas pourquoi vous n'utilisez pas une des centaines de solution de SSO qui existent. Il y en a bien au moins une qui doit correspondre à vos contraintes.
2/ J'espère que vous n'avez pas une cellule de sécurité informatique qui doit viser les développements internes. Parce que votre "solution", avec des login/password stockés en clair dans la mémoire d'un navigateur Web "lambda", c'est "no way !!!".
3/ Si vous êtes en interne, pourquoi ne pas utiliser les systèmes d'authentification des OS (Windows / Kerberos / ...) ?
4/ Pourquoi la "solution" VBA n'est pas automatiquement transposable en JS ou en .NET ???
5/ Pourquoi faire cela coté Client ???
6/ Concrètement, elle sert à quoi cette connexion Web, à part générer un cookie de Session qui ne sert à rien ? Moins de connexion => moins de code => moins de bugs
7/ Votre code à base de "HTTPWebRequest" est fragile, ne fonction que sur des sites "jouets" (authentification HTTP "Basic", sérieux !?!?) et vous ne récupérez pas les cookies (qui représente, je pense 90% des mécanismes de connexion Web), donc, très certainement, ce code sert à rien. Renseignez-vous sur les mécanismes d'authentification utilisés par le site avant d'essayer du code "au pif".
8/ Franchement, d'ici, j'ai l'impression que vos responsables sont soit complètement incompétents ou ils se foutent de vous.
EDIT: C'est très probablement faisable mais est-ce la bonne solution ? (il faut juste faire plusieurs requêtes HTTP dans le bon order et ne pas oublier les cookies.)
- Edité par bacelar 14 octobre 2020 à 11:52:43
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
1) Dans un grand groupe, il existe beaucoup d'application de gestion indépendant et concernant la mise en place d'un sso ce n'est pas moi qui décide. (je ne réalise qu'une petite application local qui à besoin de rediriger sur une autre application et de se connecter automatiquement.)
2) Justement c'est pour ne pas stocker l'id et le mdp dans la mémoire d'un navigateur web que j'essaye de me connecter de cette manière.
3) c'est une application interne au groupe, mais le groupe possède plusieurs site.
4) En VBA, j'utilisais :
Dim IE As New InternetExplorer
Dim IEDoc As HTMLDocument
Dim NumCompte As HTMLInputElement
Dim OkCmut As HTMLInputElement
Que je ne peut pas utiliser en VB.net
5) Il n'y a pas d'importance côté serveur ou client : L'httpRequest je le fait côté serveur
De plus la deuxième application est sur un autre serveur (Donc il vaut mieux ouvrir la connexion depuis le client ?)
6) Elle sert à ouvrir une deuxième application permettant de réaliser une demande d'intervention (local).
7) Pourtant j'ai déjà utilisé HTTPWebRequest avec des site HTTPS sécurisé avec TLS, et je n'ai pas besoin d'utiliser des Cookies pour garder l'id ou le password en mémoire
C'est un identifiant unique et mot de passe unique pour toutes les personnes du site donc pas besoin d'utiliser de cookies ?
1/ Ce n'est pas à vous de choisir le SSO dans un grand groupe, c'est aux architectes de l'imposer et de choisir les technologies qui lui sont compatibles. Jouez avec votre team, pas contre elle. Des applications faites dans/pour des filiales et qui doivent remonter au niveau groupe, j'en n'ai subi bien plus qu'il n'en faut. Ils sont là pour faciliter les choses. Ne faites pas le sous-marin, tôt ou tard, vous allez vous prendre une mine ou une torpille de la cellule de sécurité (ou d'un hacker s'ils font pas leur taf).
Vos réponses montrent que vous êtes un novice dans le domaine, pensez leur demander conseils.
Vous semblez facilement passer du Client au Server, c'est que vous êtes encore dans des travaux préparatoires, il est encore temps.
Bon, j'ai l'impression, aux vues des autres réponses que vous faites les choses un peu trop à l'arrache, sans consulter les autres pour vous simplifier la vie, c'est contre-productif. Il serait, par exemple, bien plus simple que vous consultiez l'équipe qui s'occupe du site Web des "demande d'intervention" pour qu'ils vous indiquent ce qui est le plus simple pour votre cas d'usage : hosting d'un navigateur comme dans le cas VBA, simulation d'un dialogue client Web - Server Web comme vous tentez très maladroitement de faire, usage d'une API dédiée qu'ils ont peut-être déjà développer et qui peuvent rapidement mettre en place, ... . La troisième serait bien plus pérenne.
2/ Le stockage dans un client lourd ne serait pas vraiment plus sûrs. Si c'est dans la partie Serveur de l'architecture, alors pourquoi s'emmerder avec tout ce fatras Web et ne pas juste utiliser directement les API Serveur, même si ce n'est que des API REST à base d'HTTP, c'est des API et pas des IHM à la con.
3/ Et ? Votre "grand groupe" est pas foutu d'avoir un annuaire commun ou faire de la fédération d'identité ? Vous prenez pas un peu vos administrateurs réseaux pour des buses, des fois ?
4/ OK, c'est du "hosting" de navigateur. Le truc le plus pourri et unsafe qui soit. C'est tout aussi possible en .NET quand VBA, mais c'est tout aussi pourri. Le code serait le même en VB.NET quand VBA ou presque, au ajout des composants COM correspondant près. Enfin, bon, ça passerait coté client, mais coté Server, uniquement si les administrateurs des plateformes applicatives sont des quiches et qui n'ont pas totalement désactivés ces passoires de sécurité que sont les navigateurs.
5/>Il n'y a pas d'importance côté serveur ou client
Alors pourquoi commencer par poster un code Javascript tout pété ??? Si vous voulez du code Javascript coté serveur, c'est avec Node.Js et pas avec .NET.
>Donc il vaut mieux ouvrir la connexion depuis le client ?
Pour que tout les systèmes de protections Web vous tombent sur le râble ???
Non !
Vous n'avez pas assez analysé le besoin.
6/ Ok, c'est beaucoup plus clair.
Maintenant, il faut connaitre le niveau d'intégration que vous voulez avoir avec cette application et le niveau de couplage que demande cette application Web. Si elle n'a pas été faite par des Mickeys, elle doit offrir une API pas juste une IHM Web. Utilisez-là, ainsi vos utilisateurs n'auront pas à sortir de votre application. Vous avez juste quelques écrans à faire à la place du site Web et lancer des requêtes vers leurs APIs le moment venu.
Si vous avez vraiment besoin de l'IHM du site, il faut se tourner vers le hosting de navigateur avec tout ce que cela implique de cauchemar de développement.
7/ HTTPS ne fait que sécuriser le tuyau de communication et rien d'autre. Pas d'authentification (sauf via certificats dans les 2 sens), ni de connexion "logiciel/applicative". Ne demandez pas à TLS de faire des choses qui n'est pas sensé faire.
Les cookies c'est pour maintenir une session entre le client et le serveur. TLS, il s'en cogne de votre session applicative.
Arrêtez de tourner en rond et contacter l'équipe du site "demande d'intervention" pour qu'il vous aiguille.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
On est d'accord ce n'est pas à moi de choisir un SOO.
bacelar a écrit:
Des applications faites dans/pour des filiales et qui doivent remonter au niveau groupe, j'en n'ai subi bien plus qu'il n'en faut.
Le problème c'est les spécificités local une applications qui fonctionne sur un site A fonctionnera totalement différemment sur un site B car les besoins, le fonctionnement, le process ne sont pas les mêmes.
bacelar a écrit:
Vos réponses montrent que vous êtes un novice dans le domaine, pensez leur demander conseils.
Je n'ai jamais dit que j'étais un expert (j'ai à peine quelque années d'expérience pro, de plus ma formation est plus généraliste qu'informaticien). Si je leurs demanderai conseil, je ne serais certainement même pas là aujourd'hui. Souvent leurs conseils c'est pas d'apporter une solution mais "ne touche a rien".
bacelar a écrit:
Bon, j'ai l'impression, aux vues des autres réponses que vous faites les choses un peu trop à l'arrache, sans consulter les autres pour vous simplifier la vie, c'est contre-productif.
Je suis loin de travailler seul, au contraire je suis plus proche des personne qui vont réellement se servir de l'application et le développe de manière à ce qui répond au mieux aux besoins.
Quand un groupe essaie de vendre une application à sa filiale avec un abonnement annuel au salaire annuel d'un ingénieur et qu'en plus l'application ne fonctionne pas sur le site en question à cause des spécificités local...
D'un autre coté je suis d'accord que c'est plus productif pour le groupe (en terme de maintenabilité, d'évolutivité, d'intégrité...) mais en contradiction avec les usines. (je pense vraiment qu'il devrais y avoir un système permettant d'ajouter des spécificité à une application global depuis le niveau local.) de rendre le développement des applications un peu plus libre mais contrôlé.
Dans l'exemple on a un banc de test dont la programmation et géré uniquement par un second site au bout du monde, chaque fois qu'il y a besoin d'une modification ça prend des mois alors que ça pourraiis être fait en 1 jour.
bacelar a écrit:
2/ Le stockage dans un client lourd ne serait pas vraiment plus sûrs. Si c'est dans la partie Serveur de l'architecture, alors pourquoi s'emmerder avec tout ce fatras Web et ne pas juste utiliser directement les API Serveur, même si ce n'est que des API REST à base d'HTTP, c'est des API et pas des IHM à la con.
Donc je recrée une interface graphique ? pourquoi ne pas réutiliser celle existantes ? surtout si elle correspond aux besoins.
bacelar a écrit:
6/ Ok, c'est beaucoup plus clair.
Si vous avez vraiment besoin de l'IHM du site, il faut se tourner vers le hosting de navigateur avec tout ce que cela implique de cauchemar de développement.
Sa m'éviterais de recréer toute l'interface
bacelar a écrit:
Les cookies c'est pour maintenir une session entre le client et le serveur. TLS, il s'en cogne de votre session applicative.
Il n'y a pas besoin de cookies si c'est un compte commun et tous le monde utilise le même identifiant et mot de passe ?
>On est d'accord ce n'est pas à moi de choisir un SOO.
On est d'accord sur cela. Mais il faut l'utiliser même pour votre application "filiale".
C'est pas ce que fait le site "demande d'intervention" ? Il devrait.
Ainsi, si vous l'utilisez, et le site aussi, il n'y aurait plus de question.
>Le problème c'est les spécificités local une applications ...
Ok, si les spécificités locales empêchent une généralisation facile, c'est bien dommage, mais cela ne vous oblige pas à ne rien utiliser de l'infrastructure centrale. Le SSO devrait être la première chose qui se fédère dans le groupe. Donc pourquoi ne pas utiliser le SSO group ?
Il vaut toujours mieux un vieux coucou qui vole qu'une navette spéciale qui ne fonctionne pas, mais c'est pas une raison pour ne pas utiliser d'ailes pour son coucou. (heu, un peu Cantona Inside ?)
>Si je leurs demanderai conseil, je ne serais certainement même pas là aujourd'hui.
Vous avez peur de quoi ?
Ils ont des informations que nous n'aurons jamais.
Il faut commencer par-là, et pas par les forum, jamais.
Si vous avez des difficultés avec les solutions qu'ils proposent, là, on peut vous aider.
>au contraire je suis plus proche des personne qui vont réellement se servir de l'application
C'est très bien. Une vieille pétoire qui correspond aux besoins c'est toujours mieux qu'un sabre laser, quand on n'est pas Jedi.
Mais ici, ce n'est pas un problème d'utilisateurs finaux mais c'est comment bien s'intégrer dans le système informatique existant.
Prenez juste la peine de demander à l'équipe du site "demande d'intervention" ce qu'ils ont prévu pour votre cas d'utilisation.
Mais j'ai l'impression que vous n'avez pas encore analysé cet usage : se connecter à un site n'est jamais un but en soi.
>je pense vraiment qu'il devrais y avoir un système permettant d'ajouter des spécificité à une application global depuis le niveau local.
Ça, c'est dans un monde parfait. Généralement, c'est dans l'autre sens que cela se passe. On implémente un truc tout moisi dans un coin et c'est la structure centrale qui pique l'idée ( ou on lui impose de faire rentrer ce truc tout pourri dans les cases, ou encore c'est un copain de partie de golf du vendredi après-midi qui a vendu au cher PDG/DSI une solution "qu'elle est géniale").
La présence d'un "_RequestVerificationToken" et autres joyeusetés montre qu'il y a des mécanismes anti-bots sur le site "demande d'intervention". Qu'ils y soient d'une manière volontaire ou pas (beaucoup de framework Web ont ce genre de fonctionnalité "de base"), ça ne change rien.
Vous devez coopérer avec l'équipe du site "demande d'intervention" pour qu'ils ne vous mettent pas des bâtons dans les roues. Vous avez normalement autre chose à faire que de hackers leurs défenses (même involontaires).
2/Donc je recrée une interface graphique ?
Faudrait quand même savoir, c'est coté serveur ou coté client que vous travaillez ???
Si c'est coté serveur, clairement, une IHM est une totale nuisance et on ne doit utiliser que les API, si possible.
Je le répète, vérifiez avec l'équipe du site "demande d'intervention" l'existence de ces API ou comment passer outre l'IHM.
Si vous êtes du coté serveur et que vous n'avez aucun interaction entre votre application et le site autre que de lancer un navigateur sur celui-ci, alors, le plus simple, c'est que le site génère un cookie permanent qu'il récupérera dès que votre application lance le navigateur sur ce site, et cela sans aucun code de votre part.
Là encore, la meilleure solution n'est pas dans votre code mais dans la coopération entre les équipes.
>Il n'y a pas besoin de cookies si c'est un compte commun
On n'en revient toujours au même, c'est fonction de comment le site gère l'authentification mais 90 à 99% des cas c'est via une session coté serveur qui utilise majoritairement les cookies pour la "transmettre" au client.
Si votre problème, c'est de lancer un navigateur sur une page Web et que l'utilisateur (même de service) soit automatiquement renseigné, c'est soit via un SSO groupe ou un cookie permanents venant du site qu'il faut se tourner. Le reste, c'est du bricolage sans l'aide du site cible.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
ASP / VB.NET - ouvrir une page web et login
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Site Internet : https://devst.go.yj.fr
Site Internet : https://devst.go.yj.fr
Site Internet : https://devst.go.yj.fr
Site Internet : https://devst.go.yj.fr
Site Internet : https://devst.go.yj.fr