Discussion :

[Pierre Fauconnier]

Et si vous ajoutez (.*?)/ devant api/v1/(.*) ?

Le test de la regexp fonctionne, donc je reste persuadé que ce n'est pas à ce niveau que ça joue. Je ne suis pas un grand spécialiste des regexp mais je pense que la réécriture est correcte. C'est soit dans la config du proxy, soit plus probablement dans ma façon d'interroger le site au travers du proxy grâce à httprequest. Je pense vraiment que c'est à ce niveau que ça bloque.

[Pierre Fauconnier]

C'était l'image d'un autre essai

Par contre, je me trompe peut-être en envoyant l'adresse au httprequest. J'envoie http://172.xx.xxx.x:2100/api/v1/customers , mais je dois peut-être entré l'adresse du site créé sur IIS. Le problème, c'est que c'est local et qu'il n'accepte pas l'adresse que je lui donne. Je dois lui donner une adresse http mais je ne vois pas quoi lui donner pour le site créé. J'ai essayé http://localhost:84/api/v1/customers sans succès (le site est sur le port 84).

[Incorporated]

C'était l'image d'un autre essai

Par contre, je me trompe peut-être en envoyant l'adresse au httprequest. J'envoie http://172.xx.xxx.x:2100/api/v1/customers , mais je dois peut-être entré l'adresse du site créé sur IIS. Le problème, c'est que c'est local et qu'il n'accepte pas l'adresse que je lui donne. Je dois lui donner une adresse http mais je ne vois pas quoi lui donner pour le site créé. J'ai essayé http://localhost:84/api/v1/customers sans succès (le site est sur le port 84).

Sur votre IIS, vous avez bien créer un site web avec un nom ? et bien essayer de requêter le http de ce nom. Par exemple http://mycompany (si c'est ce nom que vous avez choisi pour votre site web local)

Et je vois que vous avez mis :84, vous avez mis votre serveur local sur le port 84 ?

[Pierre Fauconnier]

Ca ne fonctionne pas

Par défaut, un site web est créé dans iis (son nom est Default Web site sur le port 80). Son "adresse" n'est évidemment pas son nom, vu les espaces. Via un explorateur internet, je n'arrive pas à me connecter sur ce site, je dois passer par file:///c:\intepub\wwwroot\index.html. Par exemple, http://localhost:80/index.html me renvoie une erreur 502.3 Bad Gateway.

J'ai exactement le même problème avec le "site" créé pour mon client. file:///C:/inetpub/fiduciaire2001/index.html fonctionne et m'affiche bien la page index.html, mais si j'essaie http://localhost:84/index.html, j'arrive à l'erreur 502.3. L'url demandée est "correcte", le chemin d'accès physique est correct (c:\inetpub\monclient\index.html) mais ça reste une erreur. Je suis vraiment à court d'idées, mais ce n'est clairement pas mon core business

[Incorporated]

Vous avez le raccourci vers votre site présent sur le côté droit :



Est-ce qu'en cliquant dessus, vous tomber sur le même résultat ?

[Pierre Fauconnier]

Oui, c'est la même erreur, que ce soit pour le site par défaut ou pour celui que j'ai créé.

Bien entendu, le serveur WEB est démarré ainsi que les sites. Pour être sûr, j'ai arrêté le service puis l'ai redémarré ainsi que les sites, et c'est toujours le même problème.

EDIT:

En arrêtant puis en redémarrant le serveur, ça fonctionne avec le raccourci sur la droite: http://localhost:84 fonctionne également.

Par contre, la requête httprequest renvoie maintenant une erreur 404.

Je quitte pour +/- 1 heure. Je referai des tests à tête reposée tout à l'heure.

MERCI pour ton acharnement

[Incorporated]

Le fait que vous ayez le "Default Web Site" ne me paraît pas conforme à la procédure :



Vous devriez donc avoir un nom de site web local que vous avez créé.

[Pierre Fauconnier]

J'ai les deux: Default Web Site (sur le port 80) créé par IIS au moment de l'installation, je suppose, et le site que j'ai créé sur le port 84. Les deux sont fontionnels (leur chemin d'accès dans le panneau de droite fonctionne et http://localhost:80 et http://localhost:84 dans l'explorateur permettent d'afficher la page d'accueil de chaque site.




A ce stade, je pense donc que le problème de l'installation est réglé, et qu'il reste maintenant à utiliser le httprequest en VBA en utilisant la bonne adresse et en configurant correctement la connexion au Proxy du httprequest.

A ce stade, je n'ai pas encore trouvé de doc utile.

[Incorporated]

Oui la configuration semble bonne.

Est-ce que vous êtes bien redirigé vers le site web en 172.XX.XX.XX ??

Vous pouvez peut-être partager votre code VBA ?

