cocoon-users-fr mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From philguillard <philguill...@gmail.com>
Subject Re: Meme session sur plusieurs domaines
Date Wed, 28 Dec 2005 10:21:48 GMT
Bonsoir,

Est-t-il vraiment impossible de changer le domain du cookie? En effet il 
est impossible de prendre un autre domaine, mais enregister le domain 
sans le prefix devrait etre faisable non?
Je viens de realiser que la plupart des sites enregistrent leurs cookies 
avec un domaine court comme google.com et non pas www.google.com.
Sinon a quoi sert le public void setDomain(String pattern) de la classe 
org.apache.cocoon.environment.http.HttpCookie ??
Phil


Jean-Christophe Kermagoret wrote:

> Pourquoi les jsession id ne te plaisent pas trop ?
>
> La seule différence avec les cookies est que le 'mouchard' est 
> visible. Si ton application fonctionne, n'est-ce pas une bonne solution ?
>
> Jean-Christophe
>
> philguillard a écrit :
>
>> Bonjour Jean Christophe,
>>
>> Ce sont des sujets de groupes d'interets. Ces sujets sont nombreux. 
>> Le site est compose d'un tronc commun en "www." pour la recherche, 
>> l'aide et l'enregistrement, et d'une partie groupe avec le sujet en 
>> prefixe pour donner une idee de personalisation et de comunaute. 
>> Cette partie groupe est la meme base pour tous les groupes, car 90% 
>> composee d'affichage de contenu issu de de base de donnees, en XSP et 
>> JX et des cforms.
>> Ces prefixes sont donc crees par le mod_rewrite d'Apache, ce n'est 
>> pas du virtual hosting ni du load balancing, j'ai fait l'erreur de 
>> finir par Apache httpd et suis donc bloque en fin de projet par le 
>> probleme de maintenir une session sur plusieurs subdomaines. Le 
>> meilleur example en live est www.meetup.com car c'est mon inspiration 
>> de base. Je m'apprete donc a sortir un site grand public 90% base sur 
>> cococoon!
>>
>> 1]La seule solution s'offrant a moi pour le moment est de ne pas 
>> utiliser de cookies, mais un jsessionid dans toutes les urls ne me 
>> plait pas trop.
>> 2]La deuxieme serait de pouvoir controler le domain du cookie, ce qui 
>> apparemment est impossible, a moins que je puisse utiliser ce 
>> framework 
>> http://www.javaworld.com/javaworld/jw-01-2001/jw-0126-servlets-p2.html
>> 3] J'ecarte pour le moment l'idee de gerer l'authentifcation via un 
>> realm tomcat car j'utilise le portal et donc l'auth-framework, et je 
>> pense que cela necessiterait de revoir toute l'application, avec peu 
>> de garanties de ne pas me retrouver avec le meme souci de cookies.
>>
>> Tout conseil est le bienvenu, je manque encore de beaucoup 
>> d'experience au niveau applicatif global!
>> Phil
>>
>>
>> Jean-Christophe Kermagoret wrote:
>>
>>> Bonjour,
>>> à quoi servent prefix1 et prefix2 ?
>>>
>>> C'est pour du load balancing ? Des entrées différentes pour des 
>>> rôles différents pour finalement un même site web ?
>>>
>>> Jean-Christophe
>>>
>>> philguillard a écrit :
>>>
>>>> Le plus pratique serait de pouvoir modifier le domain a la creation 
>>>> du cookie, sur cette liste j'apprends que c'est impossible, ce qui 
>>>> me parait le plus probable puisque cette action releve du client. 
>>>> J'ai tout de meme tente de reecrire 
>>>> org.apache.cocoon.environment.http.HttpCookie setDomain(), 
>>>> evidemment sans succes...
>>>>
>>>> Phil
>>>>
>>>> philguillard wrote:
>>>>
>>>>> J'ai trouve "le" document de "la" solution : 
>>>>> http://www.javaworld.com/javaworld/jw-01-2001/jw-0126-servlets.html
>>>>> Il s'agit de modifier le servlet cocoon en faisant un override de 
>>>>> getCookies() et addCookie( Cookie cookie ), a prori dans  
>>>>> java/org/apache/cocoon/environment/wrapper/RequestWrapper et 
>>>>> ResponseWrapper.
>>>>> Mes connaissances java/servlet sont limitees... j'espere que 
>>>>> quelqu'un ici pourra me donner son avis :p
>>>>>
>>>>> Phil
>>>>>
>>>>> philguillard wrote:
>>>>>
>>>>>> Bonjour,
>>>>>>
>>>>>> Je n'ai qu'une seule application cocoon, j'utlise le portal et 
>>>>>> donc l'authentication framework. Via le mod-rewite d'Apache, 
>>>>>> j'utilise des pefixes prefix1.domain.com, prefix2.domain.com qui

