Sur un site hébergé chez free, j'ai des dossiers protégés avec un pwd
qui fonctionne. Mais en interne (sur le site miroir), les même dossiers
s'ouvrent sans demander le pwd.
J'ai également le même pb avec un site html puisqu'il est en interne.
Quand je le teste depuis chez moi en interne .htaccess (invisible dans
le finder mais bien présent où il faut) n'est pas reconnu et ne
fonctionne pas. Depuis l'extérieur, je ne sais pas encore si ça
fonctionne car je ne peux pas le tester pour l'instant. Ce serait apache
qui ne le reconnait pas tel quel ?
Savez-pourquoi ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
patpro
In article <1g4tmpl.10w8xs912xzupsN%, (Bernd) wrote:
Hi à vous,
Sur un site hébergé chez free, j'ai des dossiers protégés avec un pwd qui fonctionne. Mais en interne (sur le site miroir), les même dossiers s'ouvrent sans demander le pwd. J'ai également le même pb avec un site html puisqu'il est en interne. Quand je le teste depuis chez moi en interne .htaccess (invisible dans le finder mais bien présent où il faut) n'est pas reconnu et ne fonctionne pas. Depuis l'extérieur, je ne sais pas encore si ça fonctionne car je ne peux pas le tester pour l'instant. Ce serait apache qui ne le reconnait pas tel quel ? Savez-pourquoi ?
cherche dans la doc apache au niveau de la directive "AllowOverride", ça t'expliquera comment ca marche et quoi faire pour obtenir le comportement souhaité. Ensuite, tu verras ce qui t'interesse le plus : faire les modif au niveau /etc/httpd/httpd.conf, ou au niveau /etc/httpd/users/<tonlogin>.conf
patpro
-- je cherche un poste d'admin UNIX/Mac
In article <1g4tmpl.10w8xs912xzupsN%boustrophedon@free.fr>,
boustrophedon@free.fr (Bernd) wrote:
Hi à vous,
Sur un site hébergé chez free, j'ai des dossiers protégés avec un pwd
qui fonctionne. Mais en interne (sur le site miroir), les même dossiers
s'ouvrent sans demander le pwd.
J'ai également le même pb avec un site html puisqu'il est en interne.
Quand je le teste depuis chez moi en interne .htaccess (invisible dans
le finder mais bien présent où il faut) n'est pas reconnu et ne
fonctionne pas. Depuis l'extérieur, je ne sais pas encore si ça
fonctionne car je ne peux pas le tester pour l'instant. Ce serait apache
qui ne le reconnait pas tel quel ?
Savez-pourquoi ?
cherche dans la doc apache au niveau de la directive "AllowOverride", ça
t'expliquera comment ca marche et quoi faire pour obtenir le
comportement souhaité.
Ensuite, tu verras ce qui t'interesse le plus : faire les modif au
niveau /etc/httpd/httpd.conf, ou au niveau
/etc/httpd/users/<tonlogin>.conf
In article <1g4tmpl.10w8xs912xzupsN%, (Bernd) wrote:
Hi à vous,
Sur un site hébergé chez free, j'ai des dossiers protégés avec un pwd qui fonctionne. Mais en interne (sur le site miroir), les même dossiers s'ouvrent sans demander le pwd. J'ai également le même pb avec un site html puisqu'il est en interne. Quand je le teste depuis chez moi en interne .htaccess (invisible dans le finder mais bien présent où il faut) n'est pas reconnu et ne fonctionne pas. Depuis l'extérieur, je ne sais pas encore si ça fonctionne car je ne peux pas le tester pour l'instant. Ce serait apache qui ne le reconnait pas tel quel ? Savez-pourquoi ?
cherche dans la doc apache au niveau de la directive "AllowOverride", ça t'expliquera comment ca marche et quoi faire pour obtenir le comportement souhaité. Ensuite, tu verras ce qui t'interesse le plus : faire les modif au niveau /etc/httpd/httpd.conf, ou au niveau /etc/httpd/users/<tonlogin>.conf
patpro
-- je cherche un poste d'admin UNIX/Mac
boustrophedon
Paul Guyot wrote:
Sur un site hébergé chez free, j'ai des dossiers protégés avec un pwd qui fonctionne. Mais en interne (sur le site miroir), les même dossiers s'ouvrent sans demander le pwd.
En dehors du problème de devoir activer le .htaccess (avec AllowOverride), je crois que Free n'utilise pas la commande standard. Le mécanisme de mot de passe avec le même fichier .htaccess ne peut pas fonctionner chez eux et sur ta machine sous MacOS X.
Justement sur un site hébergé par Free, les dossiers sont protégés par pwd et ça fonctionne - c'est sur un serveur http hébergé sur mon Mac dans le dossier webserveur/Documents que cela ne fonctionne pas. Free n'intervient pas dans l'opération à ce niveau. -- A+
Bernd
Paul Guyot <spam@kallisys.com> wrote:
Sur un site hébergé chez free, j'ai des dossiers protégés avec un pwd
qui fonctionne. Mais en interne (sur le site miroir), les même dossiers
s'ouvrent sans demander le pwd.
En dehors du problème de devoir activer le .htaccess (avec AllowOverride),
je crois que Free n'utilise pas la commande standard. Le mécanisme de mot
de passe avec le même fichier .htaccess ne peut pas fonctionner chez eux et
sur ta machine sous MacOS X.
Justement sur un site hébergé par Free, les dossiers sont protégés par
pwd et ça fonctionne - c'est sur un serveur http hébergé sur mon Mac
dans le dossier webserveur/Documents que cela ne fonctionne pas. Free
n'intervient pas dans l'opération à ce niveau.
--
A+
Sur un site hébergé chez free, j'ai des dossiers protégés avec un pwd qui fonctionne. Mais en interne (sur le site miroir), les même dossiers s'ouvrent sans demander le pwd.
En dehors du problème de devoir activer le .htaccess (avec AllowOverride), je crois que Free n'utilise pas la commande standard. Le mécanisme de mot de passe avec le même fichier .htaccess ne peut pas fonctionner chez eux et sur ta machine sous MacOS X.
Justement sur un site hébergé par Free, les dossiers sont protégés par pwd et ça fonctionne - c'est sur un serveur http hébergé sur mon Mac dans le dossier webserveur/Documents que cela ne fonctionne pas. Free n'intervient pas dans l'opération à ce niveau. -- A+
Bernd
pseudononame
Bernd wrote:
Paul Guyot wrote:
Sur un site hébergé chez free, j'ai des dossiers protégés avec un pwd qui fonctionne. Mais en interne (sur le site miroir), les même dossiers s'ouvrent sans demander le pwd.
En dehors du problème de devoir activer le .htaccess (avec AllowOverride), je crois que Free n'utilise pas la commande standard. Le mécanisme de mot de passe avec le même fichier .htaccess ne peut pas fonctionner chez eux et sur ta machine sous MacOS X.
Justement sur un site hébergé par Free, les dossiers sont protégés par pwd et ça fonctionne - c'est sur un serveur http hébergé sur mon Mac dans le dossier webserveur/Documents que cela ne fonctionne pas. Free n'intervient pas dans l'opération à ce niveau. -- A+
Bernd Pour que ca fonctionne il faut décommenter des lignes de configuration
relatives à .htaccess dans httpd.conf par contre je ne sais pas où il se trouve dans mac... sur linux en générale il se trouve (enfin pour slackware et debian) dans /etc/apache/ bon courage, à bientôt -- sanctius °°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°° Veuillez supprimer [nospam] de mon adresse pour me répondre en privé. Le spam est un fléau qu'il est important de réduire.
Bernd wrote:
Paul Guyot <spam@kallisys.com> wrote:
Sur un site hébergé chez free, j'ai des dossiers protégés avec un pwd
qui fonctionne. Mais en interne (sur le site miroir), les même dossiers
s'ouvrent sans demander le pwd.
En dehors du problème de devoir activer le .htaccess (avec
AllowOverride), je crois que Free n'utilise pas la commande standard. Le
mécanisme de mot de passe avec le même fichier .htaccess ne peut pas
fonctionner chez eux et sur ta machine sous MacOS X.
Justement sur un site hébergé par Free, les dossiers sont protégés par
pwd et ça fonctionne - c'est sur un serveur http hébergé sur mon Mac
dans le dossier webserveur/Documents que cela ne fonctionne pas. Free
n'intervient pas dans l'opération à ce niveau.
--
A+
Bernd
Pour que ca fonctionne il faut décommenter des lignes de configuration
relatives à .htaccess dans httpd.conf
par contre je ne sais pas où il se trouve dans mac... sur linux en générale
il se trouve (enfin pour slackware et debian) dans /etc/apache/
bon courage,
à bientôt
--
sanctius
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Veuillez supprimer [nospam] de mon adresse pour me répondre en privé.
Le spam est un fléau qu'il est important de réduire.
Sur un site hébergé chez free, j'ai des dossiers protégés avec un pwd qui fonctionne. Mais en interne (sur le site miroir), les même dossiers s'ouvrent sans demander le pwd.
En dehors du problème de devoir activer le .htaccess (avec AllowOverride), je crois que Free n'utilise pas la commande standard. Le mécanisme de mot de passe avec le même fichier .htaccess ne peut pas fonctionner chez eux et sur ta machine sous MacOS X.
Justement sur un site hébergé par Free, les dossiers sont protégés par pwd et ça fonctionne - c'est sur un serveur http hébergé sur mon Mac dans le dossier webserveur/Documents que cela ne fonctionne pas. Free n'intervient pas dans l'opération à ce niveau. -- A+
Bernd Pour que ca fonctionne il faut décommenter des lignes de configuration
relatives à .htaccess dans httpd.conf par contre je ne sais pas où il se trouve dans mac... sur linux en générale il se trouve (enfin pour slackware et debian) dans /etc/apache/ bon courage, à bientôt -- sanctius °°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°° Veuillez supprimer [nospam] de mon adresse pour me répondre en privé. Le spam est un fléau qu'il est important de réduire.
Henri.Balmain
Paul Guyot wrote:
In article (Dans l'article) <1g4tmpl.10w8xs912xzupsN%, (Bernd) wrote (écrivait) :
Sur un site hébergé chez free, j'ai des dossiers protégés avec un pwd qui fonctionne. Mais en interne (sur le site miroir), les même dossiers s'ouvrent sans demander le pwd.
En dehors du problème de devoir activer le .htaccess (avec AllowOverride), je crois que Free n'utilise pas la commande standard. Le mécanisme de mot de passe avec le même fichier .htaccess ne peut pas fonctionner chez eux et sur ta machine sous MacOS X.
oui, la dernière fois que j'ai regardé, leurs .htaccess indiquent le chemin absolu du fichier passlist qui contient le couple identifiant/mot de passe, donc ça ne peut pas marcher si on se contente de recopier le fichier tel quel, et si on oublie aussi le fichier passlist
il faut d'abord le mettre en chemin relatif depuis la racine spip, soit /ecrire/data/passlist
après, ça doit être une question de réglage d'apache mais ausi je remarque que le texte du ht.access de free parait invoquer un commande perl, alors que perl n'est pas activé d'origine dans l'apache de mac os x
peut-être une solution, chez moi ça ne marche pas non plus, ni en réseau depuis l'ibouc de ma douce.
Henri
Paul Guyot <spam@kallisys.com> wrote:
In article (Dans l'article)
<1g4tmpl.10w8xs912xzupsN%boustrophedon@free.fr>,
boustrophedon@free.fr (Bernd) wrote (écrivait) :
Sur un site hébergé chez free, j'ai des dossiers protégés avec un pwd
qui fonctionne. Mais en interne (sur le site miroir), les même dossiers
s'ouvrent sans demander le pwd.
En dehors du problème de devoir activer le .htaccess (avec AllowOverride),
je crois que Free n'utilise pas la commande standard. Le mécanisme de mot
de passe avec le même fichier .htaccess ne peut pas fonctionner chez eux et
sur ta machine sous MacOS X.
oui, la dernière fois que j'ai regardé, leurs .htaccess indiquent le
chemin absolu du fichier passlist qui contient le couple identifiant/mot
de passe, donc ça ne peut pas marcher si on se contente de recopier le
fichier tel quel, et si on oublie aussi le fichier passlist
il faut d'abord le mettre en chemin relatif depuis la racine spip, soit
/ecrire/data/passlist
après, ça doit être une question de réglage d'apache
mais ausi je remarque que le texte du ht.access de free parait invoquer
un commande perl, alors que perl n'est pas activé d'origine dans
l'apache de mac os x
In article (Dans l'article) <1g4tmpl.10w8xs912xzupsN%, (Bernd) wrote (écrivait) :
Sur un site hébergé chez free, j'ai des dossiers protégés avec un pwd qui fonctionne. Mais en interne (sur le site miroir), les même dossiers s'ouvrent sans demander le pwd.
En dehors du problème de devoir activer le .htaccess (avec AllowOverride), je crois que Free n'utilise pas la commande standard. Le mécanisme de mot de passe avec le même fichier .htaccess ne peut pas fonctionner chez eux et sur ta machine sous MacOS X.
oui, la dernière fois que j'ai regardé, leurs .htaccess indiquent le chemin absolu du fichier passlist qui contient le couple identifiant/mot de passe, donc ça ne peut pas marcher si on se contente de recopier le fichier tel quel, et si on oublie aussi le fichier passlist
il faut d'abord le mettre en chemin relatif depuis la racine spip, soit /ecrire/data/passlist
après, ça doit être une question de réglage d'apache mais ausi je remarque que le texte du ht.access de free parait invoquer un commande perl, alors que perl n'est pas activé d'origine dans l'apache de mac os x
peut-être une solution, chez moi ça ne marche pas non plus, ni en réseau depuis l'ibouc de ma douce.
Chez Free, ça marche bien. Pour preuve, aller voir à http://jomain.free.fr/ et cliquez sur généalogie.
C'est pour un serveur http dans le dossier webserver du DD que ça ne marche pas.
heu.. c'est bien ce que je dis ;-)
Henri
boustrophedon
Henri Balmain wrote:
C'est pour un serveur http dans le dossier webserver du DD que ça ne marche pas.
heu.. c'est bien ce que je dis ;-)
Je n'avais pas perçu - Cela dit, j'attends avec impatience que ceux chez qui ça fonctionne nous disent pourquoi et comment ils font parce que pour ce coup là je rame depuis hier soir.
-- A+
Bernd
Henri Balmain <Henri.Balmain@wanadoo.fr> wrote:
C'est pour un serveur http dans le dossier webserver du DD que ça ne
marche pas.
heu.. c'est bien ce que je dis ;-)
Je n'avais pas perçu - Cela dit, j'attends avec impatience que ceux chez
qui ça fonctionne nous disent pourquoi et comment ils font parce que
pour ce coup là je rame depuis hier soir.
C'est pour un serveur http dans le dossier webserver du DD que ça ne marche pas.
heu.. c'est bien ce que je dis ;-)
Je n'avais pas perçu - Cela dit, j'attends avec impatience que ceux chez qui ça fonctionne nous disent pourquoi et comment ils font parce que pour ce coup là je rame depuis hier soir.
-- A+
Bernd
Henri.Balmain
Bernd wrote:
Henri Balmain wrote:
C'est pour un serveur http dans le dossier webserver du DD que ça ne marche pas.
heu.. c'est bien ce que je dis ;-)
Je n'avais pas perçu - Cela dit, j'attends avec impatience que ceux chez qui ça fonctionne nous disent pourquoi et comment ils font parce que pour ce coup là je rame depuis hier soir.
moi aussi, de quoi occuper un dimanche grippal j'ai copié mutadis mutandis les fichiers protégeant les accès spip de "ecrire" et ça marche pour "écrire" et pas pour mon dossier "club"
je bute sur quoi mettre en face de la directive AuthName, dans le htacces d'écrire il y a "administrateur" ce qui correspond sans doute à une liste de valeur définie quelque part dans spip ... dnas le doute j'ai mis l'identifiant de l'user autorisé sur ce dossier et j'ai même essayé avec administrateur, ça ne marche pas ...
MDR
ma seule consolation a été de m'apercevoir que Golive ml'avait foutu le boxon dans les appels d'image en indiquant un chemin absolu sur mon disque. Un coup de BBEdit sur les dossiers contenant mes squelette, rechercher remplacer file: par rien dans le dossier et hop..., pis j'ai fait la mise à jour de spip en 1.6 "free" (uniquement .php)
pour j'en viens à me demander si ce n'est pas un mauvais réglage des fichiers obtenu, pourtant non, BBEdit permet de choisir d'honnêtes fichiers système bruts de ches bruts sans icone, et c'est bien ce que j'ai fait.
Henri
Bernd <boustrophedon@free.fr> wrote:
Henri Balmain <Henri.Balmain@wanadoo.fr> wrote:
C'est pour un serveur http dans le dossier webserver du DD que ça ne
marche pas.
heu.. c'est bien ce que je dis ;-)
Je n'avais pas perçu - Cela dit, j'attends avec impatience que ceux chez
qui ça fonctionne nous disent pourquoi et comment ils font parce que
pour ce coup là je rame depuis hier soir.
moi aussi, de quoi occuper un dimanche grippal
j'ai copié mutadis mutandis les fichiers protégeant les accès spip de
"ecrire" et ça marche pour "écrire" et pas pour mon dossier "club"
je bute sur quoi mettre en face de la directive AuthName, dans le
htacces d'écrire il y a "administrateur" ce qui correspond sans doute à
une liste de valeur définie quelque part dans spip ...
dnas le doute j'ai mis l'identifiant de l'user autorisé sur ce dossier
et j'ai même essayé avec administrateur, ça ne marche pas ...
MDR
ma seule consolation a été de m'apercevoir que Golive ml'avait foutu le
boxon dans les appels d'image en indiquant un chemin absolu sur mon
disque. Un coup de BBEdit sur les dossiers contenant mes squelette,
rechercher remplacer file: par rien dans le dossier et hop..., pis j'ai
fait la mise à jour de spip en 1.6 "free" (uniquement .php)
pour j'en viens à me demander si ce n'est pas un mauvais réglage des
fichiers obtenu, pourtant non, BBEdit permet de choisir d'honnêtes
fichiers système bruts de ches bruts sans icone, et c'est bien ce que
j'ai fait.
C'est pour un serveur http dans le dossier webserver du DD que ça ne marche pas.
heu.. c'est bien ce que je dis ;-)
Je n'avais pas perçu - Cela dit, j'attends avec impatience que ceux chez qui ça fonctionne nous disent pourquoi et comment ils font parce que pour ce coup là je rame depuis hier soir.
moi aussi, de quoi occuper un dimanche grippal j'ai copié mutadis mutandis les fichiers protégeant les accès spip de "ecrire" et ça marche pour "écrire" et pas pour mon dossier "club"
je bute sur quoi mettre en face de la directive AuthName, dans le htacces d'écrire il y a "administrateur" ce qui correspond sans doute à une liste de valeur définie quelque part dans spip ... dnas le doute j'ai mis l'identifiant de l'user autorisé sur ce dossier et j'ai même essayé avec administrateur, ça ne marche pas ...
MDR
ma seule consolation a été de m'apercevoir que Golive ml'avait foutu le boxon dans les appels d'image en indiquant un chemin absolu sur mon disque. Un coup de BBEdit sur les dossiers contenant mes squelette, rechercher remplacer file: par rien dans le dossier et hop..., pis j'ai fait la mise à jour de spip en 1.6 "free" (uniquement .php)
pour j'en viens à me demander si ce n'est pas un mauvais réglage des fichiers obtenu, pourtant non, BBEdit permet de choisir d'honnêtes fichiers système bruts de ches bruts sans icone, et c'est bien ce que j'ai fait.
Henri
boustrophedon
Henri Balmain wrote:
je bute sur quoi mettre en face de la directive AuthName, dans le htacces d'écrire il y a "administrateur" ce qui correspond sans doute à une liste de valeur définie quelque part dans spip ...
Je ne vois pas ce que tu veux dire - Derrière AuthName on écrit un truc du genre "accès protégé".
ma seule consolation a été de m'apercevoir que Golive ml'avait foutu le boxon dans les appels d'image en indiquant un chemin absolu sur mon disque. Un coup de BBEdit sur les dossiers contenant mes squelette, rechercher remplacer file: par rien dans le dossier et hop..., pis j'ai fait la mise à jour de spip en 1.6 "free" (uniquement .php)
Même chose avec Dreamweaver - il a fallu faire tous les liens à la main dans le code de la page. Ils faisaient tous une erreur.
pour j'en viens à me demander si ce n'est pas un mauvais réglage des fichiers obtenu, pourtant non, BBEdit permet de choisir d'honnêtes fichiers système bruts de ches bruts sans icone, et c'est bien ce que j'ai fait.
Je n'utilise plus que BBedit aussi.
Donc, on passe par les mêmes galères. -- A+
Bernd
Henri Balmain <Henri.Balmain@wanadoo.fr> wrote:
je bute sur quoi mettre en face de la directive AuthName, dans le
htacces d'écrire il y a "administrateur" ce qui correspond sans doute à
une liste de valeur définie quelque part dans spip ...
Je ne vois pas ce que tu veux dire - Derrière AuthName on écrit un truc
du genre "accès protégé".
ma seule consolation a été de m'apercevoir que Golive ml'avait foutu le
boxon dans les appels d'image en indiquant un chemin absolu sur mon
disque. Un coup de BBEdit sur les dossiers contenant mes squelette,
rechercher remplacer file: par rien dans le dossier et hop..., pis j'ai
fait la mise à jour de spip en 1.6 "free" (uniquement .php)
Même chose avec Dreamweaver - il a fallu faire tous les liens à la main
dans le code de la page. Ils faisaient tous une erreur.
pour j'en viens à me demander si ce n'est pas un mauvais réglage des
fichiers obtenu, pourtant non, BBEdit permet de choisir d'honnêtes
fichiers système bruts de ches bruts sans icone, et c'est bien ce que
j'ai fait.
je bute sur quoi mettre en face de la directive AuthName, dans le htacces d'écrire il y a "administrateur" ce qui correspond sans doute à une liste de valeur définie quelque part dans spip ...
Je ne vois pas ce que tu veux dire - Derrière AuthName on écrit un truc du genre "accès protégé".
ma seule consolation a été de m'apercevoir que Golive ml'avait foutu le boxon dans les appels d'image en indiquant un chemin absolu sur mon disque. Un coup de BBEdit sur les dossiers contenant mes squelette, rechercher remplacer file: par rien dans le dossier et hop..., pis j'ai fait la mise à jour de spip en 1.6 "free" (uniquement .php)
Même chose avec Dreamweaver - il a fallu faire tous les liens à la main dans le code de la page. Ils faisaient tous une erreur.
pour j'en viens à me demander si ce n'est pas un mauvais réglage des fichiers obtenu, pourtant non, BBEdit permet de choisir d'honnêtes fichiers système bruts de ches bruts sans icone, et c'est bien ce que j'ai fait.
Pour que ca fonctionne il faut décommenter des lignes de configuration relatives à .htaccess dans httpd.conf par contre je ne sais pas où il se trouve dans mac...
le fichier httpd.conf est fourni avec les .htaccess décommentés, en principe il n'y a que php à activer
Pour que ca fonctionne il faut décommenter des lignes de configuration
relatives à .htaccess dans httpd.conf
par contre je ne sais pas où il se trouve dans mac...
le fichier httpd.conf est fourni avec les .htaccess décommentés, en
principe il n'y a que php à activer
Pour que ca fonctionne il faut décommenter des lignes de configuration relatives à .htaccess dans httpd.conf par contre je ne sais pas où il se trouve dans mac...
le fichier httpd.conf est fourni avec les .htaccess décommentés, en principe il n'y a que php à activer
