Ouvrir une URL dans le navigateur en méthode POST
Eddy58
Membre
J'ai besoin d'ouvrir une url dans le navigateur, qui amène sur un formulaire php à remplir pour l'utilisateur, auquel je dois également fournir des variables en méthode POST, mais je n'ai encore rien trouvé de satisfaisant...:-\\
J'ai essayé ce code, mais ça télécharge le code html en local et ce n'est donc pas plus sécuritaire que la méthode GET.
Si quelqu'un a une idée sur le sujet...
J'ai essayé ce code, mais ça télécharge le code html en local et ce n'est donc pas plus sécuritaire que la méthode GET.
Si quelqu'un a une idée sur le sujet...
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Tu peux utiliser par exemple directement Cocoa, et le code que tu as cité. Tu peux utiliser curl aussi. Mais dans tous les cas, au final tu as le code, et puis tu en fais quoi ?
Donc si le but c'est d'avoir la page -- résultat de la soumission des variables POST -- qui s'affiche dans Safari, et c'est là qu'est alors le gros du problème justement (ouvrir dans Safari et non pas récupérer soi-même le code source de la page à afficher), eh bien la seule solution que j'ai trouvée jusqu'à présent c'est de faire une page web qui va avoir pour charge de mener à cette page.
Ainsi on ouvre la page et cette dernière redirige automatiquement vers la page souhaitées, en ayant posté les variables POST au passage.
Voir ici ma réponse sur Macfr ou un de nos membres a exactement le même souci
Justement, je n'en ai pas besoin, apres c'est au php de tout prendre en charge. Et ce n'est pas moi qui m'en occupe, mon boulot c'est de fournir certaines infos au script.
Oui je pense que ça serait le plus simple en effet, on va essayer ça.
Merci pour tes suggestions Ali.
[EDIT] Bon, finalement je vais essayer avec une WebView incorporée au soft, en lui injectant le code renvoyé par la NSURLConnection. Mais il risque d'y avoir des problèmes pour accéder aux images et autres ressources (chemins relatifs/absolus).
Ce n'est que si tu as besoin que la page résultat s'affiche dans Safari qu'alors passer par une page "qui soumet automatiquement un formulaire" est la seule solution que je vois.
Si le but est de laisser un script PHP executer des actions sans se soucier que la page résultat s'affiche dans un browser, alors le code que tu as cité est une meilleure piste.
(Par exemple un script PHP qui en fonction des variables passées en POST effectue des requêtes sql INSERT ou UPDATE, ou crée des fichiers sur le serveur, etc, mais dont le résultat n'est pas forcément une page HTML ou au moins l'affichage n'est pas le plus important par rapport à l'execution des actions)
C'est bien une page dynamique php qui doit être réceptionneuse des variables. Mais finalement, ces données, dans l'hypothèse où elles sont interceptées, sont de par leur nature inexploitables, donc on va finalement rester en méthode GET, avec une webview dans le soft, ce qui fait que l'adresse de l'URL et les variables renvoyées avec ne sont pas visibles.
Mais il est certain qu'une méthode permettant d'ouvrir une URL dans un navigateur ou une webview, tout en pouvant envoyant des variables en POST serait la bienvenue.
En fait le souci c'est que pour demander à un navigateur d'aller sur une page, la seule info que tu lui donnes c'est l'URL de la page. Une URL peut/doit contenir en gros, pour le cas du protocole HTTP : http://login:mdp@domain.host:port/chemin/vers/page.php?param1=truc¶m2=machin
(login et mdp sont super rarement précisés, le port l'est rarement aussi). Donc en gros ce sont les seuls informations que tu peux donner au navigateur, en intégrant ces infos dans l'URL.
Conclusion tu ne pourras pas passer autre chose comme info (comme des variables POST) quand tu demandes au navigateur de s'ouvrir sur une page. Pour pouvoir le faire (envoi de donénes POST) il faut contourner le problème et non pas simplement demander bêtement comme on s'en contente d'habitude d'ouvrir telle page (telle URL), puisqu'on a besoin d'envoyer plus.
Les pistes :
- Explorer la voie d'AppleScript pour piloter le navigateur : en gros le dictionnaire AS de Safari est super méga restreint... Donc en bref, cul-de-sac, on peut rien en tirer
- Créer une page servant d'intermédiaire (typiquement une bête page HTTP faite en 10 lignes, contenant un formulaire caché, avec les données POST que l'on veut envoyées préremplies dans le formulaire, et une minuscule ligne de Javascript pour faire en sorte que le formulaire se POSTe automatiquement dès l'ouverture de la page.
C'est la solution que je t'ai proposée dans mon premier post, et celle que j'ai toujours employée quand j'ai eu besoin de faire ce genre de choses, donc à mon avis faut te prévoir une page de ce style pour ton cas.
Avantage de cette méthode : ne dépend pas du navigateur (donc quel que soit le butineur choisi par l'utilisateur comme étant son préféré)
- Dans le cas où tu veux/peux afficher la page dans ton programme, donc que tu acceptes d'ouvrir la page dans une WebView et non pas dans Safari (ou tout autre navigateur)... avec les inconvénients qui vont avec s'il y en a.
Je n'ai pas creusé dans cette piste là , mais je subodore qu'il y a une méthode dans Cocoa pour rajouter des données POST au moment de faire la requête. Ce n'est peut-être pas dans la classe WebView, mais dans ce cas certainement dans les classes pour gérer les NSURL et les NSURLRequest ou tout ce qui tourne autour, pour construire tes requêtes un peu personnalisées et rajouter à la requête le corps qu'il faut (les données dites "POST" sont en fait simplement des données se trouvant à la fin de la requête HTTP, et ayant la même syntaxe que les données GET genre "param1=machin¶m2=truc", c'est donc dans le corps de la requête HTTP tout à la fin)
Eventuellement tu peux si ça t'intéresse rechercher sans doute par là s'il y a des trucs là dedans qui pourraient donc permettre ça, mais sinon je reste persuadé qu'une petite page HTML temporaire (qui tient vraiment sur 10 lignes, et super basique, un titre, un formulaire, une ligne de javascript des plus simples qui existe, et basta) suffit et est plus simple à mettre en oeuvre et à gérer que de chercher plus loin
Oui, j'ai déjà chercher tout ça, dans la doc et les divers forums, et tout ce que j'en ai tiré, c'est un code du genre :
Celui-ci transmet bien les variables voulues en POST, mais là où ça coince c'est que l'on ne peut pas ouvrir le navigateur en même temps, car c'est NSURLConnection qui établi la liaison POST.
Dans un premier temps, j'ai essayé de récupérer le code html renvoyé par NSURLConnection, pour ensuite le réinjecter dans une webview, mais comme c'est une page dynamique php, et toutes les ressources associées (images, autres php) étant en local sur le serveur, celles-ci ne sont donc pas disponibles et ça ne mène à rien.
Je ne demande qu'à avoir plus de précisions de ce côté, je ne connais pas javascript et php et ce n'est pas à moi de m'en occuper, mais je pourrais transmettre ta méthode au webmaster. Ce qui coince vraiment ce n'est pas le faites d'envoyer des données en POST, mais le faites de les exploiter dans la page php dynamique conçue à cet effet, et surtout d'ouvrir cette page dans un navigateur ou une webview tout en ayant les variables POST prévues bien remplies.
Mais bon je rappel que ce n'est pas primordial (bien que j'aimerais savoir comment faire), pour l'instant on est en méthode GET dans une webview, et c'est suffisant à nos besoins actuels.
Bien sûr à toi de mettre les bonnes valeurs de nom de variables (paramètre "name") et de leur valeurs (paramètre "value") ainsi que la bonne URL vers laquelle envoyer ces données (ici 4 variables POST, donc)
Ici les valeurs envoyées sont statiques, mais si tu veux pouvoir changer la valeur des variables POST que tu envoyes selon les cas, le plus simple c'est que tu génères ce code source dynamiquement avec Cocoa (NSString avec un initWithFormat étant le plus judicieux, à ensuite enregistrer dans un fichier temporaire .html que tu demandes d'ouvrir avec Safari).
Tu peux aussi rajouter du code javascript pour qu'il recopie les paramètres passés en GET dans le formulaire (pour qu'elles soient finalement transmises en POST lors de la soumission auto du formulaire) mais bon je trouve ça moins pratique.
Enfin bon pour tout ça je te laisse faire, je ne te fournis que le code HTML type après à toi de l'adapter.
Problème : ça ne marche que si j'ouvre avec le navigateur niark niark
Je crée une simple page HTML avec le formulaire et je la charge, mais pas dans une webview car j'en ai pas besoin. Mais ducoup ça ne marche pas.
J'up ce poste car j'ai un soucis avec un fichier php et une webview.
J'aimerai que ma webview afficher un .php qui sert de script mais qui affiche aussi du contenu.
Le soucis c'est que quand la webview se charge le code n'est pas interprété et je me retrouve à lire mon code.
voici la ligne qui fait appel au .php
Inutile de préciser que j'ai bien activer MAMP ^^
Pourquoi ca ne marche pas alors?
Merci !
1) Tu demandes une page locale, donc il va directement aller la chercher dans le système de fichier / disque dur local, il n'y a aucune intervention d'un quelconque serveur web ici vu ton code
D'ailleurs si tu fais la même requête dans Safari, donc que tu tapes "/Applications/MAMP/htdocs/acquisition.php" dans Safari, ça va te rajouter un "file://" devant... et t'ouvrir le fichier php sans l'interpréter, sans passer par le serveur MAMP.
2) en plus tu utilises URLWithString sauf que tu passes à ce constructeur une NSString... qui est loin d'être une URL. Or cette méthode attend une chaà®ne représentant directement une URL valide.
--> Donc soit tu veux construire une URL à partir d'un chemin de fichier local, et dans ce cas c'est "fileURLWithPath:" et non "URLWithString" qu'il faut utiliser... mais dans ce cas ça te construira une URL du genre "file:///Applications/..." et ne passera toujours pas par ton serveur Apache (et donc pas de PHP non plus), d'ailleurs que tu aies ton MAMP de lancé ou pas ça changera rien...
---> Soit tu veux vraiment utiliser Apache et PHP (enfin MAMP quoi) et donc faire en sorte que le module PHP intégré à Apache interprète ton code PHP pour te le retourner... Bref, un usage normal de ton serveur web php quoi. Mais dans ce cas il faut faire une requête au serveur, donc un http://...
Après ça dépend comment est configuré ton MAMP, c'est à dire plus exactement où pointe ton DocumentRoot et à quoi il est mappé... mais typiquement l'URL que tu cherches est tout simplement (ouvre-la avec Safari pour voir) qqch du genre : "http://localhost/acquisition.php"; !
[tt]wb mainFrame] loadRequest:[NSURLRequest requestWithURL:[NSURL URLWithString:@"http://localhost/acquisition.php"];[/tt]
Par contre avant je mettait "acquisition.html" (sans code php dedans) et ça m'affichait bien mon contenu . Tu sais pourquoi?
Un serveur web (comme Apache) a pour but de répondre aux requêtes HTTP (type HTTP GET et HTTP POST typiquement), les interpréter pour "comprendre" quelle "ressource" (fichier) tu demandes, et te renvoyer le contenu.... qui est typiquement du code HTML. Et s'il y a des choses comme un module PHP intégré dans ce serveur web, le module va "prétraiter" le contenu du fichier pour interpréter les parties PHP... mais le résultat du passage par la moulinette PHP est en général... du code HTML au final.
Après, ce code HTML, qu'il vienne :
- d'un serveur web qui te l'a fourni directement tel quel car tu as demandé un fichier genre "http://localhost/fichier.html",
- du serveur web après prétraitement par la moulinette PHP (qui aura généré un code HTML au final) car tu auras demandé genre "http://localhost/fichier.php",
- ou du système de fichier local directement sans passer par le serveur web car tu auras demandé "file:///Users/moi/Desktop/fichier.html" (ce qui te retourne le contenu brut du fichier, donc si c'est du HTML direct pas de soucis, si c'est du PHP t'auras le code source du PHP, puisqu'il n'y a pas intervention du serveur),
... au final ça reste toujours du code HTML que le navigateur (par exemple Safari ou Firefox) reçoit en réponse à ta requête.
Après c'est le navigateur qui fait le travail d'interprétation de ce code HTML pour te le présenter sous la forme que tu attends, avec les images et tout dans la page web (et non pas le code HTML visible en brut).
Donc tout ça c'est normal... tant que tu récupères du HTML, quelle que soit sa source (via serveur web avec ou sans prétraitement PHP, ou via filesystem local), le navigateur va l'interpréter. Après si tu veux du PHP, comme c'est le serveur web qui se charge, via son module PHP, de faire le prétraitement de la page pour interpréter le PHP et te générer du HTML en sortie... bah il faut passer par le serveur web pour avoir le résultat du PHP interprété et pas le code PHP brut de forme.