Sur l'un de nos sites, les gens qui s'inscrivent peuvent entrer (entre
autres) l'adresse de leur site web. Afin d'éviter les erreurs les plus
flagrantes, un contrôle est fait :
$siteini=$_POST['siteini'];
$site="http://".$siteini;
$file = @fopen($site,'r');
if ($file)
{$_SESSION['siteini']=$siteini;}
else
{
echo '<p class="erreur">L\'adresse de site '.$site.' renvoie un
message d\'erreur !</p>';
$errurl1='1';
}
Ça ne nous met pas à l'abri de toutes les bourdes, mais globalement ça
marche plutôt bien et oblige certains utilisateurs à ôter leurs moufles
pour se servir du clavier.
Aujourd'hui, j'ai le problème inverse, avec un site qui existe mais renvoie
un code erreur. Pour la page d'accueil du site en question http://www.les-
rolistes-rouennais.com/ ça ne m'étonne pas trop, car non seulement la page
d'accueil met longtemps à s'afficher, mais le chargement semble n'être
jamais fini (« en attente de http://www.les-rolistes-rouennais.com/ »). Ce
qui m'ennuie plus, c'est que j'ai le même message d'erreur
avec d'autres pages, par exemple http://www.les-rolistes-
rouennais.com/forum/accueil-f2.html , mais là aussi, il semble qu'il y ait
des éléments de page qui se chargent de manière sporadique.
Du coup, je suis embarrassée, car je n'ai pas envie du tout de supprimer ce
test, même s'il est imparfait, alors si vous avez de bonnes idées, ne vous
gênez pas... (:
Sur l'un de nos sites, les gens qui s'inscrivent peuvent entrer (entre autres) l'adresse de leur site web. Afin d'éviter les erreurs les plus flagrantes, un contrôle est fait :
[...] $file = @fopen($site,'r'); [...] Aujourd'hui, j'ai le problème inverse, avec un site qui existe mais renvoie un code erreur. [...]
Si le code de retour de fopen() n'est pas assez informatif, une idée serait peut-être d'utiliser CURL : http://fr3.php.net/manual/fr/ref.curl.php
Les codes d'erreur sont assez complets : http://curl.haxx.se/libcurl/c/libcurl-errors.html
... et certains pourraient t'intéresser, par exemple :
CURLE_URL_MALFORMAT (3) The URL was not properly formatted. -> erreur de l'utilisateur
CURLE_COULDNT_RESOLVE_HOST (6) Couldn't resolve host. The given remote host was not resolved. -> probable erreur de l'utilisateur (à confirmer avec une requête sur un site dont tu es sûre, pour vérifier que ce n'est pas le DNS qui est en rade).
CURLE_COULDNT_CONNECT (7) Failed to connect() to host or proxy. -> le site est peut-être correct, même s'il ne répond pas.
etc.
Le 06/07/2008 16:51, Pascale a écrit :
Sur l'un de nos sites, les gens qui s'inscrivent peuvent entrer (entre
autres) l'adresse de leur site web. Afin d'éviter les erreurs les plus
flagrantes, un contrôle est fait :
[...]
$file = @fopen($site,'r');
[...]
Aujourd'hui, j'ai le problème inverse, avec un site qui existe mais renvoie
un code erreur. [...]
Si le code de retour de fopen() n'est pas assez informatif, une idée
serait peut-être d'utiliser CURL :
http://fr3.php.net/manual/fr/ref.curl.php
Les codes d'erreur sont assez complets :
http://curl.haxx.se/libcurl/c/libcurl-errors.html
... et certains pourraient t'intéresser, par exemple :
CURLE_URL_MALFORMAT (3)
The URL was not properly formatted.
-> erreur de l'utilisateur
CURLE_COULDNT_RESOLVE_HOST (6)
Couldn't resolve host. The given remote host was not resolved.
-> probable erreur de l'utilisateur (à confirmer avec une requête sur un
site dont tu es sûre, pour vérifier que ce n'est pas le DNS qui est
en rade).
CURLE_COULDNT_CONNECT (7)
Failed to connect() to host or proxy.
-> le site est peut-être correct, même s'il ne répond pas.
Sur l'un de nos sites, les gens qui s'inscrivent peuvent entrer (entre autres) l'adresse de leur site web. Afin d'éviter les erreurs les plus flagrantes, un contrôle est fait :
[...] $file = @fopen($site,'r'); [...] Aujourd'hui, j'ai le problème inverse, avec un site qui existe mais renvoie un code erreur. [...]
Si le code de retour de fopen() n'est pas assez informatif, une idée serait peut-être d'utiliser CURL : http://fr3.php.net/manual/fr/ref.curl.php
Les codes d'erreur sont assez complets : http://curl.haxx.se/libcurl/c/libcurl-errors.html
... et certains pourraient t'intéresser, par exemple :
CURLE_URL_MALFORMAT (3) The URL was not properly formatted. -> erreur de l'utilisateur
CURLE_COULDNT_RESOLVE_HOST (6) Couldn't resolve host. The given remote host was not resolved. -> probable erreur de l'utilisateur (à confirmer avec une requête sur un site dont tu es sûre, pour vérifier que ce n'est pas le DNS qui est en rade).
CURLE_COULDNT_CONNECT (7) Failed to connect() to host or proxy. -> le site est peut-être correct, même s'il ne répond pas.
etc.
Pascale
Olivier Miakinen <om+ écrivait news:4870ebd3$:
Si le code de retour de fopen() n'est pas assez informatif, une idée serait peut-être d'utiliser CURL : http://fr3.php.net/manual/fr/ref.curl.php
Ça a l'air de correspondre à ce que je cherche, par contre, je suis totalement neuneue pour la mise en ½uvre...
On commence par faire :
$ch=curl_init($url); puis on récupère le code erreur éventuel avec
Si le code de retour de fopen() n'est pas assez informatif, une idée serait peut-être d'utiliser CURL : http://fr3.php.net/manual/fr/ref.curl.php
Ça a l'air de correspondre à ce que je cherche, par contre, je suis totalement neuneue pour la mise en ½uvre...
On commence par faire :
$ch=curl_init($url); puis on récupère le code erreur éventuel avec
curl_errno($ch);
Mais en fait non, j'ai rien compris ? Si...?
-- Pascale
Pascale
Olivier Miakinen <om+ écrivait news:4870ebd3$:
Si le code de retour de fopen() n'est pas assez informatif, une idée serait peut-être d'utiliser CURL [couic]
Je pense que ça correspond tout à fait à ce qu'il me faut : si je trouve pas mon bonheur là dedans, c'est vraiment que je m'y prends mal, merci Olivier (:
Si le code de retour de fopen() n'est pas assez informatif, une idée
serait peut-être d'utiliser CURL [couic]
Je pense que ça correspond tout à fait à ce qu'il me faut : si je trouve
pas mon bonheur là dedans, c'est vraiment que je m'y prends mal, merci
Olivier (:
Si le code de retour de fopen() n'est pas assez informatif, une idée serait peut-être d'utiliser CURL [couic]
Je pense que ça correspond tout à fait à ce qu'il me faut : si je trouve pas mon bonheur là dedans, c'est vraiment que je m'y prends mal, merci Olivier (:
-- Pascale
CrazyCat
Pascale wrote:
Sur l'un de nos sites, les gens qui s'inscrivent peuvent entrer (entre autres) l'adresse de leur site web. Afin d'éviter les erreurs les plus flagrantes, un contrôle est fait :
-- Réseau IRC Francophone: http://www.zeolia.net Aide et astuces webmasters : http://www.c-p-f.org Communauté Francophone sur les Eggdrops: http://www.eggdrop.fr
Pascale wrote:
Sur l'un de nos sites, les gens qui s'inscrivent peuvent entrer (entre
autres) l'adresse de leur site web. Afin d'éviter les erreurs les plus
flagrantes, un contrôle est fait :
Sur l'un de nos sites, les gens qui s'inscrivent peuvent entrer (entre autres) l'adresse de leur site web. Afin d'éviter les erreurs les plus flagrantes, un contrôle est fait :
-- Réseau IRC Francophone: http://www.zeolia.net Aide et astuces webmasters : http://www.c-p-f.org Communauté Francophone sur les Eggdrops: http://www.eggdrop.fr
Mickaël Wolff
Pascale a écrit :
On commence par faire :
$ch=curl_init($url); puis on récupère le code erreur éventuel avec
curl_errno($ch);
Mais en fait non, j'ai rien compris ? Si...?
curl_init créé une ressource, et l'initialise avec le paramètre s'il lui est fournit.
curl_setopt te permet de configurer ta ressource.
Il faut savoir que, par défaut, curl va télécharger la page distante et renvoyer le contenu vers ton navigateur. Donc si tu veux seulement vérifier que la page existe, tu peux utiliser le code suivant :
À noter que le message renvoyé n'est pas forcément une erreur.
Je profites du thread pour soulever un point concernant curl et la sécurité. En fournissant directement l'URL de l'utilisateur à Curl, n'y a-t-il pas potentiellement un problème de sécurité ?
$ch=curl_init($url);
puis on récupère le code erreur éventuel avec
curl_errno($ch);
Mais en fait non, j'ai rien compris ? Si...?
curl_init créé une ressource, et l'initialise avec le paramètre s'il
lui est fournit.
curl_setopt te permet de configurer ta ressource.
Il faut savoir que, par défaut, curl va télécharger la page distante
et renvoyer le contenu vers ton navigateur. Donc si tu veux seulement
vérifier que la page existe, tu peux utiliser le code suivant :
À noter que le message renvoyé n'est pas forcément une erreur.
Je profites du thread pour soulever un point concernant curl et la
sécurité. En fournissant directement l'URL de l'utilisateur à Curl, n'y
a-t-il pas potentiellement un problème de sécurité ?
$ch=curl_init($url); puis on récupère le code erreur éventuel avec
curl_errno($ch);
Mais en fait non, j'ai rien compris ? Si...?
curl_init créé une ressource, et l'initialise avec le paramètre s'il lui est fournit.
curl_setopt te permet de configurer ta ressource.
Il faut savoir que, par défaut, curl va télécharger la page distante et renvoyer le contenu vers ton navigateur. Donc si tu veux seulement vérifier que la page existe, tu peux utiliser le code suivant :
À noter que le message renvoyé n'est pas forcément une erreur.
Je profites du thread pour soulever un point concernant curl et la sécurité. En fournissant directement l'URL de l'utilisateur à Curl, n'y a-t-il pas potentiellement un problème de sécurité ?
Le Mon, 07 Jul 2008 12:36:13 +0000, Mickaël Wolff a écrit:
En fournissant directement l'URL de l'utilisateur à Curl, n'y a-t-il pas potentiellement un problème de sécurité ?
Si, multiples même.
Voir par exemple des papiers sur la sécurité d'OpenID (même problème : l'utilisateur fournit une URL à un serveur qui doit s'en servir et s'y connecter), ou un client HTTP « paranoïaque » dans un autre language : http://search.cpan.org/~bradfitz/LWPx-ParanoidAgent-1.03/lib/LWPx/ParanoidAgent.pm (avec quelques explications sur les pièges évités).
Et bien sûr là on ne parle même pas d'éventuelles failles dans le client HTTP en lui-même juste de failles découlant du fait d'accepter de l'extérieur une information réutilisée telle quelle.
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/>
Le Mon, 07 Jul 2008 12:36:13 +0000, Mickaël Wolff a écrit:
En fournissant directement l'URL de l'utilisateur à Curl, n'y
a-t-il pas potentiellement un problème de sécurité ?
Si, multiples même.
Voir par exemple des papiers sur la sécurité d'OpenID (même problème :
l'utilisateur fournit une URL à un serveur qui doit s'en servir et s'y
connecter), ou un client HTTP « paranoïaque » dans un autre language :
http://search.cpan.org/~bradfitz/LWPx-ParanoidAgent-1.03/lib/LWPx/ParanoidAgent.pm
(avec quelques explications sur les pièges évités).
Et bien sûr là on ne parle même pas d'éventuelles failles dans le client
HTTP en lui-même juste de failles découlant du fait d'accepter de
l'extérieur une information réutilisée telle quelle.
--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Le Mon, 07 Jul 2008 12:36:13 +0000, Mickaël Wolff a écrit:
En fournissant directement l'URL de l'utilisateur à Curl, n'y a-t-il pas potentiellement un problème de sécurité ?
Si, multiples même.
Voir par exemple des papiers sur la sécurité d'OpenID (même problème : l'utilisateur fournit une URL à un serveur qui doit s'en servir et s'y connecter), ou un client HTTP « paranoïaque » dans un autre language : http://search.cpan.org/~bradfitz/LWPx-ParanoidAgent-1.03/lib/LWPx/ParanoidAgent.pm (avec quelques explications sur les pièges évités).
Et bien sûr là on ne parle même pas d'éventuelles failles dans le client HTTP en lui-même juste de failles découlant du fait d'accepter de l'extérieur une information réutilisée telle quelle.
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/>
Olivier Miakinen
Le 07/07/2008 15:39, Patrick Mevzek a écrit :
En fournissant directement l'URL de l'utilisateur à Curl, n'y a-t-il pas potentiellement un problème de sécurité ?
Si, multiples même.
Même si cette URL n'est utilisée que pour une requête HEAD, et que la seule information utile qu'on en retient est un éventuel code d'erreur ?
Je ne vois pas quel problème de sécurité cela pourrait poser pour l'appelant : il y a *beaucoup* moins de risques que pour un simple internaute cliquant sur un lien avec un navigateur qui ferait un GET au lieu d'un HEAD et qui, en outre, interpréterait le JavaScript.
Et même pour l'appelé : s'il n'implémente pas d'effet de bord aux requêtes HEAD, il ne risque pas grand chose -- et inversement s'il reformate son disque dur en réponse à un HEAD, c'est bien fait pour sa pomme !
Voir par exemple des papiers sur la sécurité d'OpenID (même problème : l'utilisateur fournit une URL à un serveur qui doit s'en servir et s'y connecter),
Tu aurais un lien (si possible traduit en français) ?
ou un client HTTP « paranoïaque » dans un autre language : http://search.cpan.org/~bradfitz/LWPx-ParanoidAgent-1.03/lib/LWPx/ParanoidAgent.pm (avec quelques explications sur les pièges évités).
Je n'ai pas bien compris ce que ça fait (il faut dire que je ne suis pas allé voir ce qu'était LWP::UserAgent dont il dérive).
Et bien sûr là on ne parle même pas d'éventuelles failles dans le client HTTP en lui-même juste de failles découlant du fait d'accepter de l'extérieur une information réutilisée telle quelle.
Oui, bien sûr. Mais dans ce cas, quel genre de contrôle ferais-tu sur l'URL qui pourrait minimiser les risques lors de la connexion par CURL ?
Le 07/07/2008 15:39, Patrick Mevzek a écrit :
En fournissant directement l'URL de l'utilisateur à Curl, n'y
a-t-il pas potentiellement un problème de sécurité ?
Si, multiples même.
Même si cette URL n'est utilisée que pour une requête HEAD, et que la
seule information utile qu'on en retient est un éventuel code d'erreur ?
Je ne vois pas quel problème de sécurité cela pourrait poser pour
l'appelant : il y a *beaucoup* moins de risques que pour un simple
internaute cliquant sur un lien avec un navigateur qui ferait un GET
au lieu d'un HEAD et qui, en outre, interpréterait le JavaScript.
Et même pour l'appelé : s'il n'implémente pas d'effet de bord aux
requêtes HEAD, il ne risque pas grand chose -- et inversement s'il
reformate son disque dur en réponse à un HEAD, c'est bien fait pour
sa pomme !
Voir par exemple des papiers sur la sécurité d'OpenID (même problème :
l'utilisateur fournit une URL à un serveur qui doit s'en servir et s'y
connecter),
Tu aurais un lien (si possible traduit en français) ?
ou un client HTTP « paranoïaque » dans un autre language :
http://search.cpan.org/~bradfitz/LWPx-ParanoidAgent-1.03/lib/LWPx/ParanoidAgent.pm
(avec quelques explications sur les pièges évités).
Je n'ai pas bien compris ce que ça fait (il faut dire que je ne suis pas
allé voir ce qu'était LWP::UserAgent dont il dérive).
Et bien sûr là on ne parle même pas d'éventuelles failles dans le client
HTTP en lui-même juste de failles découlant du fait d'accepter de
l'extérieur une information réutilisée telle quelle.
Oui, bien sûr. Mais dans ce cas, quel genre de contrôle ferais-tu sur
l'URL qui pourrait minimiser les risques lors de la connexion par CURL ?
En fournissant directement l'URL de l'utilisateur à Curl, n'y a-t-il pas potentiellement un problème de sécurité ?
Si, multiples même.
Même si cette URL n'est utilisée que pour une requête HEAD, et que la seule information utile qu'on en retient est un éventuel code d'erreur ?
Je ne vois pas quel problème de sécurité cela pourrait poser pour l'appelant : il y a *beaucoup* moins de risques que pour un simple internaute cliquant sur un lien avec un navigateur qui ferait un GET au lieu d'un HEAD et qui, en outre, interpréterait le JavaScript.
Et même pour l'appelé : s'il n'implémente pas d'effet de bord aux requêtes HEAD, il ne risque pas grand chose -- et inversement s'il reformate son disque dur en réponse à un HEAD, c'est bien fait pour sa pomme !
Voir par exemple des papiers sur la sécurité d'OpenID (même problème : l'utilisateur fournit une URL à un serveur qui doit s'en servir et s'y connecter),
Tu aurais un lien (si possible traduit en français) ?
ou un client HTTP « paranoïaque » dans un autre language : http://search.cpan.org/~bradfitz/LWPx-ParanoidAgent-1.03/lib/LWPx/ParanoidAgent.pm (avec quelques explications sur les pièges évités).
Je n'ai pas bien compris ce que ça fait (il faut dire que je ne suis pas allé voir ce qu'était LWP::UserAgent dont il dérive).
Et bien sûr là on ne parle même pas d'éventuelles failles dans le client HTTP en lui-même juste de failles découlant du fait d'accepter de l'extérieur une information réutilisée telle quelle.
Oui, bien sûr. Mais dans ce cas, quel genre de contrôle ferais-tu sur l'URL qui pourrait minimiser les risques lors de la connexion par CURL ?
Mickaël Wolff
Patrick Mevzek a écrit :
Le Mon, 07 Jul 2008 12:36:13 +0000, Mickaël Wolff a écrit:
En fournissant directement l'URL de l'utilisateur à Curl, n'y a-t-il pas potentiellement un problème de sécurité ?
Si, multiples même.
J'ai un peu fouillé, et c'est en fait un énorme trou si on ne fait pas attention. Merci pour les infos.
Pascale, le bout de code que j'ai fournit à titre d'illustration n'est pas sécurisé. Il ne faut pas l'utiliser en production. Je regarde pour faire une classe mieux fagotée, je la posterais ici.
Le Mon, 07 Jul 2008 12:36:13 +0000, Mickaël Wolff a écrit:
En fournissant directement l'URL de l'utilisateur à Curl, n'y
a-t-il pas potentiellement un problème de sécurité ?
Si, multiples même.
J'ai un peu fouillé, et c'est en fait un énorme trou si on ne fait pas
attention. Merci pour les infos.
Pascale, le bout de code que j'ai fournit à titre d'illustration n'est
pas sécurisé. Il ne faut pas l'utiliser en production. Je regarde pour
faire une classe mieux fagotée, je la posterais ici.
Le Mon, 07 Jul 2008 12:36:13 +0000, Mickaël Wolff a écrit:
En fournissant directement l'URL de l'utilisateur à Curl, n'y a-t-il pas potentiellement un problème de sécurité ?
Si, multiples même.
J'ai un peu fouillé, et c'est en fait un énorme trou si on ne fait pas attention. Merci pour les infos.
Pascale, le bout de code que j'ai fournit à titre d'illustration n'est pas sécurisé. Il ne faut pas l'utiliser en production. Je regarde pour faire une classe mieux fagotée, je la posterais ici.
Tu aurais un lien (si possible traduit en français) ?
C'est vrai que moi aussi ça m'aurait aider. Cependant, en essayant l'url file:///etc/passwd dans curl_init, même en configurant l'option CURLOPT_NOBODY à true le contenu du fichier est affiché :-D
Je n'ai pas bien compris ce que ça fait (il faut dire que je ne suis pas allé voir ce qu'était LWP::UserAgent dont il dérive).
Ce que je pense qu'il faut en retirer, c'est la limitation du timeout (pour éviter les redirections éternelles), l'exclusion d'hôtes sensibles afin d'éviter de détourner la fonctionnalité pour sonder le voisinage réseau, etc. Tiens, si ça ce trouve, en utilisant la fonctionnalité telnet, on peut éventuellement utiliser ça pour faire du spam :-D (oui, c'est une obsession).
Oui, bien sûr. Mais dans ce cas, quel genre de contrôle ferais-tu sur l'URL qui pourrait minimiser les risques lors de la connexion par CURL ?
Vérifier que c'est une URL désignant une ressource HTTP est un bon début en fait. C'est d'ailleurs ce que je suis en train de corriger dans mes devs. Je n'avais pas réalisé la puissance de cURL.
Tu aurais un lien (si possible traduit en français) ?
C'est vrai que moi aussi ça m'aurait aider. Cependant, en essayant
l'url file:///etc/passwd dans curl_init, même en configurant l'option
CURLOPT_NOBODY à true le contenu du fichier est affiché :-D
Je n'ai pas bien compris ce que ça fait (il faut dire que je ne suis pas
allé voir ce qu'était LWP::UserAgent dont il dérive).
Ce que je pense qu'il faut en retirer, c'est la limitation du timeout
(pour éviter les redirections éternelles), l'exclusion d'hôtes sensibles
afin d'éviter de détourner la fonctionnalité pour sonder le voisinage
réseau, etc. Tiens, si ça ce trouve, en utilisant la fonctionnalité
telnet, on peut éventuellement utiliser ça pour faire du spam :-D (oui,
c'est une obsession).
Oui, bien sûr. Mais dans ce cas, quel genre de contrôle ferais-tu sur
l'URL qui pourrait minimiser les risques lors de la connexion par CURL ?
Vérifier que c'est une URL désignant une ressource HTTP est un bon
début en fait. C'est d'ailleurs ce que je suis en train de corriger dans
mes devs. Je n'avais pas réalisé la puissance de cURL.
Tu aurais un lien (si possible traduit en français) ?
C'est vrai que moi aussi ça m'aurait aider. Cependant, en essayant l'url file:///etc/passwd dans curl_init, même en configurant l'option CURLOPT_NOBODY à true le contenu du fichier est affiché :-D
Je n'ai pas bien compris ce que ça fait (il faut dire que je ne suis pas allé voir ce qu'était LWP::UserAgent dont il dérive).
Ce que je pense qu'il faut en retirer, c'est la limitation du timeout (pour éviter les redirections éternelles), l'exclusion d'hôtes sensibles afin d'éviter de détourner la fonctionnalité pour sonder le voisinage réseau, etc. Tiens, si ça ce trouve, en utilisant la fonctionnalité telnet, on peut éventuellement utiliser ça pour faire du spam :-D (oui, c'est une obsession).
Oui, bien sûr. Mais dans ce cas, quel genre de contrôle ferais-tu sur l'URL qui pourrait minimiser les risques lors de la connexion par CURL ?
Vérifier que c'est une URL désignant une ressource HTTP est un bon début en fait. C'est d'ailleurs ce que je suis en train de corriger dans mes devs. Je n'avais pas réalisé la puissance de cURL.
Pascale, le bout de code que j'ai fournit à titre d'illustration n'est pas sécurisé. Il ne faut pas l'utiliser en production. Je regarde pour faire une classe mieux fagotée, je la posterais ici.
Bon, merci à tous de vous être penchés sur mon cas (-: Je crois que tout le monde a compris ce que je veux faire, mais quelques précisions ne peuvent pas nuire. La personne qui s'inscrit au site a le droit de rentrer, parmi ses coordonnées, l'adresse de son site (le http:// est positionné automatiquement, on contrôle que l'utilisateur ne le met pas 2 fois). Le but est de prévenir la saisie d'adresses de sites farfelues ou erronées. Je ne veux en aucun cas que le site s'ouvre automatiquement sur l'ordinateur de la personne qui s'inscrit, je veux simplement prévenir la saisie d'adresses erronées (je suis embêtée non seulement avec ceux qui tapent avec leurs moufles, avec ceux qui veulent mettre un texte du style « en chantier », et aussi avec ceux, plus nombreux qu'on ne croit, qui confondent adresse de site et adresse courriel, ce qui fait qu'on se retrouve avec des URL du genre http://). Le contrôle de l'URL s'effectue non seulement à l'inscription, mais à chaque fois que la personne modifie quelque chose dans ses coordonnées. Si je peux avoir un message d'erreur plus précis que « URL erronée », ce sera pas plus mal (:
Pascale, le bout de code que j'ai fournit à titre d'illustration n'est
pas sécurisé. Il ne faut pas l'utiliser en production. Je regarde pour
faire une classe mieux fagotée, je la posterais ici.
Bon, merci à tous de vous être penchés sur mon cas (-:
Je crois que tout le monde a compris ce que je veux faire, mais quelques
précisions ne peuvent pas nuire. La personne qui s'inscrit au site a le
droit de rentrer, parmi ses coordonnées, l'adresse de son site (le http://
est positionné automatiquement, on contrôle que l'utilisateur ne le met pas
2 fois). Le but est de prévenir la saisie d'adresses de sites farfelues ou
erronées. Je ne veux en aucun cas que le site s'ouvre automatiquement sur
l'ordinateur de la personne qui s'inscrit, je veux simplement prévenir la
saisie d'adresses erronées (je suis embêtée non seulement avec ceux qui
tapent avec leurs moufles, avec ceux qui veulent mettre un texte du style
« en chantier », et aussi avec ceux, plus nombreux qu'on ne croit, qui
confondent adresse de site et adresse courriel, ce qui fait qu'on se
retrouve avec des URL du genre http://machinchouette@fai.fr).
Le contrôle de l'URL s'effectue non seulement à l'inscription, mais à
chaque fois que la personne modifie quelque chose dans ses coordonnées.
Si je peux avoir un message d'erreur plus précis que « URL erronée », ce
sera pas plus mal (:
Pascale, le bout de code que j'ai fournit à titre d'illustration n'est pas sécurisé. Il ne faut pas l'utiliser en production. Je regarde pour faire une classe mieux fagotée, je la posterais ici.
Bon, merci à tous de vous être penchés sur mon cas (-: Je crois que tout le monde a compris ce que je veux faire, mais quelques précisions ne peuvent pas nuire. La personne qui s'inscrit au site a le droit de rentrer, parmi ses coordonnées, l'adresse de son site (le http:// est positionné automatiquement, on contrôle que l'utilisateur ne le met pas 2 fois). Le but est de prévenir la saisie d'adresses de sites farfelues ou erronées. Je ne veux en aucun cas que le site s'ouvre automatiquement sur l'ordinateur de la personne qui s'inscrit, je veux simplement prévenir la saisie d'adresses erronées (je suis embêtée non seulement avec ceux qui tapent avec leurs moufles, avec ceux qui veulent mettre un texte du style « en chantier », et aussi avec ceux, plus nombreux qu'on ne croit, qui confondent adresse de site et adresse courriel, ce qui fait qu'on se retrouve avec des URL du genre http://). Le contrôle de l'URL s'effectue non seulement à l'inscription, mais à chaque fois que la personne modifie quelque chose dans ses coordonnées. Si je peux avoir un message d'erreur plus précis que « URL erronée », ce sera pas plus mal (:
