Autre solution : mixer les répertoires contenant les sessions par un lien
symbolique de ecrire/data/ vers l'autre ecrire/data/ (à tester).
Ainsi si tu es logé dans un spip, tu es logé dans l'autre automatiquement.
Pour poser le cookie "tout en haut" du site, il suffit d'un rewriterule de
type [R] dans apache (c'est ce que je fais sur le Diplo, avec mes urls
bizarres).
Pour tenter de permettre un fonctionnement correct, j'ai commencé à
modifier les noms des cookies. J'ai mis des variables
"$nomcookie_spip_admin" et "$nomcookie_spip_session" dans
Ci-joint un patch qui permet de choisir le préfixe des cookies placées
par SPIP. Ce préfixe est modifiable dans ecrire/inc_version.php3, au
même endroit que le choix du préfixe des tables SQL.
A quoi ça sert ? A pas grand'chose, sauf à permette d'avoir un site SPIP
dans un sous-répertoire d'un autre site SPIP sans conflit de cookie.
Si vous placez un site SPIP dans le sous-répertoire d'un autre, pour que
ça marche bien il faudra modifier la variable $cookie_prefix dans
ecrire/inc_version.php3 sur un des deux sites.
C'est tout. J'espère ne pas avoir fait d'erreur...
Pour info, voici un argumentaire un peu plus technique, qui a convaincu
quelqu'un d'important (qui a toujours raison mais qui a grillé son joker
aujourd'hui) de l'urgence de cette refonte totale du code de SPIP :
L'idée est de permettre d'avoir des sites imbriqués (au sens : un site
racine et des sites dans des sous-répertoires) qui puissent avoir des
utilisateurs communs (logins identiques) sans que cela ne gène le
système de gestion des cookies. Ces utilisateurs (extraits à partir
d'une base LDAP chez moi, mais tout autre partage peut être imaginé)
n'auront cependant pas tous accès au /ecrire de tous les sites.
Il n'est donc pas envisageable de partager les sessions entre les
différents sites par des liens symboliques entre les ecrire/data, donc
les utilisateurs doivent avoir des cookies distincts (un par site).
Par ailleurs, cela fonctionnera même sur des sites installés chez des
hébergeurs qui ne permettent ni liens symboliques ni rewritetules.
Ce patch pourrait quelque part s'assimiler à celui qui permet d'avoir
plusieurs sites sur une seule base MySQL avec $table_prefix.
Salut,
>Ci-joint un patch qui permet de choisir le préfixe des cookies placées
>par SPIP. Ce préfixe est modifiable dans ecrire/inc_version.php3, au
>même endroit que le choix du préfixe des tables SQL.
Une idée toute bête, ça pourrait pas être raccroché au préfixe base ??
Je pense que ça se rejoint pas mal, non ?
Dans ce cas il suffit de changer les deux variables, mais je préfère
laisser la liberté
Ce que je voulais dire, c'est que l'affaire du préfixe des tables a été mis en place pour pouvoir mettre deux Spip dans une seule
base. Pour les hébergeurs mutualisés, ce peut être utilisé pour avoir plusieurs spip dans des sous-répertoires.
Donc, plutôt que de rajouter un patch pour personnalisé le nom du cookie, je pense qu'il est plus simple de nommer le cookie selon
le préfixe des tables.
Mais je n'ai pas testé
@+
JB
@ Thomas NOEL <thomas.noel@auf.org> écrivait, il y a bien longtemps :
Ci-joint un patch qui permet de choisir le préfixe des cookies placées
par SPIP. Ce préfixe est modifiable dans ecrire/inc_version.php3, au
même endroit que le choix du préfixe des tables SQL.
Je viens de nettoyer le code autour de ces histoires de cookies, et j'en ai
profité pour ajouter un $cookie_prefix dans inc_version, avec une méthode
un peu différente de celle que tu suggérais, car tout est centralisé dans
ecrire/inc_version.php3 ; ainsi, lors des prochains développements il
suffira de penser à utiliser spip_setcookie() au lieu de setcookie()...
