Les Cookies 4° ! : LA SOLUTION

Bonjour,

Après m'être longuement débattu avec les cookies et leur non prise en compte par l'application, j'ai enfin trouvé l'origine du problème et par la même sa solution que je vous expose ici...

Hypothèse : un XMLRad 7.08.708, téléchargé le 23/01/03 installé sur un Win2000 Sp2 avec IIS 5...

Je remercie tout d'abord Julien C. qui m'a mis sur la piste :

Citation:

---

Envoyé par Julien C.

N'oublies pas que les cookies sont restitués automatiquement dans le Context, que si l'URL d'invocation est la même que lorsque les Cookies ont été inscrits sur le poste client.

---

L'URL (DOMAIN + PATH) ne variant pas, j'ai donc examiné les cookies générés par les deux applis (celle qui fonctionne et l'autre) et recherché des différences. J'ai trouvé dans le cookies de l'application "buguée" que la fin de l'URL avait un "slash" surnuméraire.

Code:

---

1 2 3

localhost/TESTBin/TEST.dll// au lieu de localhost/TESTBin/TEST.dll/

---

En examinant les paramètres de XMLRad, j'ai trouvé dans "Aliases" ceci:

Code:

---

TESTDLL => /{$XMLC_InstanceName}Bin/TEST.dll/

---

Petite remarque : Ce paramètre a été défini par XMLRad à la création du projet et je ne l'ai pas modifié par la suite ! Ce projet n'était pas non plus un réimport mais une création pure...

J'ai corrigé comme suit :

Code:

---

TESTDLL => /{$XMLC_InstanceName}Bin/TEST.dll

---

J'ai rectifié tous les liens construits avec cet alias comme suit:

Code:

---

1 2 3

<a href="{/document/Aliases/TESTDLL}FormTest"><b>Mon test</b></a> est devenu <a href="{/document/Aliases/TESTDLL}/FormTest"><b>Mon test</b></a>

---

Et j'ai retesté... AVEC SUCCES !!! 8)

Le problème vient donc du fait que XMLRad rajoute un "/" à l'URL qu'il stocke dans les cookies sans vérifier s'il n'est pas déjà présent...
Ce "/" présent dans l'alias pourrit donc le comportement de l'appli dès que l'on utilise les cookies...

Voila, en espérant que cette petite solution épargnera à d'autres de perdre le temps que j'ai passé à comprendre l'origine du pb...

Bon dév. et bon week-end, :wink:

Philippe.

Alors alors... :)

Un truc important, c'est que l'alias n'a rien à voir du tout dans la gestion des cookies. ce n'est pas cette valeur là qui est prise pour écrire le path du cookie.
Typiquement, Delos SI utilise massivement les cookies et les alias ont tous un / final. la technique est donc rodée et il n'y a pas de problèmes là dessus.
La recommendation de l'éditeur à ce sujet est de mettre un / à la fin des alias...

Donc, il faut chercher une solution ailleurs : en regardant le code du Framework de plus près (en particuliers, XMLGram.pas Assign.DoProcess et XMLUtils.pas TXMLRequest.SetCookies et AddCookie), on voit que le Framework prend la valeur des InitParams XMLC_CookiesPath. Si celle-ci est blanche, alors le Framework prend la valeur du Context Request.URL. Jamais il n'est fait mention des Aliases.

Je pense plutot que le problème du double slash "//" vient plutot d'une des urls de ta cinématique de login, qui était appellé avec {/document/Aliases/ProjectDLL}/Action, d'où la présence d'un second slash dans le Request.URL. Je pense qu'une seule des actions etait invoquée avec un double slash, ce qui ecrivait dans le cookie la mauvaise valeur, et provoquant donc l'erreur que tu décris...

Ta correction t'a certainement demandé pas mal de boulot pour mettre à jour toutes les urls de ton application, alors que je pense qu'il suffisait de rechercher ton alias suivi d'un / supplémentaire.[/b]

Pour le paramètrage XMLC_CookiesPath, c'est la technique recommandée par l'éditeur pour la gestion du path des cookies. Ce paramètre est apparu avec les alias partagés pour tous les projets (/ProjectsBin/MonProj/MonProj.dll). Le XMLC_CookiesPath permet alors de spécifier le path correctement dans ce cas là, et surtout de partager un meme cookie pour différentes applications partageant un meme alias IIS commun (par exemple, 2 projets dans l'alias ProjectBin ont chacun leur propre répertoire Proj1 et Proj2. Par défaut, ils n'auront pas le meme CookiesPath et donc chacun aura son propre cookie. On peut alors assigner le XMLC_CookiePath à l'alias commun /ProjectBin pour partager le cookie pour les 2 applications et partager ainsi, par exemple, les informations de login de l'utilisateur).

En résumé (faut que j'arrete les réponses de 3km :D) :

- un / à la fin de chaque Alias (recommendation editeur)
- attention aux urls de l'appli : toujours utilisé l'alias suivi du nom du XMLService, sans / entre les deux :)
- utilisation du XMLC_CookiesPath pour forcer le bon path à tous les coups

Damned... C'est compliqué, ces histoires de ptits gateaux :roll:

Bonjour Nicolas,

Effectivement, une recherche dans l'ancien projet montre que j'ai placé un "slash" dans une URL de l''appli, juste lors de la validation de la fiche de connexion ! :(
Si seulement ce "//" était apparu dans la ligne Edit de la fenêtre du navigateur, j'aurais pu remonter à l'origine du pb plutot... :evil:

Et comme les navigateurs (ou les serveurs web) ne semblent pas génés par des "slash" multiples... :evil:

Enfin, merci pour tes conseils toujours avisé ! :lol:

Bon weekend,
Philippe.