Amélioration de la gestion des cookies

Salut !

Pour diverses raisons, j'ai entrepris la création d'une classe JavaScript qui gère la bannière d'acceptation/rejet des cookies de tracking.

Pourquoi c'est mieux que ce qu'il y a en ce moment ?

Actuellement, l'id UA-XXXX… est en dur dans le JS. La classe que j'ai faite laisse ce code dans les templates, donc vous pourrez variabiliser cette donnée.

Le code actuel ne prend pas en compte DoNotTrack.

Si on se rend sur la page "En savoir plus" les cookies sont acceptés, or si on clic sur le lien du bandeau pour aller vers cette page, le choix ne devrait pas encore être fait. Le bandeau devrait être encore visible. Ce que fait la classe que j'ai réalisé.

C'est codé en JavaScript pur, pas besoin de jQuery.

En clair, utiliser ce petit code reviendrait à retirer le fichier cookies-banner.js et à appliquer ce qui est indiqué ici : https://github.com/Alex-D/cookies-cnil-banner

Je prévois de mettre le script sur bower, ça permettra de simplifier l'installation et la maintenance.

Done : bower install cookies-cnil-banner --save

En espérant que cette modeste contribution soit implémentée

Salut,

j'ai une question : que ce passe t'il pour quelqu'un qui n'a pas de JS d'activé ?

Sinon a part ça, si tu pense que ce sera mieux géré ainsi, je ne vois pas d'objection à ce que tu fasse une PR pour le mettre sur le dépot.

que ce passe t'il pour quelqu'un qui n'a pas de JS d'activé ?

Nous sommes en 2015, la JavaScript est "obligatoire".

Si on prend en compte le cas où il est désactivé : Google Analytics sera également désactivé puisque lui-même est fait en JavaScript. Du coup, pas le problème à ce niveau. Et de toute façon la CNIL ne couvre pas le cas où le JS n'est pas activé, donc je ne sais pas ce qu'il se passe dans le cas d'iframe ou autres.

je ne vois pas d'objection à ce que tu fasse une PR pour le mettre sur le dépot.

Why not en effet.

Si GA n'injecte pas de cookies si on a pas de JS, en effet ce n'est pas un problème puisque le bandeau de la CNIL n'est alors plus obligatoire.

Pour information, on a viré Boxer donc soit tu le met disponible pour npm, soit on copie ton code.

npm c'est de la dépendance node, c'est bizarre de mettre tout dessus… bower c'est pur front.

De toute façon techniquement j'ai déjà le package.json j'ai pas grand chose à faire pour qu'il soit sur npm je pense.

soit on copie ton code.

Ça c'est nul pour la maintenance.

Aujourd'hui on a un site parfaitement fonctionnel sans JavaScript (j'écris ce message sans JS là).

Autant je comprendrais qu'on puisse décider que le JavaScript soit obligatoire pour un site en 2015 ; autant "gérer le bandeau de cookies imposé par la CNIL" ne me paraît pas être une raison valable pour imposer le JavaScript.

Autant je comprendrais qu'on puisse décider que le JavaScript soit obligatoire pour un site en 2015 ; autant "gérer le bandeau de cookies imposé par la CNIL" ne me paraît pas être une raison valable pour imposer le JavaScript.

Apres si j'ai bien compris, on s'en fout un peu ici. Si le JS n'est pas activé, GA n'injecte pas son cookie et donc il n'y a pas de raisons de la présenter. Donc techniquement en faisant un truc ainsi, on reste compatible sans JS et on évite de le présenter à des gens qui ne sont pas concernés.

OK. Donc plus généralement, si :

