Formulaire ASP dans Wordpress ?

[Goudurisc]

Bonsoir,

Autant confirmer que je ne suis pas développeur vue ma question.

Sur mon site WP, je dois installer un petit formulaire fourni par un développeur mais il semble que celui-ci soit développé en ASP. Cela dit, ce formulaire doit exploiter une base ASP qui se trouve sur un autre site développé, lui, en asp.

Si je place le html du formulaire dans une page et les fichiers du style "password-page.aspx" sur mon hébergement, est-ce que ça va fonctionner ?

[scoch]

Si je place le html du formulaire dans une page et les fichiers du style "password-page.aspx" sur mon hébergement, est-ce que ça va fonctionner ?

ASP est une technologie Microsoft qui tourne sur un serveur IIS (Microsoft). Il y a moyen de faire fonctionner ASP sur un serveur Apache mais il faudrait que tu aies la main sur le serveur et surtout les compétences

Dans ton cas, je suppose que ton site est hébergé sur un serveur Apache mutualisé, il serait plus simple que tu traites ton formulaire en AJAX qui permet de faire des requêtes cross domain (vers un autre serveur sur un autre domaine). Il faudra configurer le serveur Microsoft pour qu'il accepte les requêtes provenant de ton domaine.

Un peu de lecture : Visitez mon site web.

[Goudurisc]

Je me doutais que c'était très simple… Bref j'ai bien compris le principe mais de là à pouvoir le mettre en place, aucune chance que j'y parvienne.

La demande concerne tout simplement un formulaire d'identification de membre (champs login + mot de passe). Il faut que les membres qui se loguent sur mon site php soit redirigés vers leur compte hébergé sur un autre site en ASP.

C'est surtout une question de design puisqu'il faut que le formulaire adopte le design de mon site et pas celui du site qui gère la base.

Je disposais d'un code complet depuis l'ancien site mais celui-ci est en…ASP

Ca sent l'intervention développeur à plein nez. A moins que le développeur du site (qui héberge le site ASP) accepte et sache faire ce petit raccordement, on peut toujours rêver...

[scoch]

La demande concerne tout simplement un formulaire d'identification de membre (champs login + mot de passe). Il faut que les membres qui se loguent sur mon site php soit redirigés vers leur compte hébergé sur un autre site en ASP.

Si je comprends bien, tu veux sur ton site PHP un formulaire qui permet de s'identifier sur un autre site ASP. Si l'identification est réussie, la personne est automatiquement redirigée vers l'autre site ASP. Il faudrait alors que le serveur ASP ouvre une session (dans le sens de $_SESSION[] en php) avant que le client (navigateur) ait affiché le site ASP… pour que suite à la redirection la personne arrive déjà identifiée sur l'autre site. C'est ça ? Quel est l'intérêt si c'est pour quitter le site PHP immédiatement ? Pourquoi ne pas faire un lien vers le formulaire d'identification de du site ASP ?

[yponomeute]

Quel est l'intérêt si c'est pour quitter le site PHP immédiatement ? Pourquoi ne pas faire un lien vers le formulaire d'identification de du site ASP ?

+1
J'ai également beaucoup de mal à comprendre l'intérêt de ce montage usine à gaz, avec formulaire d'identification sur un site A pour se connecter à un site B. Un peu comme si pour rentrer chez moi il faudrait que j'aille ouvrir la porte chez mon voisin qui ensuite me ramène chez moi et ouvre la porte à ma place.

[Goudurisc]

Sur le plan technique, je vous suis tout à fait mais il s'agit d'une question d'image.

Mon site est destiné à une petite filiale qui ne gère pas directement l'espace membres de ses clients, il doivent passer par le site parent du groupe.

Bien entendu, quand on arrive sur la page d'identification du site, il faut que le design des deux champs corresponde à la charte graphique de la filiale et non pas à celle du groupe.

Bref, au regard des clients, ça fait plus sérieux

[scoch]

Plus sérieux, faut voir…
Si tu es sur un site A aux couleurs rougeoyantes et qu'à la validation du formulaire tu te retrouves sur un site B tout bleu, ça risque de te surprendre, non ? Et si tu regardes la barre d'adresse et que tu te rends compte que tu as changé de domaine, tu risques d'être perdu puisqu'on ne t'a pas prévenu. Alors que si sur le site A on t'explique qu'on est une filiale de B (avec son beau logo) et que le compte client est géré sur B, c'est clair et simple, c'est juste un lien.

