Forums : Xul, Xbl, JS...

En html, l'envoi des données du formulaire est transparent. En xul, non, car il n'y a pas la notion de "formulaire" au sens html.

Il faut donc que tu envoi toi même les données du formulaire, à la main, en utilisant l'objet XMLHttpRequest comme décrit sur le wiki. Et à toi aussi de traiter la réponse.

Ton script php recevra donc des variables post. Il renverra (simplement par des echos) une réponse, que tu récuperera via l'objet xmlhttprequest. à toi alors dans le xul de tester cette réponse. Si l'authentification est bonne, alors tu n'auras qu'à recharger la fenetre (window.location....) avec le xul qui va bien (en verifiant toujours dans ce xul si l'utilisateur est bien autorisé à l'affiché, sinon il faut recharger la fenetre avec le xul du login )

si la réponse n'est pas bonne, tu efface les champs du formulaire et l'utilisateur devra retaper son nom.

Regarde des infos dans /wiki/WebServices et /wiki/ApplisWeb. cela pourra t'aiguiller même si il n'y a pas énormément de chose.

Merci pour ta réponse.

C'est justement cette cinétique au niveau de XUL que je ne vois pas comment mettre en place.

Sur le lien que je donne les relations javascript/PHP sont expliquées.

Est ce que ce découpage de parrait aller:

• L'utilisateur se connecte à l'IU
• On controle son identification, elle est fausse.
• On recharge le formulaire de login (window.location)
• L'utilisateur s'identifie
• On envoie les données à PHP qui effectue le controle.
• Si c'est pas bon on affiche un msg d'erreur et on vide le form
• Si c'est bon le PHP ouvre une session et renvoie un valeur "ok"
• Javascript redirige vers l'application XUL (window.location)
• A chaque communication avec le serveur PHP celui-ci controle que la session est toujours valide (donc il sait retrouver la bonne session, comme avec du html).
• Si elle est valide il effectue l'action
• Si elle n'est pas valide il redirige l'utilisateur vers le formulaire de login (window.location).

Donc pour que ca fonctionne je dois stocker dans javascript une variable qui indique si l'identification est OK. (par défaut non donc redirection)

Chaque echange avec PHP modifie cette variable.

A chaque action je dois faire un controle sur cette variable et rediriger l'utilisateur en cas d'echec (ou afficher une popup de relogin).

J'ai tout bon ?

C'est justement cette cinétique au niveau de XUL que je ne vois pas comment mettre en place.

je viens de rajouter des trucs dans ApplisWeb/Architecture . peut être ça t'aidera.

Sur le lien que je donne les relations javascript/PHP sont expliquées.

pas lu.

Est ce que ce découpage de pourrait aller:
(zap)

Tout à fait.

Donc pour que ca fonctionne je dois stocker dans javascript une variable qui indique si l'identification est OK. (par défaut non donc redirection)
Chaque echange avec PHP modifie cette variable.

Je ne sais pas si elle est vraiment utile cette variable javascript. Puisque si ton script php n'est pas ok sur l'authentification, il redirige illico vers l'écran xul de login.

