Est-ce que quelqu'un saurait s'il est possible en Javascript d'identifier de
manière unique une machine X qui accède à un site Web à plusieurs reprises
(soit à partir du navigateur Web ou bien par l'intermédiaire de l'OS de la
machine) ?
Mes conditions sont les suivantes :
Je ne souhaite pas utiliser l'identification par @ IP car l'IP
peut varier d'une connexion à l'autre à partir de la même machine, d'où un
risque de refus d'accès à la bonne machine X.
Je ne souhaite pas non plus utiliser l'identification par cookie car ce
dernier peut être exporté d'une machine à une autre (pas très secure ...).
Je ne souhaite pas non plus utiliser la signature d'un navigateur car j'ai
l'impression que cette signature peut être la même entre deux navigateurs de
même version sur deux machines distinctes.
2) Tout à fait, mais s'il le cookie est transférer dans une machine B et que l'utilisateur B connait le login et password de A, il peut accèder à la page de A, non ? En fait l'accès à la page A est un achat sur Internet qu'il faut absolument sécirisé pour éviter que l'acheteur (utilisateur A) ne le transmettre à d'autres sans paiement. D'où la nécessite d'identifier une machine plutôt que via cookie (plus risqué). L'utilisateur A pourvant communiqué son login et password à n'importe qui souhaite accèder au service sans payer.
Il faut me donner l'adresse de ce magazin car si je ne puis, par mon abonnement *payant* me connecter d'où je veux, ça va pas faire.
Maintenant, il faudrait peut-être voir du côté des certificats. Mais tu auras toujours le même problème, l'abonné pourra toujours sous-louer son certificat (ça m'a l'air encore plus facile à filer qu'un cookie, bien que n'ayant jamais essayé ni l'un ni l'autre). Bon ... quand il verra qu'il peut pas se loguer parce que les sous-locataires y sont déjà : il paiera pour des prunes et ce ne sera que son problème ... !
Je n'arrive pas bien à comprendre où est le problème, car ça m'étonnerait qu'il y ait beaucoup de contrebande, dans la mesure où A ne devrait pouvoir se logguer à la page A qu'un à la fois.
3) Le cookie me parait pas très secure, on peut assez facilement le copier et le charger sur un autre poste.
3a) je voudrais voir ça
3b) il y a des dates avec les cookies il devrait suffire de les vérifier : A1 se connecte à 11h et déconnecte à 11h30 et file le cookie à A2 vers 15 h 2 cas de figures : - A2 se connecte à 15h10 et se déconnecte à 16h A1 ne peut se reconnecter pendant ce temps et râle de sa bétise A1 se reconnecte à 16h10 avec son cookie de 15h Quoi ? quoi ? Ha mais non ! normalement ce devrait être 16h ! - A1 se reconnecte à 15h10 et se déconnecte à 16h A2 ne peut se reconnecter pendant ce temps et comprend pas que ça ne fonctionne pas A2 se connecte à 16h10 avec son cookie de 15h Quoi ? quoi ? Ha mais non ! normalement ce devrait être 16h !
De toutes façons tout ça ce sont des questions à régler côté serveur, le JavaScript n'a certainement pas grand' chose à y voir. Il y a toute une panoplie en php pour les accès plus ou moins sécurisés. (sessions, cookies à l'heure du site, Base de données, étoussa)
Y a qu'à voir ce petit échange/forum rien que pour l'histoire de l'IP : http://www.javascriptfr.com/codes/DETECTER-IP_15787.aspx
-- Stephane Moriaux et son (moins) vieux Mac déjà dépassé
2) Tout à fait, mais s'il le cookie est transférer dans une machine B et que
l'utilisateur B connait le login et password de A, il peut accèder à la page
de A, non ?
En fait l'accès à la page A est un achat sur Internet qu'il faut absolument
sécirisé pour éviter que l'acheteur (utilisateur A) ne le transmettre à
d'autres sans paiement. D'où la nécessite d'identifier une machine plutôt
que via cookie (plus risqué). L'utilisateur A pourvant communiqué son login
et password à n'importe qui souhaite accèder au service sans payer.
Il faut me donner l'adresse de ce magazin car si je ne puis, par mon
abonnement *payant* me connecter d'où je veux, ça va pas faire.
Maintenant, il faudrait peut-être voir du côté des certificats.
Mais tu auras toujours le même problème, l'abonné pourra toujours
sous-louer son certificat (ça m'a l'air encore plus facile à filer qu'un
cookie, bien que n'ayant jamais essayé ni l'un ni l'autre).
Bon ... quand il verra qu'il peut pas se loguer parce que les
sous-locataires y sont déjà : il paiera pour des prunes et ce ne sera
que son problème ... !
Je n'arrive pas bien à comprendre où est le problème, car ça
m'étonnerait qu'il y ait beaucoup de contrebande, dans la mesure où A ne
devrait pouvoir se logguer à la page A qu'un à la fois.
3) Le cookie me parait pas très secure, on peut assez facilement le copier
et le charger sur un autre poste.
3a) je voudrais voir ça
3b) il y a des dates avec les cookies
il devrait suffire de les vérifier :
A1 se connecte à 11h et déconnecte à 11h30
et file le cookie à A2 vers 15 h
2 cas de figures :
- A2 se connecte à 15h10 et se déconnecte à 16h
A1 ne peut se reconnecter pendant ce temps et râle de sa bétise
A1 se reconnecte à 16h10 avec son cookie de 15h
Quoi ? quoi ? Ha mais non ! normalement ce devrait être 16h !
- A1 se reconnecte à 15h10 et se déconnecte à 16h
A2 ne peut se reconnecter pendant ce temps et comprend pas que
ça ne fonctionne pas
A2 se connecte à 16h10 avec son cookie de 15h
Quoi ? quoi ? Ha mais non ! normalement ce devrait être 16h !
De toutes façons tout ça ce sont des questions à régler côté serveur, le
JavaScript n'a certainement pas grand' chose à y voir.
Il y a toute une panoplie en php pour les accès plus ou moins sécurisés.
(sessions, cookies à l'heure du site, Base de données, étoussa)
Y a qu'à voir ce petit échange/forum rien que pour l'histoire de l'IP :
http://www.javascriptfr.com/codes/DETECTER-IP_15787.aspx
--
Stephane Moriaux et son (moins) vieux Mac déjà dépassé
2) Tout à fait, mais s'il le cookie est transférer dans une machine B et que l'utilisateur B connait le login et password de A, il peut accèder à la page de A, non ? En fait l'accès à la page A est un achat sur Internet qu'il faut absolument sécirisé pour éviter que l'acheteur (utilisateur A) ne le transmettre à d'autres sans paiement. D'où la nécessite d'identifier une machine plutôt que via cookie (plus risqué). L'utilisateur A pourvant communiqué son login et password à n'importe qui souhaite accèder au service sans payer.
Il faut me donner l'adresse de ce magazin car si je ne puis, par mon abonnement *payant* me connecter d'où je veux, ça va pas faire.
Maintenant, il faudrait peut-être voir du côté des certificats. Mais tu auras toujours le même problème, l'abonné pourra toujours sous-louer son certificat (ça m'a l'air encore plus facile à filer qu'un cookie, bien que n'ayant jamais essayé ni l'un ni l'autre). Bon ... quand il verra qu'il peut pas se loguer parce que les sous-locataires y sont déjà : il paiera pour des prunes et ce ne sera que son problème ... !
Je n'arrive pas bien à comprendre où est le problème, car ça m'étonnerait qu'il y ait beaucoup de contrebande, dans la mesure où A ne devrait pouvoir se logguer à la page A qu'un à la fois.
3) Le cookie me parait pas très secure, on peut assez facilement le copier et le charger sur un autre poste.
3a) je voudrais voir ça
3b) il y a des dates avec les cookies il devrait suffire de les vérifier : A1 se connecte à 11h et déconnecte à 11h30 et file le cookie à A2 vers 15 h 2 cas de figures : - A2 se connecte à 15h10 et se déconnecte à 16h A1 ne peut se reconnecter pendant ce temps et râle de sa bétise A1 se reconnecte à 16h10 avec son cookie de 15h Quoi ? quoi ? Ha mais non ! normalement ce devrait être 16h ! - A1 se reconnecte à 15h10 et se déconnecte à 16h A2 ne peut se reconnecter pendant ce temps et comprend pas que ça ne fonctionne pas A2 se connecte à 16h10 avec son cookie de 15h Quoi ? quoi ? Ha mais non ! normalement ce devrait être 16h !
De toutes façons tout ça ce sont des questions à régler côté serveur, le JavaScript n'a certainement pas grand' chose à y voir. Il y a toute une panoplie en php pour les accès plus ou moins sécurisés. (sessions, cookies à l'heure du site, Base de données, étoussa)
Y a qu'à voir ce petit échange/forum rien que pour l'histoire de l'IP : http://www.javascriptfr.com/codes/DETECTER-IP_15787.aspx
-- Stephane Moriaux et son (moins) vieux Mac déjà dépassé
Steph
"ASM" a écrit dans le message de news: 45bd389b$0$25938$
2) Tout à fait, mais s'il le cookie est transférer dans une machine B et que l'utilisateur B connait le login et password de A, il peut accèder à la page de A, non ? En fait l'accès à la page A est un achat sur Internet qu'il faut absolument sécirisé pour éviter que l'acheteur (utilisateur A) ne le transmettre à d'autres sans paiement. D'où la nécessite d'identifier une machine plutôt que via cookie (plus risqué). L'utilisateur A pourvant communiqué son login et password à n'importe qui souhaite accèder au service sans payer.
Il faut me donner l'adresse de ce magazin car si je ne puis, par mon abonnement *payant* me connecter d'où je veux, ça va pas faire.
Maintenant, il faudrait peut-être voir du côté des certificats. Mais tu auras toujours le même problème, l'abonné pourra toujours sous-louer son certificat (ça m'a l'air encore plus facile à filer qu'un cookie, bien que n'ayant jamais essayé ni l'un ni l'autre). Bon ... quand il verra qu'il peut pas se loguer parce que les sous-locataires y sont déjà : il paiera pour des prunes et ce ne sera que son problème ... !
Je n'arrive pas bien à comprendre où est le problème, car ça m'étonnerait qu'il y ait beaucoup de contrebande, dans la mesure où A ne devrait pouvoir se logguer à la page A qu'un à la fois.
3) Le cookie me parait pas très secure, on peut assez facilement le copier et le charger sur un autre poste.
3a) je voudrais voir ça
3b) il y a des dates avec les cookies il devrait suffire de les vérifier : A1 se connecte à 11h et déconnecte à 11h30 et file le cookie à A2 vers 15 h 2 cas de figures : - A2 se connecte à 15h10 et se déconnecte à 16h A1 ne peut se reconnecter pendant ce temps et râle de sa bétise A1 se reconnecte à 16h10 avec son cookie de 15h Quoi ? quoi ? Ha mais non ! normalement ce devrait être 16h ! - A1 se reconnecte à 15h10 et se déconnecte à 16h A2 ne peut se reconnecter pendant ce temps et comprend pas que ça ne fonctionne pas A2 se connecte à 16h10 avec son cookie de 15h Quoi ? quoi ? Ha mais non ! normalement ce devrait être 16h !
De toutes façons tout ça ce sont des questions à régler côté serveur, le JavaScript n'a certainement pas grand' chose à y voir. Il y a toute une panoplie en php pour les accès plus ou moins sécurisés. (sessions, cookies à l'heure du site, Base de données, étoussa)
Y a qu'à voir ce petit échange/forum rien que pour l'histoire de l'IP : http://www.javascriptfr.com/codes/DETECTER-IP_15787.aspx
-- Stephane Moriaux et son (moins) vieux Mac déjà dépassé
Merci pour ces infos, je vais voir ce que je peux trouver.
"ASM" <stephanemoriaux.NoAdmin@wanadoo.fr.invalid> a écrit dans le message
de news: 45bd389b$0$25938$ba4acef3@news.orange.fr...
2) Tout à fait, mais s'il le cookie est transférer dans une machine B et
que l'utilisateur B connait le login et password de A, il peut accèder à
la page de A, non ?
En fait l'accès à la page A est un achat sur Internet qu'il faut
absolument sécirisé pour éviter que l'acheteur (utilisateur A) ne le
transmettre à d'autres sans paiement. D'où la nécessite d'identifier une
machine plutôt que via cookie (plus risqué). L'utilisateur A pourvant
communiqué son login et password à n'importe qui souhaite accèder au
service sans payer.
Il faut me donner l'adresse de ce magazin car si je ne puis, par mon
abonnement *payant* me connecter d'où je veux, ça va pas faire.
Maintenant, il faudrait peut-être voir du côté des certificats.
Mais tu auras toujours le même problème, l'abonné pourra toujours
sous-louer son certificat (ça m'a l'air encore plus facile à filer qu'un
cookie, bien que n'ayant jamais essayé ni l'un ni l'autre).
Bon ... quand il verra qu'il peut pas se loguer parce que les
sous-locataires y sont déjà : il paiera pour des prunes et ce ne sera que
son problème ... !
Je n'arrive pas bien à comprendre où est le problème, car ça m'étonnerait
qu'il y ait beaucoup de contrebande, dans la mesure où A ne devrait
pouvoir se logguer à la page A qu'un à la fois.
3) Le cookie me parait pas très secure, on peut assez facilement le
copier et le charger sur un autre poste.
3a) je voudrais voir ça
3b) il y a des dates avec les cookies
il devrait suffire de les vérifier :
A1 se connecte à 11h et déconnecte à 11h30
et file le cookie à A2 vers 15 h
2 cas de figures :
- A2 se connecte à 15h10 et se déconnecte à 16h
A1 ne peut se reconnecter pendant ce temps et râle de sa bétise
A1 se reconnecte à 16h10 avec son cookie de 15h
Quoi ? quoi ? Ha mais non ! normalement ce devrait être 16h !
- A1 se reconnecte à 15h10 et se déconnecte à 16h
A2 ne peut se reconnecter pendant ce temps et comprend pas que
ça ne fonctionne pas
A2 se connecte à 16h10 avec son cookie de 15h
Quoi ? quoi ? Ha mais non ! normalement ce devrait être 16h !
De toutes façons tout ça ce sont des questions à régler côté serveur, le
JavaScript n'a certainement pas grand' chose à y voir.
Il y a toute une panoplie en php pour les accès plus ou moins sécurisés.
(sessions, cookies à l'heure du site, Base de données, étoussa)
Y a qu'à voir ce petit échange/forum rien que pour l'histoire de l'IP :
http://www.javascriptfr.com/codes/DETECTER-IP_15787.aspx
--
Stephane Moriaux et son (moins) vieux Mac déjà dépassé
Merci pour ces infos, je vais voir ce que je peux trouver.
"ASM" a écrit dans le message de news: 45bd389b$0$25938$
2) Tout à fait, mais s'il le cookie est transférer dans une machine B et que l'utilisateur B connait le login et password de A, il peut accèder à la page de A, non ? En fait l'accès à la page A est un achat sur Internet qu'il faut absolument sécirisé pour éviter que l'acheteur (utilisateur A) ne le transmettre à d'autres sans paiement. D'où la nécessite d'identifier une machine plutôt que via cookie (plus risqué). L'utilisateur A pourvant communiqué son login et password à n'importe qui souhaite accèder au service sans payer.
Il faut me donner l'adresse de ce magazin car si je ne puis, par mon abonnement *payant* me connecter d'où je veux, ça va pas faire.
Maintenant, il faudrait peut-être voir du côté des certificats. Mais tu auras toujours le même problème, l'abonné pourra toujours sous-louer son certificat (ça m'a l'air encore plus facile à filer qu'un cookie, bien que n'ayant jamais essayé ni l'un ni l'autre). Bon ... quand il verra qu'il peut pas se loguer parce que les sous-locataires y sont déjà : il paiera pour des prunes et ce ne sera que son problème ... !
Je n'arrive pas bien à comprendre où est le problème, car ça m'étonnerait qu'il y ait beaucoup de contrebande, dans la mesure où A ne devrait pouvoir se logguer à la page A qu'un à la fois.
3) Le cookie me parait pas très secure, on peut assez facilement le copier et le charger sur un autre poste.
3a) je voudrais voir ça
3b) il y a des dates avec les cookies il devrait suffire de les vérifier : A1 se connecte à 11h et déconnecte à 11h30 et file le cookie à A2 vers 15 h 2 cas de figures : - A2 se connecte à 15h10 et se déconnecte à 16h A1 ne peut se reconnecter pendant ce temps et râle de sa bétise A1 se reconnecte à 16h10 avec son cookie de 15h Quoi ? quoi ? Ha mais non ! normalement ce devrait être 16h ! - A1 se reconnecte à 15h10 et se déconnecte à 16h A2 ne peut se reconnecter pendant ce temps et comprend pas que ça ne fonctionne pas A2 se connecte à 16h10 avec son cookie de 15h Quoi ? quoi ? Ha mais non ! normalement ce devrait être 16h !
De toutes façons tout ça ce sont des questions à régler côté serveur, le JavaScript n'a certainement pas grand' chose à y voir. Il y a toute une panoplie en php pour les accès plus ou moins sécurisés. (sessions, cookies à l'heure du site, Base de données, étoussa)
Y a qu'à voir ce petit échange/forum rien que pour l'histoire de l'IP : http://www.javascriptfr.com/codes/DETECTER-IP_15787.aspx
-- Stephane Moriaux et son (moins) vieux Mac déjà dépassé
Merci pour ces infos, je vais voir ce que je peux trouver.
Steph
"Olivier Miakinen" <om+ a écrit dans le message de news: 45bd1bfe$
4) Pas vraiment de commentaires sur ta dernière remarque ...
Dans ce cas pourquoi la citer ? D'une manière générale, surtout si tu réponds point par point, il vaudrait mieux mettre chaque réponse après chaque point cité, plutôt que tout en bloc à la fin du message (on est obligé de faire des tas d'allers-retours et c'est très pénible). Et puis bien sûr il faut supprimer ce qui ne sert à rien, par exemple la signature de celui à qui tu réponds.
Une lecture indispensable (en particulier 3.a et 3.b) : http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html
Ok, bien noté pour la prochaine fois !
"Olivier Miakinen" <om+news@miakinen.net> a écrit dans le message de news:
45bd1bfe$1@neottia.net...
4) Pas vraiment de commentaires sur ta dernière remarque ...
Dans ce cas pourquoi la citer ? D'une manière générale, surtout si tu
réponds point par point, il vaudrait mieux mettre chaque réponse après
chaque point cité, plutôt que tout en bloc à la fin du message (on est
obligé de faire des tas d'allers-retours et c'est très pénible). Et
puis bien sûr il faut supprimer ce qui ne sert à rien, par exemple la
signature de celui à qui tu réponds.
Une lecture indispensable (en particulier 3.a et 3.b) :
http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html
"Olivier Miakinen" <om+ a écrit dans le message de news: 45bd1bfe$
4) Pas vraiment de commentaires sur ta dernière remarque ...
Dans ce cas pourquoi la citer ? D'une manière générale, surtout si tu réponds point par point, il vaudrait mieux mettre chaque réponse après chaque point cité, plutôt que tout en bloc à la fin du message (on est obligé de faire des tas d'allers-retours et c'est très pénible). Et puis bien sûr il faut supprimer ce qui ne sert à rien, par exemple la signature de celui à qui tu réponds.
Une lecture indispensable (en particulier 3.a et 3.b) : http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html
