Pas mon truc du tout, mais je dois résoudre un petit problème.
Un de mes progs vérifie à intervalle régulier la disponibilité d'une mise à
jour sur un compte FTP sur un serveur mutualisé chez un hébergeur. S'il y en
a une, il le récupère par FTP sans intervention de l'utilisateur.
Mon prog se connecte sur le compte FTP en envoyant le login et mdp en clair.
C'est pas terrible, je sais et c'est pour ça que je cherche une soluce.
Tout en sachant que je ne sais pas où le prog va être installé (sous Windows
98 SE et +), que le serveur est sous FreeBSD je crois. Je dois donc
implémenter un truc dans mon prog, je ne peux pas installer un truc sur la
machine de l'utilisateur.
Question naïve : à quoi servent le login et le mot de passe si le contenu n'est pas confidentiel ?
Réponse bête : à protéger l'espace FTP contre des petits rigolos qui voudraient en faire des choses pas bien ?
Et mettre des droits qui vont bien pour n'autoriser que le download
ce qui semble etre le but recherche?
Mais effectivement au vu de la demande, je collerai un bete serveur web, et hop . SSL possible et facile . .htaccess qui va bien en bonus . possibilite de cacher le listing du repertoire contenant les fichiers a telecharger . pas de noeuds a se faire au cerveau pour deployer le tout au travers de firewall (cote client et cote serveur) . n'importe quel OS doit avoir un soft qui permet de telecharger du HTTP (voire HTTPS), donc pas de noeud au cerveau a se faire non plus pour coder la partie client. . et meme des fausses bonnes idees comme coller le serveur sur un port exotique pour eviter de se faire pourrir les logs de nimda codered etc.. -- Kevin
Le 21-11-2005, Jean Passe <runco_rien@agur-rien.com> a écrit :
Question naïve : à quoi servent le login et le mot de passe si le
contenu n'est pas confidentiel ?
Réponse bête : à protéger l'espace FTP contre des petits rigolos qui
voudraient en faire des choses pas bien ?
Et mettre des droits qui vont bien pour n'autoriser que le download
ce qui semble etre le but recherche?
Mais effectivement au vu de la demande, je collerai un bete serveur
web, et hop
. SSL possible et facile
. .htaccess qui va bien en bonus
. possibilite de cacher le listing du repertoire contenant les
fichiers a telecharger
. pas de noeuds a se faire au cerveau pour deployer le tout au
travers de firewall (cote client et cote serveur)
. n'importe quel OS doit avoir un soft qui permet de telecharger
du HTTP (voire HTTPS), donc pas de noeud au cerveau a se faire non
plus pour coder la partie client.
. et meme des fausses bonnes idees comme coller le serveur sur
un port exotique pour eviter de se faire pourrir les logs de nimda
codered etc..
--
Kevin
Question naïve : à quoi servent le login et le mot de passe si le contenu n'est pas confidentiel ?
Réponse bête : à protéger l'espace FTP contre des petits rigolos qui voudraient en faire des choses pas bien ?
Et mettre des droits qui vont bien pour n'autoriser que le download
ce qui semble etre le but recherche?
Mais effectivement au vu de la demande, je collerai un bete serveur web, et hop . SSL possible et facile . .htaccess qui va bien en bonus . possibilite de cacher le listing du repertoire contenant les fichiers a telecharger . pas de noeuds a se faire au cerveau pour deployer le tout au travers de firewall (cote client et cote serveur) . n'importe quel OS doit avoir un soft qui permet de telecharger du HTTP (voire HTTPS), donc pas de noeud au cerveau a se faire non plus pour coder la partie client. . et meme des fausses bonnes idees comme coller le serveur sur un port exotique pour eviter de se faire pourrir les logs de nimda codered etc.. -- Kevin
Eric Razny
Le Mon, 21 Nov 2005 12:54:16 +0000, Jean Passe a écrit :
Salut,
Ben dans ce cas, pourquoi ne pas mettre ça sur un bête serveur web? Et le seul paramètre est l'url :)
Oui, c'est ce que je fais maintenant, mais il y a intervention de l'utilisateur forcément et je voudrais éviter ça. C'est pour ça que je voulais le faire en FTP.
Ahem, tu programmes en quoi? Parce que ce ne doit pas être les outils qui manquent.
Je serais curieux de savoir comment s'en sortent mes utilisateurs qui ne savent même pas qu'ils passent par http ;)
Il y a certe intervention de l'utilisateur : il a allumé sa machine et éventuellement lancé "manuellement" le programme :)
Et je maintiens : pour faire ça http est moins casse cou^W^W ennuyeux que le ftp!
Eric.
Le Mon, 21 Nov 2005 12:54:16 +0000, Jean Passe a écrit :
Salut,
Ben dans ce cas, pourquoi ne pas mettre ça sur un bête serveur web?
Et le seul paramètre est l'url :)
Oui, c'est ce que je fais maintenant, mais il y a intervention de
l'utilisateur forcément et je voudrais éviter ça.
C'est pour ça que je voulais le faire en FTP.
Ahem, tu programmes en quoi?
Parce que ce ne doit pas être les outils qui manquent.
Je serais curieux de savoir comment s'en sortent mes utilisateurs qui ne
savent même pas qu'ils passent par http ;)
Il y a certe intervention de l'utilisateur : il a allumé sa machine et
éventuellement lancé "manuellement" le programme :)
Et je maintiens : pour faire ça http est moins casse cou^W^W ennuyeux que
le ftp!
Le Mon, 21 Nov 2005 12:54:16 +0000, Jean Passe a écrit :
Salut,
Ben dans ce cas, pourquoi ne pas mettre ça sur un bête serveur web? Et le seul paramètre est l'url :)
Oui, c'est ce que je fais maintenant, mais il y a intervention de l'utilisateur forcément et je voudrais éviter ça. C'est pour ça que je voulais le faire en FTP.
Ahem, tu programmes en quoi? Parce que ce ne doit pas être les outils qui manquent.
Je serais curieux de savoir comment s'en sortent mes utilisateurs qui ne savent même pas qu'ils passent par http ;)
Il y a certe intervention de l'utilisateur : il a allumé sa machine et éventuellement lancé "manuellement" le programme :)
Et je maintiens : pour faire ça http est moins casse cou^W^W ennuyeux que le ftp!
Eric.
Fabien LE LEZ
On 21 Nov 2005 12:54:16 GMT, "Jean Passe" :
Ben dans ce cas, pourquoi ne pas mettre ça sur un bête serveur web? Et le seul paramètre est l'url :)
Oui, c'est ce que je fais maintenant, mais il y a intervention de l'utilisateur forcément
Pourquoi ? Ton logiciel ouvre une connexion HTTP ou HTTPS vers le serveur, lance sa requête, télécharge les données et basta.
La seule intervention éventuelle de l'utilisateur, c'est la connexion à Internet (s'il n'est pas connecté en permanence) et le réglage du firewall pour autoriser ton soft à ouvrir une connexion.
On 21 Nov 2005 12:54:16 GMT, "Jean Passe" <runco_rien@agur-rien.com>:
Ben dans ce cas, pourquoi ne pas mettre ça sur un bête serveur web?
Et le seul paramètre est l'url :)
Oui, c'est ce que je fais maintenant, mais il y a intervention de
l'utilisateur forcément
Pourquoi ?
Ton logiciel ouvre une connexion HTTP ou HTTPS vers le serveur, lance
sa requête, télécharge les données et basta.
La seule intervention éventuelle de l'utilisateur, c'est la connexion
à Internet (s'il n'est pas connecté en permanence) et le réglage du
firewall pour autoriser ton soft à ouvrir une connexion.
Ben dans ce cas, pourquoi ne pas mettre ça sur un bête serveur web? Et le seul paramètre est l'url :)
Oui, c'est ce que je fais maintenant, mais il y a intervention de l'utilisateur forcément
Pourquoi ? Ton logiciel ouvre une connexion HTTP ou HTTPS vers le serveur, lance sa requête, télécharge les données et basta.
La seule intervention éventuelle de l'utilisateur, c'est la connexion à Internet (s'il n'est pas connecté en permanence) et le réglage du firewall pour autoriser ton soft à ouvrir une connexion.
Bertrand
Salut,
Un de mes progs vérifie à intervalle régulier la disponibilité d'une mise à jour sur un compte FTP sur un serveur mutualisé chez un hébergeur. S'il y en a une, il le récupère par FTP sans intervention de l'utilisateur. Mon prog se connecte sur le compte FTP en envoyant le login et mdp en clair. C'est pas terrible, je sais et c'est pour ça que je cherche une soluce. Tout en sachant que je ne sais pas où le prog va être installé (sous Windows 98 SE et +), que le serveur est sous FreeBSD je crois. Je dois donc implémenter un truc dans mon prog, je ne peux pas installer un truc sur la machine de l'utilisateur.
Pour compléter ce qui a été dit, il me parait indispensable de signer les échanges d'une quelconque manière que ce soit; si on utilise du SSL en HTTPS ou autre, ou tout autre protocole presentant d'une façon ou d'une autre le certificat du serveur, il faut imperativement le vérifier. Si le serveur ne présente pas de certificat, il faut signer le fichier de mise à jour lui même, et n'installer la mise à jour que si la signature est bonne (par un simple checksum, mais une "vraie" signature numérique - les APIs de Windows doivent surement fournir ce qu'il faut pour travailler avec ça).
Sinon il y a un risque de man in the middle permettant potentiellement à à peu prés n'importe qui de remplacer le fichier de mise à jour par à peu prés n'importe quoi.
@+ Bertrand
Salut,
Un de mes progs vérifie à intervalle régulier la disponibilité d'une mise à
jour sur un compte FTP sur un serveur mutualisé chez un hébergeur. S'il y en
a une, il le récupère par FTP sans intervention de l'utilisateur.
Mon prog se connecte sur le compte FTP en envoyant le login et mdp en clair.
C'est pas terrible, je sais et c'est pour ça que je cherche une soluce.
Tout en sachant que je ne sais pas où le prog va être installé (sous Windows
98 SE et +), que le serveur est sous FreeBSD je crois. Je dois donc
implémenter un truc dans mon prog, je ne peux pas installer un truc sur la
machine de l'utilisateur.
Pour compléter ce qui a été dit, il me parait indispensable de signer
les échanges d'une quelconque manière que ce soit; si on utilise du SSL
en HTTPS ou autre, ou tout autre protocole presentant d'une façon ou
d'une autre le certificat du serveur, il faut imperativement le vérifier.
Si le serveur ne présente pas de certificat, il faut signer le fichier
de mise à jour lui même, et n'installer la mise à jour que si la
signature est bonne (par un simple checksum, mais une "vraie" signature
numérique - les APIs de Windows doivent surement fournir ce qu'il faut
pour travailler avec ça).
Sinon il y a un risque de man in the middle permettant potentiellement à
à peu prés n'importe qui de remplacer le fichier de mise à jour par à
peu prés n'importe quoi.
Un de mes progs vérifie à intervalle régulier la disponibilité d'une mise à jour sur un compte FTP sur un serveur mutualisé chez un hébergeur. S'il y en a une, il le récupère par FTP sans intervention de l'utilisateur. Mon prog se connecte sur le compte FTP en envoyant le login et mdp en clair. C'est pas terrible, je sais et c'est pour ça que je cherche une soluce. Tout en sachant que je ne sais pas où le prog va être installé (sous Windows 98 SE et +), que le serveur est sous FreeBSD je crois. Je dois donc implémenter un truc dans mon prog, je ne peux pas installer un truc sur la machine de l'utilisateur.
Pour compléter ce qui a été dit, il me parait indispensable de signer les échanges d'une quelconque manière que ce soit; si on utilise du SSL en HTTPS ou autre, ou tout autre protocole presentant d'une façon ou d'une autre le certificat du serveur, il faut imperativement le vérifier. Si le serveur ne présente pas de certificat, il faut signer le fichier de mise à jour lui même, et n'installer la mise à jour que si la signature est bonne (par un simple checksum, mais une "vraie" signature numérique - les APIs de Windows doivent surement fournir ce qu'il faut pour travailler avec ça).
Sinon il y a un risque de man in the middle permettant potentiellement à à peu prés n'importe qui de remplacer le fichier de mise à jour par à peu prés n'importe quoi.
