Bonsoir, j'ai implémenté (une fois de plus) pour un client un processus
d'authentification utilisation des sessions.
Indépendament des failles possibles ("vols" de sessions par un
malfaisant) et bien que je n'utilise que des sessions par cookies (pas de
PHPID) se pose le problème suivant :
Habituellement je passe d'abord par une authentification apache
(.htaccess) puis ensuite un écran de login de l'application (et c'est ici
que les sessions entrent en oeuvre).
Ce client trouvait assez casse-pieds de devoir s'authentifier deux fois
(un premier pass global pour tous les utilisateurs, puis une
authentification appli propre à chacun), j'ai donc supprimé
l'authentification de premier niveau (.htaccess). J'ai pris soin
d'intégrer quelques conseils judicieux donnés ici (vérifier à chaque
accès que l'IP n'a pas changé) mais bon...
Ca ne le satisfait toujours pas, il trouve encore casse pied de devoir
s'authentifier à chaque fois.
La solution la plus simple serait d'utiliser un cookie disant "cet
utilisateur a été authentifié, son accès est donc valide jusqu'à telle
date" mais je trouve ça franchement insécure.
Je voudrais donc savoir quelles autres solutions sont à ma disposition ?
Ne serait-il pas possible que chaque utilisateur dispose (sur son poste,
en fait sur son navigateur) d'un certificat me permettant de m'assurer
qu'il s'agit bien d'un utilisateur duement authentifié ? Un peu sur le
principe de ssh avec ses clés privées/publiques mais sans la "pass
phrase"...
De quel côté dois-je chercher ?? Comment répondre à son attente sans pour
autant transformer l'appli en un véritable gruyère ?
Si vous avez un début de solution, ou des liens, ou je sais pas quoi, je
prends !!!
Dernière précision : les adresses IP des utilisateurs habilités à
utiliser l'appli ne sont pas connues (ip dynamiques ou ip gateway) je ne
peux donc pas compter la dessus pour identifier qui que ce soit.
et en mettant un cookie illimité sur la machine de ton client ... ???avec une référence unique que tu vérifies par rapport à l'IP par exemple à chaque connexion..???
genre un nombre + IP = valeur d'autorisation ...
et en mettant un cookie illimité sur la machine de ton client ...
???avec une référence unique que tu vérifies par rapport à l'IP par
exemple à chaque connexion..???
et en mettant un cookie illimité sur la machine de ton client ... ???avec une référence unique que tu vérifies par rapport à l'IP par exemple à chaque connexion..???
genre un nombre + IP = valeur d'autorisation ...
Jean-Marc Molina
La solution la plus simple serait d'utiliser un cookie disant "cet utilisateur a été authentifié, son accès est donc valide jusqu'à telle date"
mais je trouve ça franchement insécure.
Le cookie peut en effet être "sniffé" tout comme une session. Tu en parles auparavant d'ailleurs. Dans les 2 cas un hacker peut donc parfaitement récupérer les données qui transitent entre le serveur et le client. Une solution c'est d'utiliser le JavaScript pour crypter les données chez le client avant de les envoyer sur le serveur.
Mais la meilleure solution, l'unique, c'est d'utiliser un serveur sécurisé : SSL. Les hébergeurs proposent ce service pour un coût supplémentaire. Tout dépend de l'importance des données qui transitent et de l'application. Dans le cas d'un paiement en ligne, l'application doit être sécurisée. Un simple système de cookie/session n'étant pas du tout sécurisé.
Pour résumer, cookie, session ou .htaccess ne servent rien à si un petit hacker décide de s'en prendre à votre site ou votre application. Une solution : SSL*.
* : une faille de sécurité a été... encore... récemment découverte mais elle a été corrigée. Oui je sais c'est pas rassurant mais bon...
La solution la plus simple serait d'utiliser un cookie disant "cet
utilisateur a été authentifié, son accès est donc valide jusqu'à telle date"
mais je trouve ça franchement insécure.
Le cookie peut en effet être "sniffé" tout comme une session. Tu en parles
auparavant d'ailleurs.
Dans les 2 cas un hacker peut donc parfaitement récupérer les données qui
transitent entre le serveur et le client.
Une solution c'est d'utiliser le JavaScript pour crypter les données chez le
client avant de les envoyer sur le serveur.
Mais la meilleure solution, l'unique, c'est d'utiliser un serveur sécurisé :
SSL.
Les hébergeurs proposent ce service pour un coût supplémentaire.
Tout dépend de l'importance des données qui transitent et de l'application.
Dans le cas d'un paiement en ligne, l'application doit être sécurisée. Un
simple système de cookie/session n'étant pas du tout sécurisé.
Pour résumer, cookie, session ou .htaccess ne servent rien à si un petit
hacker décide de s'en prendre à votre site ou votre application.
Une solution : SSL*.
* : une faille de sécurité a été... encore... récemment découverte mais elle
a été corrigée. Oui je sais c'est pas rassurant mais bon...
La solution la plus simple serait d'utiliser un cookie disant "cet utilisateur a été authentifié, son accès est donc valide jusqu'à telle date"
mais je trouve ça franchement insécure.
Le cookie peut en effet être "sniffé" tout comme une session. Tu en parles auparavant d'ailleurs. Dans les 2 cas un hacker peut donc parfaitement récupérer les données qui transitent entre le serveur et le client. Une solution c'est d'utiliser le JavaScript pour crypter les données chez le client avant de les envoyer sur le serveur.
Mais la meilleure solution, l'unique, c'est d'utiliser un serveur sécurisé : SSL. Les hébergeurs proposent ce service pour un coût supplémentaire. Tout dépend de l'importance des données qui transitent et de l'application. Dans le cas d'un paiement en ligne, l'application doit être sécurisée. Un simple système de cookie/session n'étant pas du tout sécurisé.
Pour résumer, cookie, session ou .htaccess ne servent rien à si un petit hacker décide de s'en prendre à votre site ou votre application. Une solution : SSL*.
* : une faille de sécurité a été... encore... récemment découverte mais elle a été corrigée. Oui je sais c'est pas rassurant mais bon...
Zouplaz
Jean-Marc Molina - :
Mais la meilleure solution, l'unique, c'est d'utiliser un serveur sécurisé : SSL. Les hébergeurs proposent ce service pour un coût supplémentaire. Tout dépend de l'importance des données qui transitent et de l'application. Dans le cas d'un paiement en ligne, l'application doit être sécurisée. Un simple système de cookie/session n'étant pas du tout sécurisé.
Pour résumer, cookie, session ou .htaccess ne servent rien à si un petit hacker décide de s'en prendre à votre site ou votre application. Une solution : SSL*.
Bon, je comprends bien le rôle que peut jouer SSL dans la sécurisation du transfert d'informations entre le client et le serveur.
Mais dans le cas présent, en quoi est-ce que ça va résoudre le problème de mon client ?
Il me demande de trouver une solution pour ne pas avoir à se re- authentifier à chaque fois. Le fait qu'un site soit "certifié" ne signifie pas que l'application PHP puisse faire confiance à la personne qui est de l'autre côté non ? Ou alors tu veux dire que le certificat doit être installé sur le navigateur du client ??
Mais la meilleure solution, l'unique, c'est d'utiliser un serveur
sécurisé : SSL.
Les hébergeurs proposent ce service pour un coût supplémentaire.
Tout dépend de l'importance des données qui transitent et de
l'application. Dans le cas d'un paiement en ligne, l'application doit
être sécurisée. Un simple système de cookie/session n'étant pas du
tout sécurisé.
Pour résumer, cookie, session ou .htaccess ne servent rien à si un
petit hacker décide de s'en prendre à votre site ou votre application.
Une solution : SSL*.
Bon, je comprends bien le rôle que peut jouer SSL dans la sécurisation du
transfert d'informations entre le client et le serveur.
Mais dans le cas présent, en quoi est-ce que ça va résoudre le problème de
mon client ?
Il me demande de trouver une solution pour ne pas avoir à se re-
authentifier à chaque fois. Le fait qu'un site soit "certifié" ne signifie
pas que l'application PHP puisse faire confiance à la personne qui est de
l'autre côté non ? Ou alors tu veux dire que le certificat doit être
installé sur le navigateur du client ??
Mais la meilleure solution, l'unique, c'est d'utiliser un serveur sécurisé : SSL. Les hébergeurs proposent ce service pour un coût supplémentaire. Tout dépend de l'importance des données qui transitent et de l'application. Dans le cas d'un paiement en ligne, l'application doit être sécurisée. Un simple système de cookie/session n'étant pas du tout sécurisé.
Pour résumer, cookie, session ou .htaccess ne servent rien à si un petit hacker décide de s'en prendre à votre site ou votre application. Une solution : SSL*.
Bon, je comprends bien le rôle que peut jouer SSL dans la sécurisation du transfert d'informations entre le client et le serveur.
Mais dans le cas présent, en quoi est-ce que ça va résoudre le problème de mon client ?
Il me demande de trouver une solution pour ne pas avoir à se re- authentifier à chaque fois. Le fait qu'un site soit "certifié" ne signifie pas que l'application PHP puisse faire confiance à la personne qui est de l'autre côté non ? Ou alors tu veux dire que le certificat doit être installé sur le navigateur du client ??
Désolé, je suis un peu largué !!
John Gallet
Mais dans le cas présent, en quoi est-ce que ça va résoudre le problème de mon client ?
Le monsieur n'a pas tord dans ce qu'il dit, mais ça ne résoud absolument rien.
JG
Mais dans le cas présent, en quoi est-ce que ça va résoudre le problème de
mon client ?
Le monsieur n'a pas tord dans ce qu'il dit, mais ça ne résoud absolument
rien.
Mais dans le cas présent, en quoi est-ce que ça va résoudre le problème de mon client ?
Le monsieur n'a pas tord dans ce qu'il dit, mais ça ne résoud absolument rien.
JG
John Gallet
Bonsoir,
Bonsoir, j'ai implémenté (une fois de plus) pour un client un processus d'authentification utilisation des sessions. Jusqu'ici, tout va bien.
Indépendament des failles possibles ("vols" de sessions par un malfaisant) et bien que je n'utilise que des sessions par cookies (pas de PHPID) se pose le problème suivant : C'est un choix.
Ca ne le satisfait toujours pas, il trouve encore casse pied de devoir s'authentifier à chaque fois. Dommage pour lui.
Je voudrais donc savoir quelles autres solutions sont à ma disposition ? 1) faire un cahier des charges clair et précis dès le départ avant de
commencer le développement. Ca évite ce genre de conneries.
2) faire signer une décharge à ce monsieur précisant qu'il n'engagera pas ta responsabilité/celle de ton entreprise en cas d'accès non autorisé à l'application et ce quelles que soient les conséquence pour les données de l'appli. En général, ça fait réfléchir un peu les braves lusers qui ne comprennent rien.
Maintenant de toutes façons, toute solution de "sécurité" qui est basée sur des données stockées côté client (comme les cookies) sont contournables, seuls les mécanismes côté serveur sont fiables. Donc un peu de plus ou un peu de moins, ça changera pas grand chose.
Dernière précision : les adresses IP des utilisateurs habilités à utiliser l'appli ne sont pas connues (ip dynamiques ou ip gateway) je ne peux donc pas compter la dessus pour identifier qui que ce soit. Et de toutes façons cf la FAQ pour REMOTE_ADDR
La seule solution que je vois pour satisfaire ton luser, c'est de lui dire de bookmarker la page d'accueil avec https://login:/index.php Et s'il se fait piquer ses bookmarks, tant pis pour sa poire (mais oublie pas de le prévenir quand même).
a++ JG
Bonsoir,
Bonsoir, j'ai implémenté (une fois de plus) pour un client un processus
d'authentification utilisation des sessions.
Jusqu'ici, tout va bien.
Indépendament des failles possibles ("vols" de sessions par un
malfaisant) et bien que je n'utilise que des sessions par cookies (pas de
PHPID) se pose le problème suivant :
C'est un choix.
Ca ne le satisfait toujours pas, il trouve encore casse pied de devoir
s'authentifier à chaque fois.
Dommage pour lui.
Je voudrais donc savoir quelles autres solutions sont à ma disposition ?
1) faire un cahier des charges clair et précis dès le départ avant de
commencer le développement. Ca évite ce genre de conneries.
2) faire signer une décharge à ce monsieur précisant qu'il n'engagera
pas ta responsabilité/celle de ton entreprise en cas d'accès non
autorisé à l'application et ce quelles que soient les conséquence pour
les données de l'appli. En général, ça fait réfléchir un peu les braves
lusers qui ne comprennent rien.
Maintenant de toutes façons, toute solution de "sécurité" qui est basée
sur des données stockées côté client (comme les cookies) sont
contournables, seuls les mécanismes côté serveur sont fiables. Donc un
peu de plus ou un peu de moins, ça changera pas grand chose.
Dernière précision : les adresses IP des utilisateurs habilités à
utiliser l'appli ne sont pas connues (ip dynamiques ou ip gateway) je ne
peux donc pas compter la dessus pour identifier qui que ce soit.
Et de toutes façons cf la FAQ pour REMOTE_ADDR
La seule solution que je vois pour satisfaire ton luser, c'est de lui
dire de bookmarker la page d'accueil avec
https://login:password@www.toto.com/index.php
Et s'il se fait piquer ses bookmarks, tant pis pour sa poire (mais
oublie pas de le prévenir quand même).
Bonsoir, j'ai implémenté (une fois de plus) pour un client un processus d'authentification utilisation des sessions. Jusqu'ici, tout va bien.
Indépendament des failles possibles ("vols" de sessions par un malfaisant) et bien que je n'utilise que des sessions par cookies (pas de PHPID) se pose le problème suivant : C'est un choix.
Ca ne le satisfait toujours pas, il trouve encore casse pied de devoir s'authentifier à chaque fois. Dommage pour lui.
Je voudrais donc savoir quelles autres solutions sont à ma disposition ? 1) faire un cahier des charges clair et précis dès le départ avant de
commencer le développement. Ca évite ce genre de conneries.
2) faire signer une décharge à ce monsieur précisant qu'il n'engagera pas ta responsabilité/celle de ton entreprise en cas d'accès non autorisé à l'application et ce quelles que soient les conséquence pour les données de l'appli. En général, ça fait réfléchir un peu les braves lusers qui ne comprennent rien.
Maintenant de toutes façons, toute solution de "sécurité" qui est basée sur des données stockées côté client (comme les cookies) sont contournables, seuls les mécanismes côté serveur sont fiables. Donc un peu de plus ou un peu de moins, ça changera pas grand chose.
Dernière précision : les adresses IP des utilisateurs habilités à utiliser l'appli ne sont pas connues (ip dynamiques ou ip gateway) je ne peux donc pas compter la dessus pour identifier qui que ce soit. Et de toutes façons cf la FAQ pour REMOTE_ADDR
La seule solution que je vois pour satisfaire ton luser, c'est de lui dire de bookmarker la page d'accueil avec https://login:/index.php Et s'il se fait piquer ses bookmarks, tant pis pour sa poire (mais oublie pas de le prévenir quand même).
a++ JG
Jean-Marc Molina
Bonjour,
Oui en effet je ne répondais pas à la question :)
Donc pour en revenir à ton problème. La dernière fois je crois l'avoir lue un peu trop vite.
Par contre je comprends pas pourquoi tu avais fait 2 systèmes, 1 suffit, tu peux gérer l'authentification type Apache en PHP ( http://www.devshed.com/Server_Side/PHP/UserAuth ).
Pour ton problème tu peux déjà lui éviter de saisir son nom d'utilisateur en le stockant dans un cookie. Il ne lui reste plus qu'à saisir son mot de passe. Tu peux donc préremplir le formulaire avec son nom, ce qui ne pose aucun problème car les noms sont souvent connus suite aux messages que les utilisateurs postent sur des forums...
Le fait qu'un site soit "certifié" ne signifie pas que l'application PHP puisse faire confiance à la personne qui est de
l'autre côté non ?
Rien ne t'empêche de stocker une clé dans un cookie et de la référencer dans une base de données. Quand un utilisateur se connecte, tu créés une nouvelle clé, tu la stockes dans le cookie "crypté", tu la copies dans la BDD. À chaque connection d'un nouvel utilisateur, tu vérifies son IP, le cookie... ce que tu veux et le tour est joué.
Selon moi l'IP et le cookie c'est le plus important.
Donc rien à voir avec SSL. Que les données soient cryptés ou pas ne change rien au problème des cookies. Par contre ça évite qu'un mot de passe "en clair" soit récupéré par un petit hacker lors de son transit du client vers le serveur. Et c'est ça le plus important.
Pour finir je te conseille d'en rester au système d'authentification qui demande le mot de passe. Quand même c'est pas grand chose un mot de passe, déjà tu ne lui demandes plus de saisir son nom d'utilisateur.
JM
Bonjour,
Oui en effet je ne répondais pas à la question :)
Donc pour en revenir à ton problème.
La dernière fois je crois l'avoir lue un peu trop vite.
Par contre je comprends pas pourquoi tu avais fait 2 systèmes, 1 suffit, tu
peux gérer l'authentification type Apache en PHP (
http://www.devshed.com/Server_Side/PHP/UserAuth ).
Pour ton problème tu peux déjà lui éviter de saisir son nom d'utilisateur en
le stockant dans un cookie. Il ne lui reste plus qu'à saisir son mot de
passe. Tu peux donc préremplir le formulaire avec son nom, ce qui ne pose
aucun problème car les noms sont souvent connus suite aux messages que les
utilisateurs postent sur des forums...
Le fait qu'un site soit "certifié" ne signifie
pas que l'application PHP puisse faire confiance à la personne qui est de
l'autre côté non ?
Rien ne t'empêche de stocker une clé dans un cookie et de la référencer dans
une base de données. Quand un utilisateur se connecte, tu créés une nouvelle
clé, tu la stockes dans le cookie "crypté", tu la copies dans la BDD. À
chaque connection d'un nouvel utilisateur, tu vérifies son IP, le cookie...
ce que tu veux et le tour est joué.
Selon moi l'IP et le cookie c'est le plus important.
Donc rien à voir avec SSL. Que les données soient cryptés ou pas ne change
rien au problème des cookies. Par contre ça évite qu'un mot de passe "en
clair" soit récupéré par un petit hacker lors de son transit du client vers
le serveur. Et c'est ça le plus important.
Pour finir je te conseille d'en rester au système d'authentification qui
demande le mot de passe. Quand même c'est pas grand chose un mot de passe,
déjà tu ne lui demandes plus de saisir son nom d'utilisateur.
Donc pour en revenir à ton problème. La dernière fois je crois l'avoir lue un peu trop vite.
Par contre je comprends pas pourquoi tu avais fait 2 systèmes, 1 suffit, tu peux gérer l'authentification type Apache en PHP ( http://www.devshed.com/Server_Side/PHP/UserAuth ).
Pour ton problème tu peux déjà lui éviter de saisir son nom d'utilisateur en le stockant dans un cookie. Il ne lui reste plus qu'à saisir son mot de passe. Tu peux donc préremplir le formulaire avec son nom, ce qui ne pose aucun problème car les noms sont souvent connus suite aux messages que les utilisateurs postent sur des forums...
Le fait qu'un site soit "certifié" ne signifie pas que l'application PHP puisse faire confiance à la personne qui est de
l'autre côté non ?
Rien ne t'empêche de stocker une clé dans un cookie et de la référencer dans une base de données. Quand un utilisateur se connecte, tu créés une nouvelle clé, tu la stockes dans le cookie "crypté", tu la copies dans la BDD. À chaque connection d'un nouvel utilisateur, tu vérifies son IP, le cookie... ce que tu veux et le tour est joué.
Selon moi l'IP et le cookie c'est le plus important.
Donc rien à voir avec SSL. Que les données soient cryptés ou pas ne change rien au problème des cookies. Par contre ça évite qu'un mot de passe "en clair" soit récupéré par un petit hacker lors de son transit du client vers le serveur. Et c'est ça le plus important.
Pour finir je te conseille d'en rester au système d'authentification qui demande le mot de passe. Quand même c'est pas grand chose un mot de passe, déjà tu ne lui demandes plus de saisir son nom d'utilisateur.
JM
Christophe PEREZ
Le Wed, 24 Sep 2003 20:23:22 +0000, Zouplaz a écrit:
Bonsoir,
[...]
De quel côté dois-je chercher ?? Comment répondre à son attente sans pour autant transformer l'appli en un véritable gruyère ? [...]
Je viens juste de me réabonner à ce ng après plusieurs mois d'absence, et je lis donc cette discussion un peu après la bataille.
J'aimerais bien savoir comme tu t'en es finalement sorti car, je suis à peu près dans la même situation, même si ce n'est pas pour les mêmes raisons, et j'ai la grande sensation que ta solution pourrait être la mienne :-)
Je t'aurais bien contacté par mail, mais j'ai des doutes sur la validité de l'email proposé ;-).
-- Christophe PEREZ Écrivez moi sans _faute !
Le Wed, 24 Sep 2003 20:23:22 +0000, Zouplaz a écrit:
Bonsoir,
[...]
De quel côté dois-je chercher ?? Comment répondre à son attente sans pour
autant transformer l'appli en un véritable gruyère ?
[...]
Je viens juste de me réabonner à ce ng après plusieurs mois d'absence, et
je lis donc cette discussion un peu après la bataille.
J'aimerais bien savoir comme tu t'en es finalement sorti car, je suis à
peu près dans la même situation, même si ce n'est pas pour les mêmes
raisons, et j'ai la grande sensation que ta solution pourrait être la
mienne :-)
Je t'aurais bien contacté par mail, mais j'ai des doutes sur la validité
de l'email proposé ;-).
Le Wed, 24 Sep 2003 20:23:22 +0000, Zouplaz a écrit:
Bonsoir,
[...]
De quel côté dois-je chercher ?? Comment répondre à son attente sans pour autant transformer l'appli en un véritable gruyère ? [...]
Je viens juste de me réabonner à ce ng après plusieurs mois d'absence, et je lis donc cette discussion un peu après la bataille.
J'aimerais bien savoir comme tu t'en es finalement sorti car, je suis à peu près dans la même situation, même si ce n'est pas pour les mêmes raisons, et j'ai la grande sensation que ta solution pourrait être la mienne :-)
Je t'aurais bien contacté par mail, mais j'ai des doutes sur la validité de l'email proposé ;-).
-- Christophe PEREZ Écrivez moi sans _faute !
Zouplaz
Christophe PEREZ - :
Le Wed, 24 Sep 2003 20:23:22 +0000, Zouplaz a écrit:
Bonsoir,
[...]
De quel côté dois-je chercher ?? Comment répondre à son attente sans pour autant transformer l'appli en un véritable gruyère ? [...]
Je viens juste de me réabonner à ce ng après plusieurs mois d'absence, et je lis donc cette discussion un peu après la bataille.
J'aimerais bien savoir comme tu t'en es finalement sorti car, je suis à peu près dans la même situation, même si ce n'est pas pour les mêmes raisons, et j'ai la grande sensation que ta solution pourrait être la mienne :-)
Eh bien pour l'instant je fais le mort ;-) C'est à dire que j'ai expliqué à mon client que je cherchais une solution mais que cette demande ne pouvait être satisfaite dans l'immédiat... Comme je ne sais pas trop quoi faire (évidemment il y aurait bien un tunnel ssh, ça serait en soi suffisant mais c'est trop galère à déployer et de plus c'est pas mon rôle d'aller installer quoi que ce soit sur leurs bécanes).
Je pense que dans un premier temps je vais voir ce que je peux faire avec ssl mais sans pour autant aquérir un véritable certificat, ça aura quand même l'avantage de crypter les transferts d'information entre le client et le serveur, mais ça ne résoud pas le problème de l'authentification.
Puis au final, s'il n'y a pas de solution viable eh bien ça restera comme ça !
Je t'aurais bien contacté par mail, mais j'ai des doutes sur la validité de l'email proposé ;-).
Ahem, j'en suis à 150 spams/jour pour avoir longtemps posté comme un jouvenceau il y a quelques années, alors maintenant...
Christophe PEREZ - christophe_faute@novazur.com :
Le Wed, 24 Sep 2003 20:23:22 +0000, Zouplaz a écrit:
Bonsoir,
[...]
De quel côté dois-je chercher ?? Comment répondre à son attente sans
pour autant transformer l'appli en un véritable gruyère ?
[...]
Je viens juste de me réabonner à ce ng après plusieurs mois d'absence,
et je lis donc cette discussion un peu après la bataille.
J'aimerais bien savoir comme tu t'en es finalement sorti car, je suis
à peu près dans la même situation, même si ce n'est pas pour les mêmes
raisons, et j'ai la grande sensation que ta solution pourrait être la
mienne :-)
Eh bien pour l'instant je fais le mort ;-) C'est à dire que j'ai expliqué
à mon client que je cherchais une solution mais que cette demande ne
pouvait être satisfaite dans l'immédiat... Comme je ne sais pas trop quoi
faire (évidemment il y aurait bien un tunnel ssh, ça serait en soi
suffisant mais c'est trop galère à déployer et de plus c'est pas mon rôle
d'aller installer quoi que ce soit sur leurs bécanes).
Je pense que dans un premier temps je vais voir ce que je peux faire avec
ssl mais sans pour autant aquérir un véritable certificat, ça aura quand
même l'avantage de crypter les transferts d'information entre le client
et le serveur, mais ça ne résoud pas le problème de l'authentification.
Puis au final, s'il n'y a pas de solution viable eh bien ça restera comme
ça !
Je t'aurais bien contacté par mail, mais j'ai des doutes sur la
validité de l'email proposé ;-).
Ahem, j'en suis à 150 spams/jour pour avoir longtemps posté comme un
jouvenceau il y a quelques années, alors maintenant...
Le Wed, 24 Sep 2003 20:23:22 +0000, Zouplaz a écrit:
Bonsoir,
[...]
De quel côté dois-je chercher ?? Comment répondre à son attente sans pour autant transformer l'appli en un véritable gruyère ? [...]
Je viens juste de me réabonner à ce ng après plusieurs mois d'absence, et je lis donc cette discussion un peu après la bataille.
J'aimerais bien savoir comme tu t'en es finalement sorti car, je suis à peu près dans la même situation, même si ce n'est pas pour les mêmes raisons, et j'ai la grande sensation que ta solution pourrait être la mienne :-)
Eh bien pour l'instant je fais le mort ;-) C'est à dire que j'ai expliqué à mon client que je cherchais une solution mais que cette demande ne pouvait être satisfaite dans l'immédiat... Comme je ne sais pas trop quoi faire (évidemment il y aurait bien un tunnel ssh, ça serait en soi suffisant mais c'est trop galère à déployer et de plus c'est pas mon rôle d'aller installer quoi que ce soit sur leurs bécanes).
Je pense que dans un premier temps je vais voir ce que je peux faire avec ssl mais sans pour autant aquérir un véritable certificat, ça aura quand même l'avantage de crypter les transferts d'information entre le client et le serveur, mais ça ne résoud pas le problème de l'authentification.
Puis au final, s'il n'y a pas de solution viable eh bien ça restera comme ça !
Je t'aurais bien contacté par mail, mais j'ai des doutes sur la validité de l'email proposé ;-).
Ahem, j'en suis à 150 spams/jour pour avoir longtemps posté comme un jouvenceau il y a quelques années, alors maintenant...
Christophe PEREZ
Le Mon, 29 Sep 2003 18:54:46 +0000, Zouplaz a écrit:
[...]
Puis au final, s'il n'y a pas de solution viable eh bien ça restera comme ça !
Ok.
Ahem, j'en suis à 150 spams/jour pour avoir longtemps posté comme un jouvenceau il y a quelques années, alors maintenant...
Je comprends très bien, mais ça me plairait bien que nous puissions poursuivre en privé si tu veux bien. Tu dois savoir me joindre :-)
-- Christophe PEREZ Écrivez moi sans _faute !
Le Mon, 29 Sep 2003 18:54:46 +0000, Zouplaz a écrit:
[...]
Puis au final, s'il n'y a pas de solution viable eh bien ça restera comme
ça !
Ok.
Ahem, j'en suis à 150 spams/jour pour avoir longtemps posté comme un
jouvenceau il y a quelques années, alors maintenant...
Je comprends très bien, mais ça me plairait bien que nous puissions
poursuivre en privé si tu veux bien.
Tu dois savoir me joindre :-)
Le Mon, 29 Sep 2003 18:54:46 +0000, Zouplaz a écrit:
[...]
Puis au final, s'il n'y a pas de solution viable eh bien ça restera comme ça !
Ok.
Ahem, j'en suis à 150 spams/jour pour avoir longtemps posté comme un jouvenceau il y a quelques années, alors maintenant...
Je comprends très bien, mais ça me plairait bien que nous puissions poursuivre en privé si tu veux bien. Tu dois savoir me joindre :-)
-- Christophe PEREZ Écrivez moi sans _faute !
Jean-Marc Molina
Et l'idée d'utiliser au moins un cookie pour son nom d'utilisateur ? Normalement tu te retrouves avec une simple saisie pour se connecter à l'application... Celle du mot de passe.
Pour les spams je vous conseille de suffixer votre adresse avec _antipourriel_ ou _antispam_. C'est ce que j'utilise.
Et l'idée d'utiliser au moins un cookie pour son nom d'utilisateur ?
Normalement tu te retrouves avec une simple saisie pour se connecter à
l'application... Celle du mot de passe.
Pour les spams je vous conseille de suffixer votre adresse avec
_antipourriel_ ou _antispam_. C'est ce que j'utilise.
Et l'idée d'utiliser au moins un cookie pour son nom d'utilisateur ? Normalement tu te retrouves avec une simple saisie pour se connecter à l'application... Celle du mot de passe.
Pour les spams je vous conseille de suffixer votre adresse avec _antipourriel_ ou _antispam_. C'est ce que j'utilise.