• La solution est meilleure que le fonctionnement actuel (ici en particulier ça dégage l'ID en dur dans le code),
• Et qu'elle n'introduit pas de régression (ici le fonctionnement légal imposé par la CNIL, le fonctionnement du site sans JS et la maintenance)

Alors, la PR est la bienvenue

J'ai une autre question : concrètement quel est l’intérêt de cette nouvelle solution vis a vis de celle existante ? Car bon, à froid, je vois mal l’intérêt mit a part la variabilisation de l'ID de GA. Pourquoi aller se prendre une dépendance externe supplémentaire, qu'est ce que ça nous apporterait ? Car sa mise en place va demander à aller toucher le code actuel, je ne suis pas surs que virer l'ID en dur dans le code actuel soit beaucoup plus long.

Kje : pourquoi recoder cette partie soi-même quand on a un équivalent propre, mieux que l'ancien et mis à jour sans devoir faire une PR ?

Si je voulais être taquin, je dirais que cette partie a déjà été codée et que je ne vois pas de raisons logiques de la mettre à jour (sauf évolution de la législation) ; et que donc en vertu de la loi qui dit "On ne touche pas quelque chose qui fonctionne" ce bout de code n'aurait pas d'intérêt dans ce cas précis.

Cela dit, appliquer cette règle à la lettre est garantie d'immobilisme ; et les vraies règles d'acceptation de la PR sont dans mon message précédent.

PS : Par contre, ce genre de règle est effectivement appliqué dans certains projets.

Kje : pourquoi recoder cette partie soi-même quand on a un équivalent propre, mieux que l'ancien et mis à jour sans devoir faire une PR ?

Bin ma question est justement en quoi il est mieux que l'ancien ! Parce que je ne suis pas surs que récupérer une dépendance externe uniquement pour ne plus avoir l'ID de GA en dur vaille le coup. L'autre solution n'est pas de recoder un truc, c'est simplement sortir cet ID qui est en dur. On ne re-developpe rien, on évite de changer un code qui fonctionne et on évite une dépendance.

Je ne dis pas qu'on ne devrait pas le faire, je demande juste ce que va apporter cette modif concrètement.

Voyez, c'est typiquement pour ça que j'ai quitté le développement de ZdS. Je fais un post qui explique pourquoi ça serait mieux, et s'en suit des questions qui trouvent leur réponse dans l'OP.

Pourquoi JavaScript ? Parce que GA fonctionne AVEC JavaScript, donc si pas de JS, pas de GA, donc pas de cookie => rien à gérer.

Pourquoi c'est mieux ? Je me cite :

Actuellement, l'id UA-XXXX… est en dur dans le JS. La classe que j'ai faite laisse ce code dans les templates, donc vous pourrez variabiliser cette donnée.

Le code actuel ne prend pas en compte DoNotTrack.

Si on se rend sur la page "En savoir plus" les cookies sont acceptés, or si on clic sur le lien du bandeau pour aller vers cette page, le choix ne devrait pas encore être fait. Le bandeau devrait être encore visible. Ce que fait la classe que j'ai réalisé.

En somme, ça fonctionne, mais ça ne répond pas à la législation (entre autre car non-support de Do Not Track et parce qu'aller sur la page En savoir plus nous oblige à accepter les cookies au moins sur cette page).

Et ça vous déporte le tag UA d'un JS "uglifyé" par gulp (si ça n'a pas changé) à un template où vous pouvez mettre une simple variable en 2-2.

Encore plus résumé : ça résout des problèmes de législation et ça vous corrige un problème technique qui est ce code UA qui traîne dans le dépôt à une place où il ne devrait pas.

En somme, ça fonctionne, mais ça ne répond pas à la législation (entre autre car non-support de Do Not Track et parce qu'aller sur la page En savoir plus nous oblige à accepter les cookies au moins sur cette page).

Je ne comprends pas cet argument. On avait exprès pris le code de la CNIL sans autre modification que le design justement pour que ça corresponde à la législation sans qu'on ait besoin de réfléchir à quoi que ce soit.

PS : en tant que DTC de ce projet, je trouve ça vachement inquiétant qu'un comportement ne fonctionne pas comme il était prévu qu'il fonctionne.

On avait exprès pris le code de la CNIL

On a pas du tout pris le code de la CNIL. Autant pour Do Not Track on a merdé à ce moment là, autant pour la gestion de la page "En savoir plus" c'est une modification qui a été faite sur demande, à savoir : le code proposé par la CNIL affiche la bannière jusqu'à acceptation/refus des cookies. Sur ZdS il a été demandé de procéder de la façon "à la prochaine page, on considère que c'est accepté". Du coup ça n'a pas été prévu pour car c'est un cas qui nous échappé.

Ensuite, ça corrige également des soucis de SEO qu'on mal corrigé à l'époque, Cf. Google.

Maintenant, je propose un gros patch, propre, qui sera documenté et maintenu et je me fais limite gueuler dessus.

Bref, moi j'arrête là la conversation et je vous laisse le loisir d'appliquer ou non ce script que je vous propose. Je ne ferais probablement pas la PR car je n'ai plus rien de ZdS sur ma machine et que ça prendra 5 secondes à des dev front actuel.

. Sur ZdS il a été demandé de procéder de la façon "à la prochaine page, on considère que c'est accepté".

Vraiment ? Je ne me souviens pas de cette conversation, ça m'ettone mais j'ai pas tout suivi.

Pour le reste, comme tu veux. Moi je ne vois pas ou tu te fais engueuler. Tu propose quelque chose, on en discute comme de tout. Perso je ne vois pas ce qu'il y a de choquant a dicuter de l'ajout d'une dépendance pour un truc qui, jusqu'ici, fonctionne et n'a pas provoqué de remonté de bugs. Par exemple l'obligation du support du do not track, je ne le savais pas et je ne le pensais pas nécessaire vu la tonne de site qui ne le respectent pas.

Si tu veux pas faire la pr, comme tu veux, mais ne nous reproche pas de débattre d'un point qui a une influence sur le code.

Je suis en train de réalisé mon site web : [URL modérée] et je cherche des réponse pour l’utilisation des cookies, avez vous des pistes ?

Merci par avance !

@webmagnetsite Bienvenue sur Zds ! N’hésite pas à te présenter sur ce sujet pour permette à la communauté d’en savoir plus sur toi

Si les suggestions apportées sur ce sujet ne suffisent pas à t’aider, je te suggère d’ouvrir un nouveau sujet pour éviter de déterrer une discussions abandonnée depuis près de 10 ans.

Au passage, on essaye de limiter la pub et le spam SEO sur ZdS, j’ai donc supprimé l’URL de ton message par précaution. Merci de limiter cela uniquement à des partages où l’ajout d’une URL est essentiel à la compréhension (par exemple pour partager un page où il y a un bug, ou un document de référence).