Si vraiment tu n'as pas le choix, le plus simple est que le site de la maison mère gère ça. Ça peut ne pas être compliqué à mettre en place :
- le site d'une filiale transmet son identifiant dans une variable en GET lors de l'appel de l'URL du site de la maison mère (par exemple la variable se nommerait « filiale ») :

Code

https://www.maisonmere.com/compte.aspx?filiale=id-de-la-filiale

- la page du site de la maison mère doit pouvoir recevoir cette variable en GET, je crois que c'est comme ça en ASP :

Code

string filiale = Request.QueryString["filiale"]

- la page ASP ajoute à body une classe CSS du nom de la valeur de la variable « filiale », par exemple <body class="id-de-la-filiale">
- reste juste à créer des règles CSS pour appliquer le look du site de la filiale à la page de la maison mère :

Code

/* Pour la maison mère */
#logo {
    background-image: url(logo-maison-mere.png);
}
#formulaire-identification {
    background-color: blue;
}

/* Pour la filiale id-de-la-filiale */
.id-de-la-filiale #logo {
    background-image: url(logo-id-de-la-filiale.png);
}
.id-de-la-filiale #formulaire-identification {
    background-color: red;
}

Ce message a été modifié par scoch - 26 Oct 2014, 20:34.

[Goudurisc]

Tes arguments sont entre nous imparables mais les choix clients ne méritent pas toujours d'être discutés. Celaa dit, je suis scotché par tes compétentes mais je ne voudrais pas te faire perdre ton temps. Surtout que je n'ai pas tous les éléments techniques en main.

L'idée pour moi était déjà de savoir si c'était techniquement réalisable, ce qui me permettra de donner un petit avis quand ce point devra être tranché définitivement. Par le client sur le principe, mais aussi par le développeur du site parent qui est peu en clin à me dérouler le tapis rouge mais qui est malgré tout censé me fournir sous contrainte les éléments techniques "tout chauds".

A mon niveau, je suis tout juste capable de réaliser le formulaire mais pas de réaliser la mécanique qui va derrière.

Le simple fait que tu m'assures que c'est faisable et pas trop compliqué pour un développeur averti (ce que je ne suis pas du tout), ça répond déjà à ma demande et je t'en remercie grandement ! D'ailleurs, je te bénie déjà tous les jours pour la solution que tu m'as apportée sur les styles personnalisés il y a quelques jours

Je vais donc tenter d'avoir plus d'infos dans les jours qui viennent et relancer le débat avec un peu plus de matière.

Encore un grand merci et très bonne soirée !

[No6]

Peut être en passant par une iframe ?
mais je n'ai aucune idée comment la chose peut bien de faire sous WordPress [s'il l'accepte]...

Le pire: la page entière sert de iframe...
une sorte d'URL Rewriting bien pourrit

re:
Ah si, c'est possible ...
http://premium.wpmudev.org/blog/easily-emb...i-frame-plugin/

Ce message a été modifié par No6 - 27 Oct 2014, 17:28.

[scoch]

Celaa dit, je suis scotché par tes compétentes mais je ne voudrais pas te faire perdre ton temps.

Bah tu sais, ce truc de passer une variable et d'appliquer une classe au body c'est basique, c'est d'ailleurs ce que font la plupart des thèmes WordPress ; ça permet de facilement changer l'apparence selon qu'on est sur la page d'accueil, une catégorie, un article, une page, etc.

[Goudurisc]

Je te crois sur parole Mais pour tout dire, j'espère ne pas avoir à te solliciter à niveau sur ce sujet, car ça signifiera que le développeur côté groupe me renverra la patate chaude sous prétexte que ce n'est pas de son ressort !

[No6]

Peut être en passant par une iframe ?
mais je n'ai aucune idée comment la chose peut bien de faire sous WordPress [s'il l'accepte]...

Le pire: la page entière sert de iframe...
une sorte d'URL Rewriting bien pourrit

re:
Ah si, c'est possible ...
http://premium.wpmudev.org/blog/easily-emb...i-frame-plugin/

BIS...

http://www.startyourdev.com/html/tag-html-balise-iframe

Ce message a été modifié par No6 - 27 Oct 2014, 17:29.

[scoch]

Peut être en passant par une iframe ?
mais je n'ai aucune idée comment la chose peut bien de faire sous WordPress [s'il l'accepte]...

Le pire: la page entière sert de iframe...
une sorte d'URL Rewriting bien pourrit

re:
Ah si, c'est possible ...
http://premium.wpmudev.org/blog/easily-emb...i-frame-plugin/

BIS...

http://www.startyourdev.com/html/tag-html-balise-iframe