[Pierre Fauconnier]

Voici le code:

C'est le code d'acquisition du texte json du token qui permettra de requêter par la suite. C'est en réponse au Send que je reçois l'erreur 404

Code VBA :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
Function getTokenSource(Url As String, Key As String) As String
  Dim w As New WinHttp.WinHttpRequest
 
  On Error GoTo Catch
  w.Open "GET", Url & "/api/v1/token/" & Key, False
  w.SetRequestHeader "content-type", "application/x-www-form-urlencoded; charset=ISO-8859-1"
  w.SetProxy 2, "localhost:84", ""
  w.Send
  getTokenSource = w.ResponseText
 
Catch:
  If Err.Number <> 0 Then Err.Raise Err.Number, "dal.getTokenSource", Err.Description
End Function

[Incorporated]

Je suis loin d'être un expert en code mais je vais continuer d'essayer de vous aider.

Lorsque vous requêter habituellement ce site, est-ce que vous avez besoin de credential ? peut-être que c'est une piste à explorer.

Et vu que votre IIS est devenu un "proxy", est-ce que la configuration proxy dans le code VBA est nécessaire ? vu que vous requêter votre site local, c'est lui qui se charge de faire la redirection.

[Pierre Fauconnier]

Je précise que le code est fonctionnel. J'ai une connexion sur le site de tests du prestataire, qui ne requiert pas de proxy et je récupère les données sans soucis. Je viens de retester en basculant sur les données de test et je reçois bien le json du token.

Le code en lui-même est donc ok, ce sont les paramètres qui sont passés pour la connexion au site de prod qui ne sont pas corrects, alors que ce site de prod requiert le proxy, d'où le tralala avec IIS et proxy comme mentionné dans la doc citée plus haut.

Sans les paramètres du proxy dans le code, j'obtiens la même erreur. J'avais pensé comme toi et donc essayé sans le proxy, mais j'ai tout de même essayé à nouveau toujours avec l'erreur 404. A ce stade, je pourrais penser que iis fait mal sa réécriture d'url, puisque j'obtiens une vieille Peugeot => l'adresse réellement envoyée ne serait pas bien recomposée. Mais j'ai retesté l'écriture au niveau de l'IIS manager et j'obtiens bien {R:1} = token/xxxxxxxxx.

[Incorporated]

Et bien effectivement, le fait de parler de proxy sur la configuration faite sur le IIS n'est pas réellement juste.

En fait, il s'agit d'un Reverse Proxy avec la configuration suivante :



Vous avez installé l'extension supplémentaire https://www.iis.net/downloads/micros...equest-routing ?

De plus le fait d'utiliser le port 84 me plait guère, en effet, il ne s'agit pas du port de communication du protocole HTTP. Le protocole HTTP communique sur le port 80. Peut-être fouiller de ce côté et modifier votre serveur IIS en fonction de ça ? inverser les ports entre votre Default et votre création de site.

[Pierre Fauconnier]

Oui, j'ai cette extension et j'ai paramétré Application Request Routing comme indiqué dans la doc et sur l'image que tu as fournie.

Par contre, je viens d'avoir l'informaticien de mon client (pas du prestataire de l'api) qui me dit que ça doit être un problème de redirection de son côté, car 172.xx.xxx.x:2100 serait une adresse locale et il doit paramétrer son serveur pour permettre d'entrer. Il va me fournir une adresse pour me connecter début de semaine prochaine et je pourrai reprendre les tests avec cette adresse. Je râle quand même ferme que le prestataire n'ait pas été plus clair, tant dans sa doc en ligne que dans les nombreux échanges que j'ai eu avec lui et qui se sont soldés par un "tire ton plan"...

On va donc peut-être progresser...

Je te remercie énormément pour ton aide et ta ténacité, car tes interventions m'ont de toute façon permis de mieux comprendre et de mieux paramétrer. Je t'informerai des résultats via cette discussion.

Je te souhaite un excellent weekend!

[Pierre Fauconnier]

En fait, il fallait que l'ICT ouvre le port 2100 de l'adresser 172.xx.xxx.x et il m'a fourni une adresse en dyndns pour entrer sur le serveur. Du coup, pas besoin d'IIS, de proxy, de url rewriting et autres. Juste une put* d'intervention de 30 secondes là où j'ai perdu 2 jours à chercher à cause d'un dialogue de sourds entre le prestataire de l'erp et moi (faut dire que ce sont des flamands et que même s'ils parlent "bien" français, ils n'ont peut-être pas compris le problème et m'ont envoyé sur une mauvaise piste)

Le problème est donc résolu et n'a en fait rien à voir avec IIS, mais je veux encore une fois te remercier pour ton acharnement. J'ai vraiment apprécié ta volonté à trouver une solution!

Bon weekend!