Précédent   Forum des professionnels en informatique > Webmasters - Développement Web > Outils > XMLRAD
XMLRAD Environnement de développement Web XML/XSL. Avant de poster -> F.A.Q XMLRAD
Partagez cette discussion sur d'autres réseaux sociaux : Viadeo Twitter Google Facebook Digg Delicious MySpace Yahoo
Réponse Proposer ce sujet en actualité
 
Outils de la discussion
Publicité
'
Vieux 31/01/2003, 10h45   #1
Membre chevronné
 
Philippe
Inscription : avril 2002
Messages : 456
Détails du profil
Informations personnelles :
Nom : Philippe
Localisation : France

Informations forums :
Inscription : avril 2002
Messages : 456
Points : 688
Points : 688
Envoyer un message via ICQ à Ph. B.
Par défaut 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,

Philippe.
Ph. B. est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 31/01/2003, 15h51   #2
Membre éclairé
 
Inscription : janvier 2003
Messages : 284
Détails du profil
Informations forums :
Inscription : janvier 2003
Messages : 284
Points : 311
Points : 311
Envoyer un message via MSN à Nicolas.Cogi
Par défaut Cookies...

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 ) :

- 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
__________________
Nicolas
Nicolas.Cogi est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 31/01/2003, 16h46   #3
Membre chevronné
 
Philippe
Inscription : avril 2002
Messages : 456
Détails du profil
Informations personnelles :
Nom : Philippe
Localisation : France

Informations forums :
Inscription : avril 2002
Messages : 456
Points : 688
Points : 688
Envoyer un message via ICQ à Ph. B.
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...

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

Enfin, merci pour tes conseils toujours avisé !

Bon weekend,
Philippe.
Ph. B. est déconnecté   Envoyer un message privé Réponse avec citation 00
Réponse Proposer ce sujet en actualité Cette discussion est résolue.
Outils de la discussion



Fuseau horaire GMT +2. Il est actuellement 16h35.


 
 
 
 
Partenaires

Hébergement Web