C'est sûr qu'avec une iframe c'est facile d'intégrer les pages du site de la maison mère mais par contre il ne pourra pas changer l'apparence du formulaire.

Mise à jour de l'élément iframe en HTML5 sur W3C.

[No6]

de toutes façon, l' iframe sur ton site n'est la que pour entrer un lognin/pasword; ça prend au grand max 200 par 300 pixels, à l'intérieur de l'une de tes pages sous wordPress.

Le Look de ton site ne risque pas vraiment d'être mis à mal par cette intégration...

[scoch]

de toutes façon, l' iframe sur ton site n'est la que pour entrer un lognin/pasword; ça prend au grand max 200 par 300 pixels, à l'intérieur de l'une de tes pages sous wordPress.

Le Look de ton site ne risque pas vraiment d'être mis à mal par cette intégration...

Si le formulaire tiers s'affiche dans une iframe, le reste du site tiers s'y affichera aussi, et dans 200 px * 300 px ce ne sera pas utilisable
Son projet est tordu, c'est tout

[No6]

../ mais par contre il ne pourra pas changer l'apparence du formulaire.

si, via javascript, ou mieux jQuery, tu peux changer l'aparence des éléments dans un iFrame...

Si le formulaire tiers s'affiche dans une iframe, le reste du site tiers s'y affichera aussi, et dans 200 px * 300 px ce ne sera pas utilisable
Son projet est tordu, c'est tout

ben non, faut juste que la validation du Login/password envoie sur une autre page[fenetre ou onglet]

Sinon, il peut toujours mettre un iframe plus grand...

Mais je suis bien d'accord avec toi, l'ensemble du projet est complétement bancal.

Déjà des pages en ASP: Beurk...
à la limite s'il y avait du WebService d'ans l'histoire, pourquoi pas , mais faire du CRUD avec WordPress, c'est complétement débile.

Ce message a été modifié par No6 - 27 Oct 2014, 18:34.

[scoch]

../ mais par contre il ne pourra pas changer l'apparence du formulaire.

si, via javascript, ou mieux jQuery, tu peux changer l'aparence des éléments dans un iFrame...

Ah ok pour la solution jQuery, tu penses à la méthode contents() ? Je croyais me souvenir que ça ne marchait pas en cross domain, que pour cela il fallait plutôt se tourner vers la méthode JavaScript Window.postMessage(). Je ferai des essais pour me mettre à la page mais si tu peux m'éclairer, je suis preneur.

Si le formulaire tiers s'affiche dans une iframe, le reste du site tiers s'y affichera aussi, et dans 200 px * 300 px ce ne sera pas utilisable
Son projet est tordu, c'est tout

ben non, faut juste que la validation du Login/password envoie sur une autre page[fenetre ou onglet]

La redirection dans la fenêtre "_top" serait gérée depuis le site tiers affiché dans l'iframe, non ? Ou peux-tu aussi écouter des événements dans l'iframe ?

[No6]

../ mais par contre il ne pourra pas changer l'apparence du formulaire.

si, via javascript, ou mieux jQuery, tu peux changer l'aparence des éléments dans un iFrame...

Ah ok pour la solution jQuery, tu penses à la méthode contents() ? Je croyais me souvenir que ça ne marchait pas en cross domain, que pour cela il fallait plutôt se tourner vers la méthode JavaScript Window.postMessage(). Je ferai des essais pour me mettre à la page mais si tu peux m'éclairer, je suis preneur.

https://forum.jquery.com/topic/modifying-cs...iframe-contents

Si le formulaire tiers s'affiche dans une iframe, le reste du site tiers s'y affichera aussi, et dans 200 px * 300 px ce ne sera pas utilisable
Son projet est tordu, c'est tout

ben non, faut juste que la validation du Login/password envoie sur une autre page[fenetre ou onglet]

La redirection dans la fenêtre "_top" serait gérée depuis le site tiers affiché dans l'iframe, non ? Ou peux-tu aussi écouter des événements dans l'iframe ?

Sérieux ? un simple target= "_blank" dans le formulaire de l'iframe est suffisant...

http://www.w3schools.com/tags/att_form_target.asp


En repensant à son PB, je me suis fait la réflexion que le codeur sur du site en ASP doit pas être vraiment au courant de ce qui est faisable en css.
Car changer l'aspect d'un même site, pour qu'il puisse avoir un habillage différent pour chaque entité d'un même groupe n'est pas le truc le plus compliqué à faire...

Faut dire aussi que Visual Studio n'est pas vraiment calibré pour faire du css

[scoch]