>>>>>> en fait me ramenent a la meme application. Je prefere fixer la 
>>>>>> session via le cookie et eviter le jsessionid dans toutes les 
>>>>>> URLs. Or cette methode ne me permet pas de garder la session 
>>>>>> puisque pour le navigateur le hostname est different a cause du 
>>>>>> prefixe. D'ou mon interet pour un realm et/ou le un valve Single

>>>>>> Sign On avec tomcat. Or je ne vois pas du tout comment faire 
>>>>>> cohabiter ces elements avec mon application existante, au niveau

>>>>>> de l'authentication framewrork de cocoon.
>>>>>>
>>>>>> Merci d'avance pour toute aide!
>>>>>>
>>>>>> Phil
>>>>>>
>>>>>> Sylvain Wallez wrote:
>>>>>>
>>>>>>> Philippe Guillard wrote:
>>>>>>>
>>>>>>>> Bonjour,
>>>>>>>> (suite sujet "Basique question de session et url rewrite")
>>>>>>>>
>>>>>>>> - Beaucoup de sites implementent une authentification valable

>>>>>>>> sur plusieurs
>>>>>>>> prefixes ajoutes au meme nom de domaine sans inclure de session

>>>>>>>> id dans les
>>>>>>>> urls, donc j'imagine une certaine quantite sont realises
via 
>>>>>>>> servlet et le
>>>>>>>> session tracking est fait via un cookie. Quelqu'un sait-il

>>>>>>>> comment ceci peut
>>>>>>>> etre realise?
>>>>>>>> - Est-il possible sur cocoon d'empecher le session tracking
via 
>>>>>>>> le cookie et
>>>>>>>> utiliser exclusivement le transformer "urlrewrite"?
>>>>>>>>   
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> La gestion des sessions est différente de la gestion de 
>>>>>>> l'authentification. Ce que tu cherches est peut-être le "single

>>>>>>> sign on", qui permet à un utilisateur de s'identifier une seule

>>>>>>> fois pour toutes les applications d'un même serveur.
>>>>>>>
>>>>>>> Tomcat propose cette fonctionnalité : 
>>>>>>> http://tomcat.apache.org/tomcat-5.0-doc/config/host.html#Single%20Sign%20On

>>>>>>>
>>>>>>>
>>>>>>> Sylvain
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------

>>>>>>
>>>>>> Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/
>>>>>> Pour vous desinscrire : 
>>>>>> mailto:users-fr-unsubscribe@cocoon.apache.org
>>>>>> Autres commandes : mailto:users-fr-help@cocoon.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/
>>>>> Pour vous desinscrire : mailto:users-fr-unsubscribe@cocoon.apache.org
>>>>> Autres commandes : mailto:users-fr-help@cocoon.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/
>>>> Pour vous desinscrire : mailto:users-fr-unsubscribe@cocoon.apache.org
>>>> Autres commandes : mailto:users-fr-help@cocoon.apache.org
>>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/
>> Pour vous desinscrire : mailto:users-fr-unsubscribe@cocoon.apache.org
>> Autres commandes : mailto:users-fr-help@cocoon.apache.org
>>
>
>


---------------------------------------------------------------------
Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/
Pour vous desinscrire : mailto:users-fr-unsubscribe@cocoon.apache.org
Autres commandes : mailto:users-fr-help@cocoon.apache.org


Mime
View raw message