J'ai un peu progressé dans mes problèmes de syntaxe (résolus) pour
htaccess. Désormais le fichier de mot de passe est bien reconnu, le
dialogue de saisie apparaît bien MAIS je suis forcé de revenir vers vous
parce que je me prends une erreur 401 (password mismatch) quelque soit
l'utilisateur et que le mdp soit bon ou pas.
- quand le fichier htaccess n'est pas présent, l'accès au site se fait
sans problème
- quand il est présent il me demande identifiant et mot de passe, normal
- si je déplace le fichier des mots de passe il me renvoie une erreur
404 de fichier non présent
- quand il est en place il le voit, mais le navigateur ne reçoit pas le
ok de "correspondance" pour accéder au site et il me renvoit une 401.
Une piste : quand je veux mettre des accents dans mon message
d'invitation, ça me ressort du "garbage" sur les caractères accentués.
Il y a donc un problème de non francisation ou quelque chose du genre ?
(je précise que j'ai choisi "Identification" comme invitation, des
prénoms sans accents comme logins, et des mots de passe constitués
uniquement de chiffres.)
J'ajoute que le résultat est le même avec Safari et avec Firefox.
De mémoire, le chemin indiquant htpasswd doit etre complet dans htaccess AuthUserFile /home/web/ton/chemin/.htpasswd
Y
Gerald
Yop wrote:
De mémoire, le chemin indiquant htpasswd doit etre complet dans htaccess AuthUserFile /home/web/ton/chemin/.htpasswd
Le chemin n'est pas en cause : quand il l'était (et il l'a été avant que je ne trouve la bonne syntaxe !), ça donnait une erreur 404. Là c'est une erreur d'authentification : le fichier est bien vu mais sa lecture est corrompue. Et je dirais même : dès la comparaison de l'identifiant puisque le problème existe même quand on ne met pas de mot de passe.
Mais merci quand même pour l'intention,
-- Gérald
Yop <kloug-news@yahoo.fr> wrote:
De mémoire, le chemin indiquant htpasswd
doit etre complet dans htaccess
AuthUserFile /home/web/ton/chemin/.htpasswd
Le chemin n'est pas en cause : quand il l'était (et il l'a été avant que
je ne trouve la bonne syntaxe !), ça donnait une erreur 404. Là c'est
une erreur d'authentification : le fichier est bien vu mais sa lecture
est corrompue. Et je dirais même : dès la comparaison de l'identifiant
puisque le problème existe même quand on ne met pas de mot de passe.
De mémoire, le chemin indiquant htpasswd doit etre complet dans htaccess AuthUserFile /home/web/ton/chemin/.htpasswd
Le chemin n'est pas en cause : quand il l'était (et il l'a été avant que je ne trouve la bonne syntaxe !), ça donnait une erreur 404. Là c'est une erreur d'authentification : le fichier est bien vu mais sa lecture est corrompue. Et je dirais même : dès la comparaison de l'identifiant puisque le problème existe même quand on ne met pas de mot de passe.
Mais merci quand même pour l'intention,
-- Gérald
Vincent
Le 24/10/2011 10:52, Gerald a écrit :
Une piste : quand je veux mettre des accents dans mon message d'invitation, ça me ressort du "garbage" sur les caractères accentués.
J'avais eu quelque chose comme cela... Il m'avait fallu réencoder le fichier htaccess avec le même encodage que celui de la page appelante (c'était le index.php)
Si ça peut aider...
Pour le fun, le htaccess avait été encodé en UTF16 little endian par je ne sais quel cochonnerie d'éditeur windows.
Le 24/10/2011 10:52, Gerald a écrit :
Une piste : quand je veux mettre des accents dans mon message
d'invitation, ça me ressort du "garbage" sur les caractères accentués.
J'avais eu quelque chose comme cela...
Il m'avait fallu réencoder le fichier htaccess avec le même encodage que
celui de la page appelante (c'était le index.php)
Si ça peut aider...
Pour le fun, le htaccess avait été encodé en UTF16 little endian par je
ne sais quel cochonnerie d'éditeur windows.
Une piste : quand je veux mettre des accents dans mon message d'invitation, ça me ressort du "garbage" sur les caractères accentués.
J'avais eu quelque chose comme cela... Il m'avait fallu réencoder le fichier htaccess avec le même encodage que celui de la page appelante (c'était le index.php)
Si ça peut aider...
Pour le fun, le htaccess avait été encodé en UTF16 little endian par je ne sais quel cochonnerie d'éditeur windows.
SAM
Le 24/10/11 10:52, Gerald a écrit :
J'ai un peu progressé dans mes problèmes de syntaxe (résolus) pour htaccess.
Ça se passe chez qui ? (quel hébergeur ?)
Désormais le fichier de mot de passe est bien reconnu, le dialogue de saisie apparaît bien MAIS je suis forcé de revenir vers vous parce que je me prends une erreur 401 (password mismatch) quelque soit l'utilisateur et que le mdp soit bon ou pas.
- quand le fichier htaccess n'est pas présent, l'accès au site se fait sans problème
Ouf ! donc le "site" existerait (au moins en cache ;-) )
- quand il est présent il me demande identifiant et mot de passe, normal - si je déplace le fichier des mots de passe il me renvoie une erreur 404 de fichier non présent - quand il est en place il le voit, mais le navigateur ne reçoit pas le ok de "correspondance" pour accéder au site et il me renvoit une 401.
erreur de login, non ? (ou erreur de rédaction du fichier de MdP)
Une piste : quand je veux mettre des accents dans mon message d'invitation, ça me ressort du "garbage" sur les caractères accentués.
Bon ... bien entendu, tous les fichiers sont écrits avec le même charset ? En utf-8, par exemple. (ou, à minima, en ISO-8859-1)
Il y a donc un problème de non francisation ou quelque chose du genre ? (je précise que j'ai choisi "Identification" comme invitation, des prénoms sans accents comme logins, et des mots de passe constitués uniquement de chiffres.)
J'ajoute que le résultat est le même avec Safari et avec Firefox.
les pov's chéris n'y peuvent goute pour des problèmes de serveurs ;-) non ?
Si quelqu'un a une idée, d'avance merci.
Essayer depuis un ordi et une connexion qui n'ont jamais été utilisés pour aller là.
tout refaire "propre" ? (y compris le ftp)
-- Stéphane Moriaux avec/with iMac-intel
Le 24/10/11 10:52, Gerald a écrit :
J'ai un peu progressé dans mes problèmes de syntaxe (résolus) pour
htaccess.
Ça se passe chez qui ?
(quel hébergeur ?)
Désormais le fichier de mot de passe est bien reconnu, le
dialogue de saisie apparaît bien MAIS je suis forcé de revenir vers vous
parce que je me prends une erreur 401 (password mismatch) quelque soit
l'utilisateur et que le mdp soit bon ou pas.
- quand le fichier htaccess n'est pas présent, l'accès au site se fait
sans problème
Ouf ! donc le "site" existerait (au moins en cache ;-) )
- quand il est présent il me demande identifiant et mot de passe, normal
- si je déplace le fichier des mots de passe il me renvoie une erreur
404 de fichier non présent
- quand il est en place il le voit, mais le navigateur ne reçoit pas le
ok de "correspondance" pour accéder au site et il me renvoit une 401.
erreur de login, non ?
(ou erreur de rédaction du fichier de MdP)
Une piste : quand je veux mettre des accents dans mon message
d'invitation, ça me ressort du "garbage" sur les caractères accentués.
Bon ...
bien entendu, tous les fichiers sont écrits avec le même charset ?
En utf-8, par exemple.
(ou, à minima, en ISO-8859-1)
Il y a donc un problème de non francisation ou quelque chose du genre ?
(je précise que j'ai choisi "Identification" comme invitation, des
prénoms sans accents comme logins, et des mots de passe constitués
uniquement de chiffres.)
J'ajoute que le résultat est le même avec Safari et avec Firefox.
les pov's chéris n'y peuvent goute pour des problèmes de serveurs ;-)
non ?
Si quelqu'un a une idée, d'avance merci.
Essayer depuis un ordi et une connexion qui n'ont jamais été utilisés
pour aller là.
J'ai un peu progressé dans mes problèmes de syntaxe (résolus) pour htaccess.
Ça se passe chez qui ? (quel hébergeur ?)
Désormais le fichier de mot de passe est bien reconnu, le dialogue de saisie apparaît bien MAIS je suis forcé de revenir vers vous parce que je me prends une erreur 401 (password mismatch) quelque soit l'utilisateur et que le mdp soit bon ou pas.
- quand le fichier htaccess n'est pas présent, l'accès au site se fait sans problème
Ouf ! donc le "site" existerait (au moins en cache ;-) )
- quand il est présent il me demande identifiant et mot de passe, normal - si je déplace le fichier des mots de passe il me renvoie une erreur 404 de fichier non présent - quand il est en place il le voit, mais le navigateur ne reçoit pas le ok de "correspondance" pour accéder au site et il me renvoit une 401.
erreur de login, non ? (ou erreur de rédaction du fichier de MdP)
Une piste : quand je veux mettre des accents dans mon message d'invitation, ça me ressort du "garbage" sur les caractères accentués.
Bon ... bien entendu, tous les fichiers sont écrits avec le même charset ? En utf-8, par exemple. (ou, à minima, en ISO-8859-1)
Il y a donc un problème de non francisation ou quelque chose du genre ? (je précise que j'ai choisi "Identification" comme invitation, des prénoms sans accents comme logins, et des mots de passe constitués uniquement de chiffres.)
J'ajoute que le résultat est le même avec Safari et avec Firefox.
les pov's chéris n'y peuvent goute pour des problèmes de serveurs ;-) non ?
Si quelqu'un a une idée, d'avance merci.
Essayer depuis un ordi et une connexion qui n'ont jamais été utilisés pour aller là.
tout refaire "propre" ? (y compris le ftp)
-- Stéphane Moriaux avec/with iMac-intel
Gerald
SAM wrote:
Ça se passe chez qui ? (quel hébergeur ?)
Chez moi ! Sur un MacMINI de 2006 sous Snow Leopard en utilisant les fonctionnalité du serveur Apache intégré à Mac OS X : - Préférences Système : partage web - Site créé avec RapidWeaver et copié en local dans le dossier "Sites" d'un utilisateur lambda du MacMINI - Positionnement du MINI en IP Fixe derrière une TimeCapsule qui gère les redirections - et qui est branchée en Ethernet sur une BBox complètement passive, sur laquelle j'ai simplement ouvert le HTTP, et activé la redirection dynamique du nom de domaine (vers DynDNS.org)
Ouf ! donc le "site" existerait (au moins en cache ;-) )
En fait LES sites existent depuis plusieurs années et fonctionnent très bien (dans la limite du débit montant de Bouygues quand même, mais c'est pour une utilisation à très faible audience, certaines mauvaises langues diraient à très faible intérêt :-)
Bon ... bien entendu, tous les fichiers sont écrits avec le même charset ? En utf-8, par exemple. (ou, à minima, en ISO-8859-1)
Je soupçonne effectivement une merde à ce niveau-là. J'ai créé (et re-créé) ces fichiers avec TextEdit, demandé le passage en "texte" et sauvegardé en UTF-8... Comment en savoir plus sur les caractéristiques du fichier ? Faut-il utiliser un autre éditeur ? TextWrangler ? Smultron ? Autre ?
Essayer depuis un ordi et une connexion qui n'ont jamais été utilisés pour aller là.
Déjà essayé, tout comme de créer un nouvel utilisateur pour voir si le résultat serait différent : hélas non. J'ai aussi exclu la nature du site (très élémentaire) créé par RapidWeaver en le remplaçant par une copie des pages par défaut d'Apple pour le dossier Sites de l'utilisateur. Pas de changement : sans htaccess ça s'affiche impec, avec htaccess ça demande le mot de passe, ça accède au fichier mdp (puisque "pas" de 404) mais ça ne reconnaît pas ce qui est saisi (ou ce qui est renvoyé) comme identique.
tout refaire "propre" ? (y compris le ftp)
Réinstaller le système ? J'y pense mais j'ai un doute sur l'efficacité de la manip.
J'ai effectivement l'impression qu'il y a quelque chose qui modifie la nature du texte identifiant-mot de passe, quand on le tape, ou quand on l'envoie, ou quand on le reçoit, ou quand on lit le fichier mdp, ou quand on compare les deux (c'est Apache du MINI qui fait ça, je crois). C'est sûrement très évident et je suis sûrement le roidek, mais le résultat est le même : je suis bloqué (enfin pour cette fonctionnalité). J'ai vu qu'il existe un "external" pour rapidweaver qui offre une interface graphique pour gérer ces fichiers, mais j'ai peur de dépenser 10 euros pour rien.
En tout cas merci de ton aide : tu suis parfaitement le problème, et c'est agréable d'être compris, à défaut de bondir de joie :-)
-- Gérald
SAM <stephanemoriaux.NoAdmin@wanadoo.fr.invalid> wrote:
Ça se passe chez qui ?
(quel hébergeur ?)
Chez moi ! Sur un MacMINI de 2006 sous Snow Leopard en utilisant les
fonctionnalité du serveur Apache intégré à Mac OS X :
- Préférences Système : partage web
- Site créé avec RapidWeaver et copié en local dans le dossier "Sites"
d'un utilisateur lambda du MacMINI
- Positionnement du MINI en IP Fixe derrière une TimeCapsule qui gère
les redirections
- et qui est branchée en Ethernet sur une BBox complètement passive, sur
laquelle j'ai simplement ouvert le HTTP, et activé la redirection
dynamique du nom de domaine (vers DynDNS.org)
Ouf ! donc le "site" existerait (au moins en cache ;-) )
En fait LES sites existent depuis plusieurs années et fonctionnent très
bien (dans la limite du débit montant de Bouygues quand même, mais c'est
pour une utilisation à très faible audience, certaines mauvaises langues
diraient à très faible intérêt :-)
Bon ...
bien entendu, tous les fichiers sont écrits avec le même charset ?
En utf-8, par exemple.
(ou, à minima, en ISO-8859-1)
Je soupçonne effectivement une merde à ce niveau-là. J'ai créé (et
re-créé) ces fichiers avec TextEdit, demandé le passage en "texte" et
sauvegardé en UTF-8... Comment en savoir plus sur les caractéristiques
du fichier ? Faut-il utiliser un autre éditeur ? TextWrangler ? Smultron
? Autre ?
Essayer depuis un ordi et une connexion qui n'ont jamais été utilisés
pour aller là.
Déjà essayé, tout comme de créer un nouvel utilisateur pour voir si le
résultat serait différent : hélas non. J'ai aussi exclu la nature du
site (très élémentaire) créé par RapidWeaver en le remplaçant par une
copie des pages par défaut d'Apple pour le dossier Sites de
l'utilisateur. Pas de changement : sans htaccess ça s'affiche impec,
avec htaccess ça demande le mot de passe, ça accède au fichier mdp
(puisque "pas" de 404) mais ça ne reconnaît pas ce qui est saisi (ou ce
qui est renvoyé) comme identique.
tout refaire "propre" ?
(y compris le ftp)
Réinstaller le système ? J'y pense mais j'ai un doute sur l'efficacité
de la manip.
J'ai effectivement l'impression qu'il y a quelque chose qui modifie la
nature du texte identifiant-mot de passe, quand on le tape, ou quand on
l'envoie, ou quand on le reçoit, ou quand on lit le fichier mdp, ou
quand on compare les deux (c'est Apache du MINI qui fait ça, je crois).
C'est sûrement très évident et je suis sûrement le roidek, mais le
résultat est le même : je suis bloqué (enfin pour cette fonctionnalité).
J'ai vu qu'il existe un "external" pour rapidweaver qui offre une
interface graphique pour gérer ces fichiers, mais j'ai peur de dépenser
10 euros pour rien.
En tout cas merci de ton aide : tu suis parfaitement le problème, et
c'est agréable d'être compris, à défaut de bondir de joie :-)
Chez moi ! Sur un MacMINI de 2006 sous Snow Leopard en utilisant les fonctionnalité du serveur Apache intégré à Mac OS X : - Préférences Système : partage web - Site créé avec RapidWeaver et copié en local dans le dossier "Sites" d'un utilisateur lambda du MacMINI - Positionnement du MINI en IP Fixe derrière une TimeCapsule qui gère les redirections - et qui est branchée en Ethernet sur une BBox complètement passive, sur laquelle j'ai simplement ouvert le HTTP, et activé la redirection dynamique du nom de domaine (vers DynDNS.org)
Ouf ! donc le "site" existerait (au moins en cache ;-) )
En fait LES sites existent depuis plusieurs années et fonctionnent très bien (dans la limite du débit montant de Bouygues quand même, mais c'est pour une utilisation à très faible audience, certaines mauvaises langues diraient à très faible intérêt :-)
Bon ... bien entendu, tous les fichiers sont écrits avec le même charset ? En utf-8, par exemple. (ou, à minima, en ISO-8859-1)
Je soupçonne effectivement une merde à ce niveau-là. J'ai créé (et re-créé) ces fichiers avec TextEdit, demandé le passage en "texte" et sauvegardé en UTF-8... Comment en savoir plus sur les caractéristiques du fichier ? Faut-il utiliser un autre éditeur ? TextWrangler ? Smultron ? Autre ?
Essayer depuis un ordi et une connexion qui n'ont jamais été utilisés pour aller là.
Déjà essayé, tout comme de créer un nouvel utilisateur pour voir si le résultat serait différent : hélas non. J'ai aussi exclu la nature du site (très élémentaire) créé par RapidWeaver en le remplaçant par une copie des pages par défaut d'Apple pour le dossier Sites de l'utilisateur. Pas de changement : sans htaccess ça s'affiche impec, avec htaccess ça demande le mot de passe, ça accède au fichier mdp (puisque "pas" de 404) mais ça ne reconnaît pas ce qui est saisi (ou ce qui est renvoyé) comme identique.
tout refaire "propre" ? (y compris le ftp)
Réinstaller le système ? J'y pense mais j'ai un doute sur l'efficacité de la manip.
J'ai effectivement l'impression qu'il y a quelque chose qui modifie la nature du texte identifiant-mot de passe, quand on le tape, ou quand on l'envoie, ou quand on le reçoit, ou quand on lit le fichier mdp, ou quand on compare les deux (c'est Apache du MINI qui fait ça, je crois). C'est sûrement très évident et je suis sûrement le roidek, mais le résultat est le même : je suis bloqué (enfin pour cette fonctionnalité). J'ai vu qu'il existe un "external" pour rapidweaver qui offre une interface graphique pour gérer ces fichiers, mais j'ai peur de dépenser 10 euros pour rien.
En tout cas merci de ton aide : tu suis parfaitement le problème, et c'est agréable d'être compris, à défaut de bondir de joie :-)
-- Gérald
Gerald
Vincent wrote:
Il m'avait fallu réencoder le fichier htaccess avec le même encodage que celui de la page appelante (c'était le index.php)
DE LA PAGE *APPELANTE* ? mmm ! ça pourrait bien être ça, mais ça le fait pareil si je remplace la page créée par RapidWeaver par celle créée par Apple (par défaut dans le dossier Sites).
Une suggestion pour ce réencodage (logiciel et manière de faire ?)
En tout cas merci déjà !
-- Gérald
Vincent <vincentvaquin@sfr.fr> wrote:
Il m'avait fallu réencoder le fichier htaccess avec le même encodage que
celui de la page appelante (c'était le index.php)
DE LA PAGE *APPELANTE* ? mmm ! ça pourrait bien être ça, mais ça le fait
pareil si je remplace la page créée par RapidWeaver par celle créée par
Apple (par défaut dans le dossier Sites).
Une suggestion pour ce réencodage (logiciel et manière de faire ?)
Il m'avait fallu réencoder le fichier htaccess avec le même encodage que celui de la page appelante (c'était le index.php)
DE LA PAGE *APPELANTE* ? mmm ! ça pourrait bien être ça, mais ça le fait pareil si je remplace la page créée par RapidWeaver par celle créée par Apple (par défaut dans le dossier Sites).
Une suggestion pour ce réencodage (logiciel et manière de faire ?)
En tout cas merci déjà !
-- Gérald
Denis Beauregard
Le Mon, 24 Oct 2011 10:52:21 +0200, (Gerald) écrivait dans fr.comp.infosystemes.www.auteurs:
J'ai un peu progressé dans mes problèmes de syntaxe (résolus) pour htaccess. Désormais le fichier de mot de passe est bien reconnu, le dialogue de saisie apparaît bien MAIS je suis forcé de revenir vers vous parce que je me prends une erreur 401 (password mismatch) quelque soit l'utilisateur et que le mdp soit bon ou pas.
Je ne sais pas si cela aidera, mais voici une petite anecdote à ce sujet.
Une fois, j'ai essayé de créer un .htaccess à la mitaine, en écrivant le code et en envoyant le tout au serveur et cela ne marchait pas. Par contre, il y avait sur le serveur un logiciel de gestion du site (du genre cpanel). En l'utilisant, j'ai pu avoir un .htaccess fonctionnel. Je n'ai jamais su quel était le problème. J'éditais sur Windows et le serveur être en Linux, avec une éventuelle conversion durant le FTP.
Si on édite sur Mac et que le serveur est un Linux, le .htaccess n'a pas d'extension et peut-être que le logiciel FTP ne fait pas la conversion des fins de ligne. J'essaierais soit d'éditer les fichiers directement sur le serveur, soit de changer l'extension (exemple : .txt) lors du téléversement au serveur.
Denis
Le Mon, 24 Oct 2011 10:52:21 +0200, Gerald@alussinan.org (Gerald)
écrivait dans fr.comp.infosystemes.www.auteurs:
J'ai un peu progressé dans mes problèmes de syntaxe (résolus) pour
htaccess. Désormais le fichier de mot de passe est bien reconnu, le
dialogue de saisie apparaît bien MAIS je suis forcé de revenir vers vous
parce que je me prends une erreur 401 (password mismatch) quelque soit
l'utilisateur et que le mdp soit bon ou pas.
Je ne sais pas si cela aidera, mais voici une petite anecdote à
ce sujet.
Une fois, j'ai essayé de créer un .htaccess à la mitaine, en
écrivant le code et en envoyant le tout au serveur et cela ne
marchait pas. Par contre, il y avait sur le serveur un logiciel
de gestion du site (du genre cpanel). En l'utilisant, j'ai pu
avoir un .htaccess fonctionnel. Je n'ai jamais su quel était le
problème. J'éditais sur Windows et le serveur être en Linux, avec
une éventuelle conversion durant le FTP.
Si on édite sur Mac et que le serveur est un Linux, le .htaccess
n'a pas d'extension et peut-être que le logiciel FTP ne fait pas
la conversion des fins de ligne. J'essaierais soit d'éditer les
fichiers directement sur le serveur, soit de changer l'extension
(exemple : .txt) lors du téléversement au serveur.
Le Mon, 24 Oct 2011 10:52:21 +0200, (Gerald) écrivait dans fr.comp.infosystemes.www.auteurs:
J'ai un peu progressé dans mes problèmes de syntaxe (résolus) pour htaccess. Désormais le fichier de mot de passe est bien reconnu, le dialogue de saisie apparaît bien MAIS je suis forcé de revenir vers vous parce que je me prends une erreur 401 (password mismatch) quelque soit l'utilisateur et que le mdp soit bon ou pas.
Je ne sais pas si cela aidera, mais voici une petite anecdote à ce sujet.
Une fois, j'ai essayé de créer un .htaccess à la mitaine, en écrivant le code et en envoyant le tout au serveur et cela ne marchait pas. Par contre, il y avait sur le serveur un logiciel de gestion du site (du genre cpanel). En l'utilisant, j'ai pu avoir un .htaccess fonctionnel. Je n'ai jamais su quel était le problème. J'éditais sur Windows et le serveur être en Linux, avec une éventuelle conversion durant le FTP.
Si on édite sur Mac et que le serveur est un Linux, le .htaccess n'a pas d'extension et peut-être que le logiciel FTP ne fait pas la conversion des fins de ligne. J'essaierais soit d'éditer les fichiers directement sur le serveur, soit de changer l'extension (exemple : .txt) lors du téléversement au serveur.
Denis
Olivier Miakinen
Le 24/10/2011 17:13, Gerald a écrit :
Bon ... bien entendu, tous les fichiers sont écrits avec le même charset ? En utf-8, par exemple. (ou, à minima, en ISO-8859-1)
Je soupçonne effectivement une merde à ce niveau-là. J'ai créé (et re-créé) ces fichiers avec TextEdit, demandé le passage en "texte" et sauvegardé en UTF-8... Comment en savoir plus sur les caractéristiques du fichier ?
Pour le contenu effectif, si tu as un moyen d'afficher le contenu des fichiers octet par octet tu peux comparer un caractère donné (mettons un « é » par exemple) avec son encodage prévu (en l'occurrence, deux octets de valeurs hexa C3 et A9, dans cet ordre). Ceci est à faire aussi bien sur le .htaccess que sur la page à protéger.
Regarder aussi s'il n'y aurait pas un BOM au début de l'un des fichiers. Pour cela, voir si les trois premiers octets sont EF BB BF.
Enfin, il serait bon de préciser ce que tu appelais « garbage » dans ton premier article, en donnant un exemple des caractères que tu souhaites et du résultat obtenu (à faire par copier-coller car je me doute que tu ne sauras pas forcément saisir un Å ou un √). Euh... hum, je vois que tu utilises MacSOUP alors il ne te sera peut-être pas possible de faire ce copier-coller ici... dans ce cas cjoint.com est ton ami.
Cordialement, -- Olivier Miakinen
Le 24/10/2011 17:13, Gerald a écrit :
Bon ...
bien entendu, tous les fichiers sont écrits avec le même charset ?
En utf-8, par exemple.
(ou, à minima, en ISO-8859-1)
Je soupçonne effectivement une merde à ce niveau-là. J'ai créé (et
re-créé) ces fichiers avec TextEdit, demandé le passage en "texte" et
sauvegardé en UTF-8... Comment en savoir plus sur les caractéristiques
du fichier ?
Pour le contenu effectif, si tu as un moyen d'afficher le contenu des
fichiers octet par octet tu peux comparer un caractère donné (mettons
un « é » par exemple) avec son encodage prévu (en l'occurrence, deux
octets de valeurs hexa C3 et A9, dans cet ordre). Ceci est à faire
aussi bien sur le .htaccess que sur la page à protéger.
Regarder aussi s'il n'y aurait pas un BOM au début de l'un des fichiers.
Pour cela, voir si les trois premiers octets sont EF BB BF.
Enfin, il serait bon de préciser ce que tu appelais « garbage » dans ton
premier article, en donnant un exemple des caractères que tu souhaites
et du résultat obtenu (à faire par copier-coller car je me doute que tu
ne sauras pas forcément saisir un Å ou un √). Euh... hum, je vois que tu
utilises MacSOUP alors il ne te sera peut-être pas possible de faire ce
copier-coller ici... dans ce cas cjoint.com est ton ami.
Bon ... bien entendu, tous les fichiers sont écrits avec le même charset ? En utf-8, par exemple. (ou, à minima, en ISO-8859-1)
Je soupçonne effectivement une merde à ce niveau-là. J'ai créé (et re-créé) ces fichiers avec TextEdit, demandé le passage en "texte" et sauvegardé en UTF-8... Comment en savoir plus sur les caractéristiques du fichier ?
Pour le contenu effectif, si tu as un moyen d'afficher le contenu des fichiers octet par octet tu peux comparer un caractère donné (mettons un « é » par exemple) avec son encodage prévu (en l'occurrence, deux octets de valeurs hexa C3 et A9, dans cet ordre). Ceci est à faire aussi bien sur le .htaccess que sur la page à protéger.
Regarder aussi s'il n'y aurait pas un BOM au début de l'un des fichiers. Pour cela, voir si les trois premiers octets sont EF BB BF.
Enfin, il serait bon de préciser ce que tu appelais « garbage » dans ton premier article, en donnant un exemple des caractères que tu souhaites et du résultat obtenu (à faire par copier-coller car je me doute que tu ne sauras pas forcément saisir un Å ou un √). Euh... hum, je vois que tu utilises MacSOUP alors il ne te sera peut-être pas possible de faire ce copier-coller ici... dans ce cas cjoint.com est ton ami.
Cordialement, -- Olivier Miakinen
SAM
Le 24/10/11 17:13, Gerald a écrit :
SAM wrote:
Ça se passe chez qui ? (quel hébergeur ?)
Chez moi ! Sur un MacMINI de 2006 sous Snow Leopard en utilisant les fonctionnalité du serveur Apache intégré à Mac OS X : - Préférences Système : partage web - Site créé avec RapidWeaver et copié en local dans le dossier "Sites" d'un utilisateur lambda du MacMINI
ça, ça me gène ... le coup du "copié" qu'en pense le serveur ensuite ? les droits des fichiers sont-ils les bons ?
il faudrait faire un chmod à bon escient(*) sur les fichiers .htaccess et .passwords
(*) je ne sais si un chmod 7777 conviendrait pour ces fichiers
- Positionnement du MINI en IP Fixe derrière une TimeCapsule qui gère les redirections - et qui est branchée en Ethernet sur une BBox complètement passive, sur laquelle j'ai simplement ouvert le HTTP, et activé la redirection dynamique du nom de domaine (vers DynDNS.org)
Ha Oui ! Quand même !
Et est-ce que l'accès protégé a eu fonctionné un jour ? Ou bien est-ce tes premiers essais.
bien entendu, tous les fichiers sont écrits avec le même charset ? En utf-8, par exemple. (ou, à minima, en ISO-8859-1)
Je soupçonne effectivement une merde à ce niveau-là. J'ai créé (et re-créé) ces fichiers avec TextEdit, demandé le passage en "texte" et sauvegardé en UTF-8...
Oui ... bon ... même s'il est censé y arriver, ça se mérite trop pour être certain de ne pas avoir fait une erreur qque part.
Comment en savoir plus sur les caractéristiques du fichier ? Faut-il utiliser un autre éditeur ? TextWrangler ? Smultron
À défaut de BBEdit, j'opterais volontiers pour TextWrangler (TextEdit est trop difficile à dompter, je trouve) Smultron, oui sans doute (bien que pour un fichier texte de MdP ...)
Essayer depuis un ordi et une connexion qui n'ont jamais été utilisés pour aller là.
ça ne reconnaît pas ce qui est saisi (ou ce qui est renvoyé).
J'espère que ton fichier de MdP en contient plusieurs et que tu as essayé sur chacun ? Histoire d'écarter la fôte de frappe réitérée à l'infini. (on peut de bonne fois s'évertuer à entrer un login sans s'appercevoir que ce n'est pas exactement le bon)
tout refaire "propre" ? (y compris le ftp)
Réinstaller le système ? J'y pense mais j'ai un doute sur l'efficacité de la manip.
non quand même pas ;-) ! Je voulais juste dire de réécrire les fichiers en les enregistrant aux bons endroit (sans s'amuser à les glisser ensuite d'un dossier à l'autre)
je suis bloqué (enfin pour cette fonctionnalité). J'ai vu qu'il existe un "external" pour rapidweaver qui offre une
Je me méfie comme de la peste de ces usines à créer des fichiers web rien le vaut le labeur à la mimine
interface graphique pour gérer ces fichiers, mais j'ai peur de dépenser 10 euros pour rien.
10 euros pour écrire un fichier de 4 à 6 lignes et un autre d'autant de lignes que de logins ??? économise ! économise !
Chez moi ! Sur un MacMINI de 2006 sous Snow Leopard en utilisant les
fonctionnalité du serveur Apache intégré à Mac OS X :
- Préférences Système : partage web
- Site créé avec RapidWeaver et copié en local dans le dossier "Sites"
d'un utilisateur lambda du MacMINI
ça, ça me gène ... le coup du "copié"
qu'en pense le serveur ensuite ?
les droits des fichiers sont-ils les bons ?
il faudrait faire un chmod à bon escient(*) sur les fichiers .htaccess
et .passwords
(*) je ne sais si un chmod 7777 conviendrait pour ces fichiers
- Positionnement du MINI en IP Fixe derrière une TimeCapsule qui gère
les redirections
- et qui est branchée en Ethernet sur une BBox complètement passive, sur
laquelle j'ai simplement ouvert le HTTP, et activé la redirection
dynamique du nom de domaine (vers DynDNS.org)
Ha Oui ! Quand même !
Et est-ce que l'accès protégé a eu fonctionné un jour ?
Ou bien est-ce tes premiers essais.
bien entendu, tous les fichiers sont écrits avec le même charset ?
En utf-8, par exemple.
(ou, à minima, en ISO-8859-1)
Je soupçonne effectivement une merde à ce niveau-là. J'ai créé (et
re-créé) ces fichiers avec TextEdit, demandé le passage en "texte" et
sauvegardé en UTF-8...
Oui ... bon ... même s'il est censé y arriver, ça se mérite trop pour
être certain de ne pas avoir fait une erreur qque part.
Comment en savoir plus sur les caractéristiques du fichier ?
Faut-il utiliser un autre éditeur ? TextWrangler ? Smultron
À défaut de BBEdit, j'opterais volontiers pour TextWrangler
(TextEdit est trop difficile à dompter, je trouve)
Smultron, oui sans doute (bien que pour un fichier texte de MdP ...)
Essayer depuis un ordi et une connexion qui n'ont jamais été utilisés
pour aller là.
ça ne reconnaît pas ce qui est saisi (ou ce qui est renvoyé).
J'espère que ton fichier de MdP en contient plusieurs et que tu as
essayé sur chacun ?
Histoire d'écarter la fôte de frappe réitérée à l'infini. (on peut de
bonne fois s'évertuer à entrer un login sans s'appercevoir que ce n'est
pas exactement le bon)
tout refaire "propre" ?
(y compris le ftp)
Réinstaller le système ? J'y pense mais j'ai un doute sur l'efficacité
de la manip.
non quand même pas ;-) !
Je voulais juste dire de réécrire les fichiers en les enregistrant aux
bons endroit (sans s'amuser à les glisser ensuite d'un dossier à l'autre)
je suis bloqué (enfin pour cette fonctionnalité).
J'ai vu qu'il existe un "external" pour rapidweaver qui offre une
Je me méfie comme de la peste de ces usines à créer des fichiers web
rien le vaut le labeur à la mimine
interface graphique pour gérer ces fichiers, mais j'ai peur de dépenser
10 euros pour rien.
10 euros pour écrire un fichier de 4 à 6 lignes et un autre d'autant de
lignes que de logins ???
économise ! économise !
Chez moi ! Sur un MacMINI de 2006 sous Snow Leopard en utilisant les fonctionnalité du serveur Apache intégré à Mac OS X : - Préférences Système : partage web - Site créé avec RapidWeaver et copié en local dans le dossier "Sites" d'un utilisateur lambda du MacMINI
ça, ça me gène ... le coup du "copié" qu'en pense le serveur ensuite ? les droits des fichiers sont-ils les bons ?
il faudrait faire un chmod à bon escient(*) sur les fichiers .htaccess et .passwords
(*) je ne sais si un chmod 7777 conviendrait pour ces fichiers
- Positionnement du MINI en IP Fixe derrière une TimeCapsule qui gère les redirections - et qui est branchée en Ethernet sur une BBox complètement passive, sur laquelle j'ai simplement ouvert le HTTP, et activé la redirection dynamique du nom de domaine (vers DynDNS.org)
Ha Oui ! Quand même !
Et est-ce que l'accès protégé a eu fonctionné un jour ? Ou bien est-ce tes premiers essais.
bien entendu, tous les fichiers sont écrits avec le même charset ? En utf-8, par exemple. (ou, à minima, en ISO-8859-1)
Je soupçonne effectivement une merde à ce niveau-là. J'ai créé (et re-créé) ces fichiers avec TextEdit, demandé le passage en "texte" et sauvegardé en UTF-8...
Oui ... bon ... même s'il est censé y arriver, ça se mérite trop pour être certain de ne pas avoir fait une erreur qque part.
Comment en savoir plus sur les caractéristiques du fichier ? Faut-il utiliser un autre éditeur ? TextWrangler ? Smultron
À défaut de BBEdit, j'opterais volontiers pour TextWrangler (TextEdit est trop difficile à dompter, je trouve) Smultron, oui sans doute (bien que pour un fichier texte de MdP ...)
Essayer depuis un ordi et une connexion qui n'ont jamais été utilisés pour aller là.
ça ne reconnaît pas ce qui est saisi (ou ce qui est renvoyé).
J'espère que ton fichier de MdP en contient plusieurs et que tu as essayé sur chacun ? Histoire d'écarter la fôte de frappe réitérée à l'infini. (on peut de bonne fois s'évertuer à entrer un login sans s'appercevoir que ce n'est pas exactement le bon)
tout refaire "propre" ? (y compris le ftp)
Réinstaller le système ? J'y pense mais j'ai un doute sur l'efficacité de la manip.
non quand même pas ;-) ! Je voulais juste dire de réécrire les fichiers en les enregistrant aux bons endroit (sans s'amuser à les glisser ensuite d'un dossier à l'autre)
je suis bloqué (enfin pour cette fonctionnalité). J'ai vu qu'il existe un "external" pour rapidweaver qui offre une
Je me méfie comme de la peste de ces usines à créer des fichiers web rien le vaut le labeur à la mimine
interface graphique pour gérer ces fichiers, mais j'ai peur de dépenser 10 euros pour rien.
10 euros pour écrire un fichier de 4 à 6 lignes et un autre d'autant de lignes que de logins ??? économise ! économise !
-- Stéphane Moriaux avec/with iMac-intel
SAM
Le 24/10/11 17:22, Denis Beauregard a écrit :
Si on édite sur Mac et que le serveur est un Linux, le .htaccess n'a pas d'extension et peut-être que le logiciel FTP ne fait pas la conversion des fins de ligne. J'essaierais soit d'éditer les fichiers directement sur le serveur, soit de changer l'extension (exemple : .txt) lors du téléversement au serveur.
Bon, là en l'occurrence il n'y a ps de ftp tout est fait directement sur l'ordi qui fait serveur web
éditer un fichier caché sur le serveur ... ça ne m'est pas évident. (jamais essayé)(compliqué ... login étoussa)
Sinon, pour ma part, un .htaccess est écrit (copié/collé) grâce à un éditeur-texte respectueux de l'encodage que je lui précise. Le fichier est sauvegardé sur l'ordi avec n'importe quel nom et, si suffixe, ce serait : txt Le fichier est uploadé sur le site en ftp puis renommé sur le site (en .htacces) À partir de ce moment mon logiciel de ftp ne le voit plus sur le site. (à chaque modif j'en uploade et renomme un autre)
-- Stéphane Moriaux avec/with iMac-intel
Le 24/10/11 17:22, Denis Beauregard a écrit :
Si on édite sur Mac et que le serveur est un Linux, le .htaccess
n'a pas d'extension et peut-être que le logiciel FTP ne fait pas
la conversion des fins de ligne. J'essaierais soit d'éditer les
fichiers directement sur le serveur, soit de changer l'extension
(exemple : .txt) lors du téléversement au serveur.
Bon, là en l'occurrence il n'y a ps de ftp
tout est fait directement sur l'ordi qui fait serveur web
éditer un fichier caché sur le serveur ... ça ne m'est pas évident.
(jamais essayé)(compliqué ... login étoussa)
Sinon, pour ma part, un .htaccess est écrit (copié/collé) grâce à un
éditeur-texte respectueux de l'encodage que je lui précise.
Le fichier est sauvegardé sur l'ordi avec n'importe quel nom et, si
suffixe, ce serait : txt
Le fichier est uploadé sur le site en ftp
puis renommé sur le site (en .htacces)
À partir de ce moment mon logiciel de ftp ne le voit plus sur le site.
(à chaque modif j'en uploade et renomme un autre)
Si on édite sur Mac et que le serveur est un Linux, le .htaccess n'a pas d'extension et peut-être que le logiciel FTP ne fait pas la conversion des fins de ligne. J'essaierais soit d'éditer les fichiers directement sur le serveur, soit de changer l'extension (exemple : .txt) lors du téléversement au serveur.
Bon, là en l'occurrence il n'y a ps de ftp tout est fait directement sur l'ordi qui fait serveur web
éditer un fichier caché sur le serveur ... ça ne m'est pas évident. (jamais essayé)(compliqué ... login étoussa)
Sinon, pour ma part, un .htaccess est écrit (copié/collé) grâce à un éditeur-texte respectueux de l'encodage que je lui précise. Le fichier est sauvegardé sur l'ordi avec n'importe quel nom et, si suffixe, ce serait : txt Le fichier est uploadé sur le site en ftp puis renommé sur le site (en .htacces) À partir de ce moment mon logiciel de ftp ne le voit plus sur le site. (à chaque modif j'en uploade et renomme un autre)
