Comment gérez-vous cos COOKIES ?

[php_addict]

Bonjour

tout est dans le titre, Comment gérez-vous cos COOKIES ? sachant qu'il y a un nombre de cookies maxi par domaine et une taille maxi pour chaque cookie? (je n'ai pas les chiffres en têtes et les sources internet se contredisent, faudrait voir l'imbuvable RFC...)

alors alors?

- un cookie par donnée/paramètre
- un seul cookie avec les données sérialisées?
- autre?
- avantage et inconvénients?

bonne journée !

[Sephi-Chan]

La RFC te donnera la référence mais tu n'en sauras pas plus sur l'implémentation de chacun.

J'utilise extrêmement peu de cookies, pour commencer. Le plus souvent, j'en utilise un seul qui contient le jeton de persistence de mon utilisateur courant. Si j'en ai besoin d'autres, je les stock dans des clés différentes, histoire d'aller au plus simple.

Globalement, je pense qu'il y a assez peu d'informations à stocker de cette manière. La plupart des choses sont déterminées depuis l'utilisateur courant (choix de la langue, nombre de messages par sujet, etc.)


Dans d'autres cas, le cookie est stocké pour donner un état aux pages. Par exemple dans un jeu ou l'utilisateur pourrait gérer plusieurs villages, le village courant pourrait être stocké dans un cookie, ce qui permettrait de savoir sur quel village agir quand on est sur les différentes pages.

Selon moi, cette approche est nulle. L'URL est un bien meilleur endroit que le cookie pour donner un contexte.

Je préfère que le site utilise des URL de type.

/villages/paris/buildings
/villages/yerres/buildings
/villages/yerres/people

Qu'un site qui utilise un cookie village_id et seulement 2 URL :

/buildings
/people

[SorenS]

Tu utilises des cookies pour quoi php_addict ?

Perso, c'est pareil que Sephi. Cookie pour la persistance de la connexion et ... c'est tout ^^

[php_addict]

je m'en sert pour enregistré côté client des paramètres optionnels choisis par le joueur, des trucs à afficher ou pas, rien d'essentiel pour le jeu, on peut voir ca comme des options de design pour l'interface graphique, ce genre de truc quoi

par contre pour l'exemple de Sephi-Chan, "l'id du village courant" c'est en SESSION

[Sephi-Chan]

Pourquoi ne pas lire ces informations dans la table de l'utilisateur afin de le prendre en compte à l'affichage ? Ainsi, aucune surcharge systématique de tes headers HTTP.

par contre pour l'exemple de Sephi-Chan, "l'id du village courant" c'est en SESSION

Y a-t-il une raison particulière à ce choix ?
Penses-tu qu'il a des avantages (notamment à l'utilisation) ?
Que penses-tu d'avoir l'état dans l'URL ?

[php_addict]

Pourquoi ne pas lire ces informations dans la table de l'utilisateur afin de le prendre en compte à l'affichage ? Ainsi, aucune surcharge systématique de tes headers HTTP.

euh..bonne question, ah oui: navigateur mobile sur un client et navigateur desktop sur un pc d'où le côté client de la chose...(ouf j'ai faillis oublié ce pourquoi j'avais opté pour les cookies...)

par contre pour l'exemple de Sephi-Chan, "l'id du village courant" c'est en SESSION

Y a-t-il une raison particulière à ce choix ?
Penses-tu qu'il a des avantages (notamment à l'utilisation) ?
Que penses-tu d'avoir l'état dans l'URL ?

l'état dans l'url est assez séduisant en effet mais j'ai opté pour les SESSIONS car c'était les villages étaient le premier module de mon code et je ne voyait que cette façon de faire à l'époque...

[Sephi-Chan]

Pourquoi ne pas lire ces informations dans la table de l'utilisateur afin de le prendre en compte à l'affichage ? Ainsi, aucune surcharge systématique de tes headers HTTP.

euh..bonne question, ah oui: navigateur mobile sur un client et navigateur desktop sur un pc d'où le côté client de la chose...(ouf j'ai faillis oublié ce pourquoi j'avais opté pour les cookies...)

Ton site a conscience qu'il est affiché en version mobile, non ? Si oui, tu peux lire les informations dont tu as besoin (en l'occurrence, les préférences mobiles).

par contre pour l'exemple de Sephi-Chan, "l'id du village courant" c'est en SESSION

Y a-t-il une raison particulière à ce choix ?
Penses-tu qu'il a des avantages (notamment à l'utilisation) ?
Que penses-tu d'avoir l'état dans l'URL ?

l'état dans l'url est assez séduisant en effet mais j'ai opté pour les SESSIONS car c'était les villages étaient le premier module de mon code et je ne voyait que cette façon de faire à l'époque...

Ok, c'est donc une raison historique.
Vive les frameworks ! :p

[php_addict]

Ton site a conscience qu'il est affiché en version mobile, non ? Si oui, tu peux lire les informations dont tu as besoin (en l'occurrence, les préférences mobiles).

tu veut dire détection de la résolution navigateur? c'est assez peu fiable comme donnée.

[Sephi-Chan]

Pas la résolution, mais le user agent. Je n'ai jamais eu à me plaindre de la fiabilité de cette technique (que je sois côté utilisateur ou développeur).
Si le mec change le user agent de son smartphone, c'est son problème après-tout.

[niahoo]

Tu regardes simplement l'user-agent

Moi ce que je n'aime pas avec le système de sessions c'est que si on veut gérer plusieurs villages en même temps sur plusieurs onglets on ne peut pas. Et pire encore, quand on ne sait pas qu'on ne peut pas et qu'on le fait quand même ça donne des trucs pas cools.

Genre :

Onglet 1 :
- création d'un village de test
- bidouilles sans importance

Onglet 2 : Ouverture du village principal, (200 jours de jeu)
- on regarde un truc pour comparer au village de test

Onglet 1 :
- [tout ce que tu fais ici s'applique au village principal]
- suppression par exemple ...

Ouverture d'un onglet 3 : http://fr.wikipedia.org/wiki/Nœud_de_pendu