../ mais par contre il ne pourra pas changer l'apparence du formulaire.

si, via javascript, ou mieux jQuery, tu peux changer l'aparence des éléments dans un iFrame...

Ah ok pour la solution jQuery, tu penses à la méthode contents() ? Je croyais me souvenir que ça ne marchait pas en cross domain, que pour cela il fallait plutôt se tourner vers la méthode JavaScript Window.postMessage(). Je ferai des essais pour me mettre à la page mais si tu peux m'éclairer, je suis preneur.

https://forum.jquery.com/topic/modifying-cs...iframe-contents

C'est bien la méthode contents(). Dans mes essais ça fonctionne sur le même domaine mais pas en cross domain alors que mes requêtes AJAX fonctionnent entre ces deux domaines.
Console JavaScript :

Code

Uncaught SecurityError: Failed to read the 'contentDocument' property from 'HTMLIFrameElement': Blocked a frame with origin "http://domaine1" from accessing a frame with origin "http://domaine2". Protocols, domains, and ports must match.

Si le formulaire tiers s'affiche dans une iframe, le reste du site tiers s'y affichera aussi, et dans 200 px * 300 px ce ne sera pas utilisable
Son projet est tordu, c'est tout

ben non, faut juste que la validation du Login/password envoie sur une autre page[fenetre ou onglet]

La redirection dans la fenêtre "_top" serait gérée depuis le site tiers affiché dans l'iframe, non ? Ou peux-tu aussi écouter des événements dans l'iframe ?

Sérieux ? un simple target= "_blank" dans le formulaire de l'iframe est suffisant...

Mais dans ce cas les utilisateurs du site de la maison mère auront aussi l'ouverture d'une nouvelle fenêtre à la validation du formulaire…

Ce message a été modifié par scoch - 28 Oct 2014, 01:48.

[yponomeute]

J'ai du mal à comprendre la volonté du "client" d'adapter le formulaire de connexion à la charte graphique de la filiale. Une fois connecté on va se retrouver avec la charte graphique de la maison mère, ça ne va tromper personne.
Autant inscrire "bananes" sur un sac de patates, une fois le sac ouvert tout le monde verra bien que c'est des patates.

La solution simple sinon : reproduire le code html du formulaire original dans wordpress en modifiant la charte graphique. Il suffit que le paramètre action de la balise form soit identique à celui du formulaire de connexion du site de la maison mère. En validant le formulaire on envoie la requête au site de la maison mère et ça sera transparent.

[Goudurisc]

reproduire le code html du formulaire original dans wordpress en modifiant la charte graphique. Il suffit que le paramètre action de la balise form soit identique à celui du formulaire de connexion du site de la maison mère. En validant le formulaire on envoie la requête au site de la maison mère et ça sera transparent.

En fait, c'est ce que j'avais imaginé innocemment en début de dossier en pensant que si c'était plus compliqué, il faudrait comme toujours trouver une solution.

Si ce principe élémentaire suffit, ce sera parfait !

Pour le débat sur les cinq fruits et légumes par jour, je ne peux pas te contredire mais si ça fait le bonheur du client, je n'insisterai pas pour lui proposer autre chose, le dossier est suffisamment lourd pour ne pas en rajouter.

Je donne une suite dès que j'en sais plus

Merci les amis

[No6]

C'est bien la méthode contents(). Dans mes essais ça fonctionne sur le même domaine mais pas en cross domain alors que mes requêtes AJAX fonctionnent entre ces deux domaines.
Console JavaScript :

Code

Uncaught SecurityError: Failed to read the 'contentDocument' property from 'HTMLIFrameElement': Blocked a frame with origin "http://domaine1" from accessing a frame with origin "http://domaine2". Protocols, domains, and ports must match.

hum, bizarre, ça veux dire qu'il y a un appel au serveur d'origine de l'iframe...

Je sais pas, peut-être en passant via un "$(this).html();" de l'iframe on évite se problème...?

Mais dans ce cas les utilisateurs du site de la maison mère auront aussi l'ouverture d'une nouvelle fenêtre à la validation du formulaire…

bien sur il faut un formulaire à part pour ce cas, c'est pas la mer à boire pour le Dev ASP: juste dupliquer sa page et ajouter un target...

de toutes façon ce truc est débile, yponomeute à raison, bananes et patates...
S'il y une erreur de login / Password, l'utilisation du target foutra le bordel...

Sur ce problème, les billes sont toutes du coté du dev en ASP.
et je comprends qu'il aient pas trop l'envie de passer du temps pour mettre en place une sorte de "déviation" sur leur système.
[et je suis prêt à parier un kilo d'oranges que le leur site en ASP n'utilise pas de CSS; et voire pire= qu'il ne fonctionne qu'en mode "IE6"...]