Comme cela reste une appli web, le système de session de PHP fonctionne toujours, que tu appelle une page en modifiant l'url de la fenêtre, ou que tu l'appelles en appellant XMLHttpRequest (celui ci envoi/recoit les cookies comme d'hab...)

Donc ton xul à la limite, n'a même pas à s'occuper de l'authentification. Il ne devrait d'ailleurs absolument pas car comme c'est coté client, cela veut dire qu'il y a des petits malins qui peuvent modifier le xul, javascript etc (DOM inspector et debugger js roxor ;-). Donc on laisse le maximum coté serveur, sauf l'UI.

Après avoir lu la doc que tu vien d'ajouter je me situe donc dans ce cas là:

Architecture client-serveur "lourde"

Puisque l'IU sera disponible en XPI.

Seulement étant dans ce cas là je ne peux pas demander au serveur PHP de faire une redirection du client vers le formulaire de login (puisque il est en local, p/e que le serveur ne sait pas ou le trouver non ?).

C'est pour ca que j'avais pensé utiliser une variable javascript qui en fonction de la réponse du serveur à la validité de l'identification, redirige ou non vers le formulaire de login.

Cependant je suis d'accord qu'il va etre possible d'empeicher cette redirection.

Seulement cette redirection ne fait que partie du "mécanisme d'utilisation", dans le sens ou si on l'empeiche on se retrouve exactement dans le meme cas que si on n'effectue pas d'action. Ce qui a été chargé est toujours "lisible", mais on ne peut plus rien en faire, le serveur refusera de faire quoi que ce soit puisque l'identification n'est plus valide.

En fait ca serait un peu comme quand tu laisses une session ouverte trop longtemps dans copix. Tant que tu fait rien tu peux lire ce qu'il y a d'affiché, mais si tu demandes une action le serveur voit que la session n'est plus valide (expirée) et tu es redirigé vers le formulaire de login. Si tu empeiche la redirection ca ne t'avance à rien, du reste de toute facon bloquer avec les données que tu as.

J'ai écris

Puisque si ton script php n'est pas ok sur l'authentification, il redirige illico vers l'écran xul de login.

J'ai écrit n'importe quoi... On peut pas effectuer de redirection quand on fait un XMLHttpRequest.

ce qu'il faut, c'est, si la session n'est out, (donc mec plus identifié ou non identifié), alors le script php renvoi un code précis à ton script JS, **quelque soit** l'action demandée.

Aprés, à ton script js de detecter ce code dans la reponse xmlhttprequest, et de faire un window.location..

Et même si on trafiquote le js ou autre coté client, l'appli restera inutilisable (puisque quoique qu'il arrive aucune action ne sera executée coté php puisque session pas bonne)

oki, là je suis 100% ok :)

Je testerais ca demain. Je viendrais poster un message ici histoire de dire si ca fonctionne nikel ;)

J'ai oublier de te remercier :p

Merci pour ton aide :)

Bon, ben j'ai fait un petit essai rapido et ca fonctionne nikel :)

Merci encore :)

NB: Ca serait p/e pas mal de faire une petite doc à mettre sur le site à partir de ces éléments ?

Quand je mettrais réélement cette solution en application d'ici quelques semaines je pourrais éventuellement en rédiger une petite :)

La technique que j'ai utiliser pour l'identification est la suivante :

• Déjà faut considéré que tout ce qui vient du client est suspect.

• Une fonction (en l'occurrence un Web Service) pour l'identification
• Elle prend en entré le login et le passe
• Elle renvoie en sortie un N° de session aléatoire

• Et après toutes les fonctions sur le serveur (Web Services, rdfs, ...) nécessitent le n° de session, la vérification de l'utilisateur n'est pas faite par le client (.xul) mais par le serveur à chaque appel d'une fonction distante.

Avantages :

• La vérification de l'utilisateur est faite sur le serveur.
• Pas facile à passez outre.
• Pas de vérification systématique du client dans le chargement du .xul ( ce qui prend des ressources, rarement utile )

Inconvénients :

• Toute la sécurité repose sur le n° de session.
• On peut être amené à se connecter a un .xul via un n° de session expiré
• Le n° de session reste le même tout le long de la session.

Euh, pourquoi tu t'embete avec ce numéro de session ???

En PHP par exemple, il est généré automatiquement et stocké dans un cookie. Tu n'as donc rien à faire de ce coté là. Aucune vérification sinon la présence de variables dans la session (avec eventuellement un contrôle de timeout par rapport à une date de la dernière requête etc..)

bref, tu t'embètes bien pour rien je pense. À moins que tu utilises une autre techno coté serveur qui ne fait pas ce genre de chose.. (Mais je me demande alors bien laquelle

Le processus devrait être plutôt :

• Une fonction (en l'occurrence un Web Service) pour l'identification
• Elle prend en paramètre le login et le passe
• Elle renvoie un boolean indiquant si l'authentification est ok ou pas. (+ un message si pas ok)
• Si c'est ok, le service web crée une variable en session indiquant que tout est ok. PHP renvoi de toute manière l'id de la session dans un cookie. Cookie qui est renvoyé au serveur automatiquement par le navigateur à chaque appel de services web.

Le système de gestion via les session de php est pas mal, mais souffres de quelques problèmes:

• Le client doit accepté les cookies ( Mozilla pas de problème, applet JAVA je sait pas, autre indéterminés )
• On ne peut pas géré de session "longue".
• On ne peut pas géré une session sur plusieurs serveur en même temps.

Je sous entend qu'on ne sait pas exactement ce qui vas appeler les Web Services, pour le moment je développe un client en XUL, mais il n'est pas inenvisageable d'avoir un jour un autre client dans un autre langage.

Bref, à choisir en fonction de ce que l'on veut :)