La gestion des cookies en Javascript :
Le concepteur des pages html que vous lisez a parfois besoin, pour l’utilisation de son site, de cookies afin de s’y référer, et éventuellement pour sauvegarder la configuration pour vos prochaines visites. Comme les pages se trouvent sur le web, et que tout utilisateur peut potentiellement y accéder, ces données peuvent difficilement être sauvegardées sur le site lui-même. Imaginez, par exemple, un site comme celui de microsoft qui a plusieurs millions de visiteurs, ou le concepteur devrait effectuer une recherche pour accéder aux données relatives à ses pages, mais propres à votre lecture ? Le temps d’accès risque d’être long... très long. C’est pour cela qu’on a inventé le cookie. Cela permet de sauver quelques informations sur le disque de l’utilisateur, informations qui ne seront relatives qu’à sa lecture propre, puisqu’elles ne pourront pas être utilisées pour un autre utilisateur, qui lui, aura ses propres informations sauvées sur son disque dur.
Y a-t-il un risque à accepter un cookie ?
Ma fois, le seul risque encouru, c’est celui de vous faciliter la vie. En effet, un cookie étant une chaine de caractères au format texte, les risques liés au virus sont inexistants. Comme il est impossible de lire la valeur d’un cookie depuis un site web si ce cookie a été placé depuis un autre site web, abandonnez toute idée paranoïaque, le risque d’être espionné nominativement est inexistant. Par contre, si un concepteur veut placer un cookie sur votre disque, il y a de fortes chances pour qu’il s’en serve afin de vous aider dans la visite de son site. Il s’y réfèrera probablement lors de vos prochaines visites, soit pour vous amener directement à la page à laquelle vous étiez arrivé, soit pour configurer l’apparence de ses pages en fonction de vos critères de préférence (version avec ou sans frames, couleurs de fonds....)
Pourquoi refuser ou accepter qu’un auteur place un cookie ?
Comme nous venons de le voir, dans la majorité des cas, il n’y a aucune raison de refuser le placement d’un cookie. Le seul cas dans lequel vous pourriez être ammené à le refuser, c’est lorsque vous avez dit à votre femme que vous ne vous connecteriez pas à internet tel ou tel jour, et que vous le faites quand-même. Et encore faudrait-il qu’elle-même s’y connecte et visite les mêmes sites que vous pour éventuellement s’en apercevoir. Plus sérieusement, vu que les seules données accessibles par le concepteur sont soit celles qu’il connait déjà, soit celles que vous lui communiquez, il n’y a pas vraiment de bonne raison pour refuser un cookie.
Principe du cookie :
Le cookie est une chaine de caractères qui est sauvegardée sur votre disque dur. Afin d’éviter tout message d’erreur lorsque vous travaillez sur vos cookies, il y a une certaine marche à suivre. Dans l’ordre, il faudra :
Vérifier son existence.
Eventuellement créer le cookie inexistant.
Lire la valeur du cookie.
Sauvegarder celui-ci.
Effacer les cookies dont vous n’aurez plus besoin.
Si vous n’effectuez pas les opérations dans cet ordre là, vous risquez d’essayer de lire un cookie qui n’existe pas, ce qui provoque une erreur de langage. Examinons en détail les différentes étapes de la gestion du cookie :
1.Vérification de l’existence du cookie.
function VerCookie(Name) {
var search = Name + "="
if (document.cookie.length > 0) {
// si il existe au moins un cookie
offset = document.cookie.indexOf(search)
if (offset != -1) {
// si le cookie recherché existe
return offset
}
else {
//le cookie n'existe pas
return -1
}
}
} C’est toujours dans le but d’éviter les messages d’erreur que l’on vérifie si il existe au moins un cookie, avant de vérifier si le cookie recherché existe bien.
2.Création d’un cookie (ou sauvegarde de la valeur d’un cookie).
function setCookie(name, value, expire) {
// dans cet exemple, expire est un nombre de jours.
if (expire != null) {
var today = new Date()
var expires = new Date()
expires.setTime(today.getTime() + 60*60*24*1000*expire)
expire = expires
}
document.cookie = name + "=" + escape(value)
+ ((expire == null) ? "" : ("; expires=" + expire.toGMTString()))
} La fonction toGMTString() permet d’être certain du moment d’expiration du cookie, quel que soit le pays depuis lequel le cookie a été lu. Cela n’aura généralement pas d’importance, mais dans certains cas, vous aurez peut-être à éviter qu’un cookie disparaisse près de 24 heures avant celui d’un autre utilisateur.
3.Lecture de la valeur d’un cookie
Cette fonction ressemble à la fonction VerCookie. En fait, elles sont identiques, jusqu’à ce que l’on ait vérifié l’existence de notre cookie, mais cette fonction-ci déterminera également sa valeur, alors que l’autre fonction ne faisait que vérifier la présence de celui-ci.
function LitCookie(Name) {
var search = Name + "="
if (document.cookie.length > 0) {
// si il existe au moins un cookie
offset = document.cookie.indexOf(search)
if (offset != -1) {
// si le cookie recherché existe
offset += search.length ;
//détermine la position de début de la valeur du cookie.
end = document.cookie.indexOf(";", offset)
// détermine la position de la fin de la valeur du cookie
if (end == -1)
end = document.cookie.length
return unescape(document.cookie.substring(offset, end))
}
}
} 4.Effacement d’un cookie.
C’est simple : pour effacer votre cookie, appelez la fonction setCookie(), en donnant une valeur décimale à expire. Cela donnera une valeur d’expiration de votre cookie inférieur à un jour. En effet, si expire = 1, cela représente 24 heures à partir du moment ou vous écrivez votre cookie. (1000 millième de secondes * 60 seondes * 60 minutes * 24 heures) Vous pouvez également lui donner une valeur négative, dans ce cas, le cookie sera effacé car sa date d’expiration sera dépassée.
En tant qu’utilisateur, puis-je lire la valeur des cookies ? Puis-je les modifier ou les utiliser ?
Non. Du moins, pas comme vous l’entendez. Expliquons-nous :
Vous ne pourrez pas lire un cookie et en utiliser les valeurs depuis votre browser, car votre page ne sera pas celle qui a placé le cookie.
A plus forte raison, vous ne pourrez pas modifier la valeur de ceux-ci depuis votre browser.
Comme Netscape ne sauvegarde les cookies que l’on vient de modifier ou de placer que lorsque vous terminez votre session internet, même depuis un éditeur de texte vous ne pourrez pas en vérifier directement la valeur.
Par contre, ces cookies sont sauvegardés dans un fichier au format texte, dans un sous répertoire de Netscape. Ce fichier s’appelle tout simplement : cookie.txt. (Notons qu’Internet Explorer crée un répertoire par site utilisant un cookie... Pourquoi faire simple quand on peut faire compliqué ?) La lecture du cookie ne vous apprendra pas grand chose, juste les adresses des pages ayant servi à placer le cookie, et la valeur de ceux-ci. Eventuellement, la date de placement et d’expiration de celui-ci. Les valeurs et les noms étant propres au concepteur du site, leur lecture ne sera pas très passionnante, sauf si :
Vous travaillez de concert avec le concepteur du site, et ce dans le but de vous permettre de relire cette valeur et de l’interpréter (dans ce cas, cela se fera au moyen d’un logiciel propre, que vous aurez soit conçu, soit acquis auprès du concepteur du site).
Le cookie sauvegardé n’est pas crypté et vous pouvez facilement en déduire sa signification. Par exemple, un cookie nommé user avec une valeur correspondant à votre nom.Mais dans ce cas, est-ce intéressant de le lire ?
Comme concepteur de pages web, puis-je utiliser le cookie pour sauver un mot de passe ?
Soyons clair : Une gestion de mots de passe par cookies n’est pas le meilleur moyen. C’est réalisable, mais presque n’importe quel utilisateur connaissant un peu le langage html sera capable de passer outre. Sauf si vous compléter ce moyen avec un programe CGI. En effet, pour placer le cookie, votre utilisateur devra se présenter sur une page de votre site, afin de "s’enregistrer". Cette page contiendra dans son code source, le nom du cookie à sauver. N’importe qui pourra donc y accéder et déterminer quel cookie doit contenir la valeur d’un mot de passe. Cela fait, pour pénétrer sur votre site, il devra se présenter sur une page de vérification "d’identité". Cette page lira le cookie, mais devra en comparer la valeur avec une valeur contenue dans le code source de votre page. Quelqu’un de mal intentionné pourra donc facilement sauver cette page afin d’y lire la valeur demandée au cookie, et, de là , aller sur la page d’enregistrement afin de s’y faire enregister en entrant les données requises. Considérons donc que ce moyen est utilisable afin de ne décourager que l’utilisateur "accidentel", afin de lui éviter d’entrer par mégarde dans une partie de votre site que vous préfèrez réserver à certains utilisateurs privilégiés. Par contre, si vous cherchez un moyen de préserver vos pages contre des lecteurs mal intentionnés, faites plutôt appel à un concepteur de programmes. C’est quand même plus adapté. Pour ceux qui voudraient malgré tout s’essayer à la conception d’un mot de passe, cette méthode, parmi beaucoup d’autres, me semble l’une des moins mauvaises. Mais une fois encore, insistons sur le fait que ce n’est ni la meilleure, ni la plus sécure.
Inconvénients du cookie
-Taille maximum
Chaque cookie ne peut excéder une taille de 4 kilobyte (environs 4000 caractères). Si c’est juste pour pouvoir sauvegarder le nom de l’utilisateur et son nombre de visites sur votre site, afin, par exemple, de créer une page personnalisée lui souhaitant la bienvenue, c’est plus que suffisant. Par contre, si vous vous servez des cookies à un niveau commercial, afin que vos utilisateurs puissent passer des commandes directement sur votre site, et afin de pouvoir vous y référer lors des visites suivantes, et que vous comptez y stocker beaucoup de données, vous risquez rapidement de manquer de place. Il est à noter que dans ce cas, le cookie n’est pas le meilleur des moyens. Il vaudrait peut-être mieux passer par un programme dit "CGI" et faire appel a un programmeur compétent.
- Nombre limité
Chaque concepteur n’a droit "qu’à" 20 cookies différents. Pour les propriétaires de sites propres, c’est en principe suffisant. Par contre, si, comme moi, vous êtes un simple utilisateur qui "s’amuse" à placer un cookie, l’adresse de vos pages se trouve chez votre provider. Et pour peu qu’il en utilise lui-même, il y a un risque pour que vos propres cookies ne puissent pas être sauvegardés sur le disque de vos visiteurs. De plus, et ici, c’est dans le but de ne pas sur-encombrer les disques des utilisateurs, le nombre total de cookies pouvant être sauvés sur le disque d’un utilisateur est de 300 cookies, tous sites confondus.
- Liaison à l’emplacement de la page
Si vous avez un site permanent sur le web, pas de problème. Vous sauverez vos cookies en permanence, et vous pourrez les relire sans trop de problèmes (pour autant que les conditions précédentes soient respectées). Par contre, si vous avez déjà lu la page expliquant comment transformer son ordinateur en serveur web, et que vous avez décidé d’appliquer cette technique, l’utilisation du cookie va devenir un réel problème. En effet, à chaque fois que vous vous connecterez au réseau, il y a de grandes chances pour que votre numéro de modem (dial) soit différent de celui de votre connexion précédente. Lorsque je me connecte chez mon provider actuel, ping.be, je me connecte sur le serveur liégeois, qui est une ville relativement petite, mais ou plus de 150 modems différents existent. Je ne pourrai donc, en moyenne, relire mes cookies qu’une fois sur 150. Et la possibilité pour qu’un utilisateur vienne lire mes pages deux fois de suite avec une connexion (de ma part) sur le même modem que la fois précédente est pour ainsi dire inexistante. Dans ce cas, l’utilisation sûre d’un cookie est complètement impossible, puisque la possibilité de les relire sera complètement aléatoire.
Si mes pages sont déplacées, comment conserver mes anciens cookie ?
Le seul moyen, c’est d’avoir encore accès depuis l’ancien emplacement, et à condition que celui-ci soit fixe. De cet endroit, vous lisez les valeurs de vos anciens cookies, que vous placez dans une variable. Puis, vous appelez une page sur votre nouvel emplacement, avec un paramètre contenant la valeur de vos cookies. Par exemple, si vous avez deux cookies appelés user et value, vous les lirez sur votre premier emplacement : user = Lazone et value = monpass. Puis, vous appellerez votre nouvelle page, par exemple http://www.cookie.com/index.htm avec un paramètre de recherche tel que : http://www.cookie.com/index.htm?use... Il ne vous restera plus qu’à analyser la ligne de commande au moyen d’une petite fonction, ce qui vous permettra de retrouver les valeurs et les noms de vos cookies.
Source : le site des débutants en programmation que nous vous conseillons vivement pour trouver une foule de trucs et astuces concernant l’HTML.
UN EXEMPLE BIEN CONCRET
Voici le script que j’utilise dans mes pages d’articles, pour qu’une pop-up vous propose de vous inscrire à la newsletter, cette invite se fera tous les 90 jours, car si elle apparaissait à chaque page, je vous entendrais me maudire jusqu’ici...
<SCRIPT LANGUAGE="JavaScript">
var expDays = 90;
var page = "http://votrepage";
var windowprops = "width=700,height=340,location=no,toolbar=no,
menubar=no,scrollbars=no,resizable=no";
function GetCookie (name) {
var arg = name + "=";
var alen = arg.length;
var clen = document.cookie.length;
var i = 0;
while (i < clen) {
var j = i + alen;
if (document.cookie.substring(i, j) == arg)
return getCookieVal (j);
i = document.cookie.indexOf(" ", i) + 1;
if (i == 0) break;
}
return null;
}
function SetCookie (name, value) {
var argv = SetCookie.arguments;
var argc = SetCookie.arguments.length;
var expires = (argc > 2) ? argv[2] : null;
var path = (argc > 3) ? argv[3] : null;
var domain = (argc > 4) ? argv[4] : null;
var secure = (argc > 5) ? argv[5] : false;
document.cookie = name + "=" + escape (value) +
((expires == null) ? "" : ("; expires=" + expires.toGMTString())) +
((path == null) ? "" : ("; path=" + path)) +
((domain == null) ? "" : ("; domain=" + domain)) +
((secure == true) ? "; secure" : "");
}
function DeleteCookie (name) {
var exp = new Date();
exp.setTime (exp.getTime() - 1);
var cval = GetCookie (name);
document.cookie = name + "=" + cval + "; expires=" + exp.toGMTString();
}
var exp = new Date();
exp.setTime(exp.getTime() + (expDays*24*60*60*1000));
function amt(){
var count = GetCookie('count')
if(count == null) {
SetCookie('count','1')
return 1
}
else {
var newcount = parseInt(count) + 1;
DeleteCookie('count')
SetCookie('count',newcount,exp)
return count
}
}
function getCookieVal(offset) {
var endstr = document.cookie.indexOf (";", offset);
if (endstr == -1)
endstr = document.cookie.length;
return unescape(document.cookie.substring(offset, endstr));
}
function checkCount() {
var count = GetCookie('count');
if (count == null) {
count=1;
SetCookie('count', count, exp);
window.open(page, "", windowprops);
}
else {
count++;
SetCookie('count', count, exp);
}
}
</script>
RSS 2.0