7
votes

En utilisant le même cookie à travers les sous-domaines sélectifs

J'essaie d'essayer de trouver un moyen de partager des cookies sur plusieurs sous-domaines.

Réglage du cookie comme: xxx

fait exactement cela. Mais il y a un léger problème ici. Cela partagera le cookie à travers toutes les sous-domaines.

Mon problème est que j'ai d'autres environnements (dev et test) mis en place sur 2 sous-domaines. Je cherche un moyen de partager des cookies sur des sous-domaines "sélectifs". C'est-à-dire de partager des sous-domaines et ne partage pas parmi d'autres. Je ne sais pas si quelque chose comme ça existe.

Toute aide est appréciée. Merci.


5 commentaires

Vous pouvez simplement ajouter un préfixe dans vos noms de cookie. Dev_Token, Prod_Token, tout ce que vous avez besoin.


Je ne pense pas que la solution pour faire exactement ce que vous voulez exister. Ce que vous pouvez faire est de protéger votre cookie d'être consulté par tous les sous-domaines. Vous pouvez encoder votre cookie en quelque sorte et donner des touches sélectives sous-domaines pour le décoder. Ou vous pouvez explicitement définir des cookies pour chacun des domaines dont vous avez besoin en même temps. Comme si vous définissez dev_cookie et test_cookie au même endroit dans le code.


À la connaissance de ce que je suis au courant et que d'autres ont mentionné ce n'est pas possible. Votre seule solution est de les nommer différemment. Sauf si vous obtenez un domaine différent pour vos environnements de développement, ce qui semble un peu beaucoup.


Vous pourriez trouver $ cookie-> SetDomain ($ domaine) utile, comme trouvé dans Cette bibliothèque autonome < / a>. Cela vous permet de partager le cookie avec tous les sous-domaines ou pas du tout. Tous les autres scénarios ne sont pas possibles conformément à la spécification HTTP.


Serait-il possible de faire le domaine = dev * .example.com domain = prod * .example.com?


4 Réponses :


1
votes

Autant que je sache que vous puissiez partager tous les sous-domaines à l'aide de '.MyDomain.com' (comme vous devez être spécifique et cibler un seul sous-domaine en utilisant, par exemple, 'test.mydomain .com '.

Vous pouvez également utiliser des astuces ou des travaux de contournement, comme le préfixer le nom de la cookie, puis de faire le côté du serveur logique, mais je ne sais pas si cette SI la solution que vous recherchez.


0 commentaires

0
votes

Après avoir pensé et rechercher beaucoup de choses à ce sujet et lire tous les précieux commentaires postés ci-dessus, je suppose qu'il n'y a pas de solution directe à cela.

J'aurais pu aller avec la solution fournie par Adrien Hingert, mais cela signifierait une vérification supplémentaire à chaque fois qu'un utilisateur est entré.

Je suppose que je suis laissé sans autre option, mais pour déplacer mon développement et mes environnements de test vers un autre domaine.

Merci beaucoup de vous tous les gars pour vos pensées.


0 commentaires

0
votes

L'attribut domaine = .example.com rend spécifiquement le cookie disponible par tous les sous-domaines. Il suffit de supprimer cet attribut et le cookie ne peut être lu que par le sous-domaine qui le définit.

C'est aussi facile.


1 commentaires

Ce n'est plus valide.



0
votes

Peu de retard au spectacle et de l'interface utilisateur ont une émission similaire dans mon programme de développement des choses. Après avoir frappé ma tête ici, il est évident est clair.

Permet de le casser là-bas est un «Strong> Setter Strong> AKA PHP Script à partir d'un domaine protticulaire et il y a SENDER STRUT> AKA AKA. Envoie des cookies sur chaque appel effectué à partir du navigateur au domaine du domaine. P>

Nous savons également qu'une fois le script PHP effectué le traitement de la connexion au navigateur et ouvre un thread pour un nouvel appel par dites. P> Broswer utilise cependant la date d'expiration des cookies pour déterminer quoi rester dans le cache et ce que ne pas rester à Cahche. Basé sur ce qui est gardé il kee sur le couplage des données à chaque appel. P>

Qu'est-ce que nous avons l'intention de faire est de faire le script informer le navigateur Quel domaine à envoyer Cokkie et quel domaine à ne pas envoyer de cookie à. P >

Spécification indique uniquement le domaine qui est le setter recevra le cookie de l'expéditeur. Si ce n'était pas de cette façon, nous serions dans beaucoup de problèmes. énorme passerelle de piratage inondé ici et là. p>

basé sur au-dessus de la fonction de cookie PHP de la fonction de cookie PHP effectue une seule opération Oui, nous pouvons réégalités bit ici et là-bas sous la hotte, il n'exprime que des opérations simples. P >

EG P>

    function newCookie ($name,$value = "",$expires = 0,$path = "/",$domain = "",$secure = false,$httponly = false){
    
    if (is_array($domain) && sizeof($domain)>> 0){
    
    foreach ($domain as $value) { 
        setcookie($name,$value,$expires,$path,$value,$secure,$httponly);
    }
    
    
    } else {
    setcookie($name,$value,$expires,$path,$domain,$secure,$httponly);
    }
    
    };
    
    newCookie('token', base64_encode(serialize($token_value)), time()+10800, '/', ['prod.mydomain.com', 'dev.mydomain.com']);
 or simply function newCookie ($name,$value = "",$expires = 0,$path = "/",$domain = "",$secure = false,$httponly = false){

if (is_array($domain) && sizeof($domain)>> 0){

foreach ($domain as $value) { 
    setcookie($name,$value,$expires,$path,$value,$secure,$httponly);
}


} else {
setcookie($name,$value,$expires,$path,$domain,$secure,$httponly);
}

    };

    newCookie('token', base64_encode(serialize($token_value)), time()+10800, '/', 'dev.mydomain.com');


0 commentaires