Du coté des pages en WordPress, faut arréter de croire qu'on peut tout faire et mélanger les genres, le mieux à faire c'est de mettre un joli lien dans gros bouton rose, pour ouvrir une nouvelle page pointant vers le login du site ASP, et basta.

Maintenant si le client veut vraiment que le site ASP ressemble a sa charte graphique, c'est aux personnes du site ASP qu'il faut s'adresser.

Autant envoyer un message à Tim Berners-Lee pour lui demander de tout changer dans l'HTML

Ce message a été modifié par No6 - 28 Oct 2014, 12:58.

[yponomeute]

[et je suis prêt à parier un kilo d'oranges que le leur site en ASP n'utilise pas de CSS; et voire pire= qu'il ne fonctionne qu'en mode "IE6"...]

Du CSS pour faire quoi ? La balise <font> est tellement pratique

[scoch]

C'est bien la méthode contents(). Dans mes essais ça fonctionne sur le même domaine mais pas en cross domain alors que mes requêtes AJAX fonctionnent entre ces deux domaines.
Console JavaScript :

Code

Uncaught SecurityError: Failed to read the 'contentDocument' property from 'HTMLIFrameElement': Blocked a frame with origin "http://domaine1" from accessing a frame with origin "http://domaine2". Protocols, domains, and ports must match.

hum, bizarre, ça veux dire qu'il y a un appel au serveur d'origine de l'iframe...

Je sais pas, peut-être en passant via un "$(this).html();" de l'iframe on évite se problème...?

La méthode html() est l'équivalent de la propriété .innerHTML, je ne vois pas bien comment ça m'aiderait.

Voici mon code et j'ai placé un .htaccess dans le dossier du domaine2 autorisant les requêtes en provenance du domaine1 ainsi qu'un header php dans domaine2/page.php.

Code

<iframe src="http://domaine2/page.php" width="80%" height="600" id="maframe"></iframe>
<script>
$(document).ready( function () {
    console.log('dom ready');
    $('#maframe').load( function () {
        console.log('iframe chargée');
        console.log($(this).contents().find("a"));
        $(this).contents().find("a").css("background-color","#F00");
    });
});
</script>

Nous sommes bien d'accord que le mieux pour tout le monde reste le lien direct, dans une nouvelle fenêtre éventuellement.
Il n'y a qu'à pondre un beau bouton qui mêle les esthétiques du site A et du site B, une sorte de banane plantain

[No6]

Sincerement, j'ai pas testé, mais dans mon idée le "innerHTML" est juste utile pour vérifier que l'iframe est bien chargée, car je ne suis pas certain que le document ready de jQuery le prenne en compte.

pouis ensuite passer directement sur un [$(this).contents().find("a").css("background-color","#F00")] par exemple, mais sans passer par le load jQuery, qui est en fait un ajax déguisé.

l'iframe se charge toute seule, pas besoin de load jQuery d'ailleurs..

[scoch]

Le load jQuery est un écouteur de l'événement load sur l'iframe, ça n'est pas pour la charger
C'est quand même recommandable de procéder dans cet ordre pour accéder de façon sécurisée au contenu de l'iframe, ça permet aussi de gérer une erreur de chargement.
Dans l'exemple au-dessus :
1. Être sûr que le DOM est chargé pour accéder à un de ses éléments : l'iframe
2. Être sûr que la page dans l'iframe est chargée pour accéder à ses éléments
3. Manipuler les éléments de la page contenu dans l'iframe

D'ailleurs, ça marche comme il faut, sauf l'accès au DOM de la page dans l'iframe en cross domain.

Pour le fun, j'ai ajouté un observateur d'événement load sur les éléments window et body de la page chargée dans l'iframe :

Code

<head>
    <script>
        window.onload = onLoadWindow;
        function onLoadWindow(event) {
            console.log('window.onload : fenêtre de page.php chargée');
        }
        function onLoadBody(event) {
            console.log('body.onload : body de page.php chargé');
        }
    </script>
</head>
<body onload="onLoadBody();">
    <a href="http://www.machin.net">Machin</a>
    <a href="http://www.bidule.net">Bidule</a>
</body>

et sans surprise voici l'orde de diffusion des événements :

- dom ready
- window.onload : fenêtre page.php chargée
- body.onload : body de page.php chargé
- $('#maframe').load : iframe chargée
- tableau des éléments "a" => erreur seulement en cross domain