htaccess et erreur 401

Le
Gerald
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.

Si quelqu'un a une idée, d'avance merci.

--
Gérald
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Yop
Le #23898211
Si quelqu'un a une idée, d'avance merci.



De mémoire, le chemin indiquant htpasswd
doit etre complet dans htaccess
AuthUserFile /home/web/ton/chemin/.htpasswd

Y
Gerald
Le #23898311
Yop
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 #23898301
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.
SAM
Le #23898561
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
Gerald
Le #23898901
SAM
Ç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
Gerald
Le #23898891
Vincent
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 #23898961
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 #23899041
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.

Cf.

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 #23900541
Le 24/10/11 17:13, Gerald a écrit :
SAM
Ç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 !

--
Stéphane Moriaux avec/with iMac-intel
SAM
Le #23900601
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
Publicité
Poster une réponse
Anonyme