Onderwerp: Probleem met .htpasswd bij gebruik van RewriteEngine

Hallo,

Een tijdje geleden vroeg ik hier hulp i.v.m. de RewriteEngine binnen
..htaccess, zie http://tinyurl.com/63gov (Google Groups).

Momenteel gebruik ik deze code in mijn .htaccess bestand:

RewriteEngine on
RewriteCond %{REQUEST_URI} !^/cgi-bin
RewriteCond %{HTTP_HOST} ^www.domein1.be$ [OR]
RewriteCond %{HTTP_HOST} ^domein1.be$ [OR]
RewriteCond %{HTTP_HOST} ^www.domein2.be$ [OR]
RewriteCond %{HTTP_HOST} ^domein2.be$
RewriteRule ^(.*)$ http://subdomein.domein1.be/$1 [L]

Wat er dus voor zorget dat domein1 en domein2 worden doorverwezen naar
subdomein.domein1.be, uitgezonderd de cgi-bin directory.

Dit werkt vlekkeloos maar heeft een vervelend nevenverschijnsel. Ik kan
namelijk niet meer inloggen in directories die beveiligd worden door een
..htpasswd. In plaats van het aanmeldingvenster krijg ik een 404 pagina.
Die wordt volgens mijn error log veroorzaakt doordat er op zoek wordt gegaan
naar het bestand /home/mijnaccount/public_html/subdomein/401.shtml.

Ik heb geen idee waarom. Ik heb nooit met een bestand 401.shtml gewerkt en
dit ook nooit ergens ingesteld. Heeft er iemand een idee wie of wat de
opdracht zou kunnen geven naar dit bestand op zoek te gaan? Dat zou me al
een stukje verder helpen in mijn zoektocht naar een oplossing.

Alvast bedankt.

Met vriendelijke groet,
Carl Janssen

Carl Janssen wrote:
> Hallo,
>
> Een tijdje geleden vroeg ik hier hulp i.v.m. de RewriteEngine binnen
> .htaccess, zie http://tinyurl.com/63gov (Google Groups).
>
> Momenteel gebruik ik deze code in mijn .htaccess bestand:
>
> RewriteEngine on
> RewriteCond %{REQUEST_URI} !^/cgi-bin
> RewriteCond %{HTTP_HOST} ^www.domein1.be$ [OR]
> RewriteCond %{HTTP_HOST} ^domein1.be$ [OR]
> RewriteCond %{HTTP_HOST} ^www.domein2.be$ [OR]
> RewriteCond %{HTTP_HOST} ^domein2.be$
> RewriteRule ^(.*)$ http://subdomein.domein1.be/$1 [L]
>
> Wat er dus voor zorget dat domein1 en domein2 worden doorverwezen naar
> subdomein.domein1.be, uitgezonderd de cgi-bin directory.
>
> Dit werkt vlekkeloos maar heeft een vervelend nevenverschijnsel. Ik kan
> namelijk niet meer inloggen in directories die beveiligd worden door een
> .htpasswd. In plaats van het aanmeldingvenster krijg ik een 404 pagina.
> Die wordt volgens mijn error log veroorzaakt doordat er op zoek wordt gegaan
> naar het bestand /home/mijnaccount/public_html/subdomein/401.shtml.
>
> Ik heb geen idee waarom. Ik heb nooit met een bestand 401.shtml gewerkt en
> dit ook nooit ergens ingesteld. Heeft er iemand een idee wie of wat de
> opdracht zou kunnen geven naar dit bestand op zoek te gaan? Dat zou me al
> een stukje verder helpen in mijn zoektocht naar een oplossing.

Net als 404 de HTTP-code is voor "object niet gevonden", is 401 de code
voor "Niet geauthoriseerd".

Het lijkt er op dat je hoster de server zo heeft ingesteld, dat je je
eigen 401-pagina kunt maken. De pagina die verschijnt als iemand niet
kan inloggen kun je dus zelf bepalen.

Zet gewoon eens wat tekst in die 401.shtml en kijk wat er gebeurt.

Edwin Martin.

--
http://www.bitstorm.org/

"Edwin Martin" <e.j.martin@chello.nl> schreef in bericht
news:Z%PPc.44215$i7.39769@amsnews05.chello.com...
>
> Net als 404 de HTTP-code is voor "object niet gevonden", is 401 de code
> voor "Niet geauthoriseerd".
>
> Het lijkt er op dat je hoster de server zo heeft ingesteld, dat je je
> eigen 401-pagina kunt maken. De pagina die verschijnt als iemand niet
> kan inloggen kun je dus zelf bepalen.
>
> Zet gewoon eens wat tekst in die 401.shtml en kijk wat er gebeurt.

Hm, ik heb me niet goed uitgedrukt vrees ik.

Ik heb namelijk helemaal geen 401.shtml bestand. Net daardoor wordt de 404
error gecreëerd. Ik werk al jaren met custom error pagina's. Ik heb er dus
ook eentje voor 401, 404, etc. En dat is het probleem dus niet.

Het probleem is dat ik bij het surfen naar een beveiligde directory geen
aanmeldvenster voor username en password krijg, maar dat er in de plaats
daarvan op zoek gegaan wordt naar 401.shtml. Waarom dat gebeurt weet ik
niet. Ik weet alleen dat:

1/ Als ik de RewriteEngine uit de .htaccess haal alles weer vlekkeloos
werkt.
2/ Het zo goed als zeker niets met mijn eigen ingestelde error pagina's te
maken heeft. Die eindigen namelijk op .php. En ze werken. Het feit dat ik
uiteindelijk op een 404.php uitkom omdat de 401.shtml niet kan gevonden
worden bewijst dat nog eens.

Met vriendelijke groet,
Carl Janssen

Carl Janssen schreef:
> Momenteel gebruik ik deze code in mijn .htaccess bestand:
>
> RewriteEngine on
> RewriteCond %{REQUEST_URI} !^/cgi-bin
> RewriteCond %{HTTP_HOST} ^www.domein1.be$ [OR]
> RewriteCond %{HTTP_HOST} ^domein1.be$ [OR]
> RewriteCond %{HTTP_HOST} ^www.domein2.be$ [OR]
> RewriteCond %{HTTP_HOST} ^domein2.be$
> RewriteRule ^(.*)$ http://subdomein.domein1.be/$1 [L]
>
> Wat er dus voor zorget dat domein1 en domein2 worden doorverwezen naar
> subdomein.domein1.be, uitgezonderd de cgi-bin directory.
>
> Dit werkt vlekkeloos maar heeft een vervelend nevenverschijnsel. Ik kan
> namelijk niet meer inloggen in directories die beveiligd worden door een
> .htpasswd. In plaats van het aanmeldingvenster krijg ik een 404 pagina.
> Die wordt volgens mijn error log veroorzaakt doordat er op zoek wordt gegaan
> naar het bestand /home/mijnaccount/public_html/subdomein/401.shtml.

Apache doet dit (ErrorDocument directive). Voor zover ik begrijp gebeurt
het volgende:

1. je roept een beschermde pagina op;

2. apache zend een 401 naar de client (browser) om een user/passwd;

3. die zou moeten reageren met een aanmeldingsvenster, maar doet dit
blijkbaar niet. Zou het kunnen dat door caching hij verkeerde gegevens
doorstuurt? Het user/passwd paar is namelijk ook gekoppeld aan een
'realm' en de server naam. Die laatste verander je in feite door die
Rewrite (denk ik).

4. doordat de server een verkeerd user/passwd krijgt, probeert hij een
401-pagina door te sturen (authorisation failed):
4a. apache is geconfigureerd om op zoek te gaan naar een 401, eventueel
met gekende extensies (zoals .shtml);
4b. 401.shtml wordt niet gevonden;
4c. apache genereerd een 404 (not found) die bij jou blijkbaar wel een
handler kent (=> 404.php).

't Probleem zit 'em in eerste instantie in (3). Je zou tenminste een
aanmeldingsvenster moeten krijgen van je browser. Cache clearen?

Door de rewrite loopt één en ander misschien mis. Helpt het als je iets als:
AuthType Basic
AuthName "Some 'realm', eg 'Private content'"
AuthUserFile /path/to/your/passwd
Require valid-user
in je .htaccess toevoegt?

Gewoon luidop aan 't denken...

Mvg,
Robrecht

"Robrecht Jacques" <Robrecht.Jacques@advalvas.be> schreef in bericht
news:41100c06$0$385$ba620e4c@news.skynet.be...
>
> Apache doet dit (ErrorDocument directive). Voor zover ik begrijp gebeurt
> het volgende:
>
> 1. je roept een beschermde pagina op;

Juist.

> 2. apache zend een 401 naar de client (browser) om een user/passwd;

Juist.

> 3. die zou moeten reageren met een aanmeldingsvenster, maar doet dit
> blijkbaar niet. Zou het kunnen dat door caching hij verkeerde gegevens
> doorstuurt? Het user/passwd paar is namelijk ook gekoppeld aan een
> 'realm' en de server naam. Die laatste verander je in feite door die
> Rewrite (denk ik).

Net de cache even leeggemaakt, maar dat levert me niets op. :-(

> 4. doordat de server een verkeerd user/passwd krijgt, probeert hij een
> 401-pagina door te sturen (authorisation failed):
> 4a. apache is geconfigureerd om op zoek te gaan naar een 401, eventueel
> met gekende extensies (zoals .shtml);
> 4b. 401.shtml wordt niet gevonden;
> 4c. apache genereerd een 404 (not found) die bij jou blijkbaar wel een
> handler kent (=> 404.php).

Klopt, maar daar is dus wat vreemd aan de hand. In mijn .htaccess is wel
degelijk ook een handler voor 401 gedefinieerd. Nu heb ik echter wel net
'ontdekt' dat die om de één of andere reden niet blijkt te werken. Vreemd,
want de syntax is hetzelfde opgebouwd als voor de andere error codes, nl.

ErrorDocument 401 http://www.mijndomein.be/error/error.php?code=401 en dit
bestand bestaat wel degelijk.

Nou ja, da's dus een ander probleem en verklaard inderdaad meer dan
waarschijnlijk waarom er op zoek wordt gegaan naar die 401.shtml.

> 't Probleem zit 'em in eerste instantie in (3). Je zou tenminste een
> aanmeldingsvenster moeten krijgen van je browser. Cache clearen?

Voilà, dat is dus het hoofdprobleem. Vergeet die 401.shtml even. Het
voornaamste probleem is dat ik geen aanmeldingsvenster krijg. Als ik de
RewriteEngine code uit m'n .htaccess zwier krijg ik dat venster dus wel.

> Door de rewrite loopt één en ander misschien mis

Je hebt het probleem duidelijk begrepen. ;-)

> Helpt het als je iets als:
> AuthType Basic
> AuthName "Some 'realm', eg 'Private content'"
> AuthUserFile /path/to/your/passwd
> Require valid-user
> in je .htaccess toevoegt?

Nu volg ik je even niet. Laat me eerst even duidelijk stellen dat het hier
eigenlijk over twee .htaccess bestanden gaat. Het .htaccess bestand met de
RewriteEngine code staat in de root, het .htaccess bestand met de de
wachtwoordbeveiliging staat in een onderliggende directory. In dat
..htaccess bestand staat uiteraard jouw bovenstaande code, om op die manier
wachtwoordbeveiliging te verkrijgen. Jouw code in het .htaccess bestand in
de root zetten lijkt me zinloos, aangezien ik dan de volledige website
afscherm met een wachtwoord. Dus wat wil je precies dat ik probeer?

> Gewoon luidop aan 't denken...

En dat wordt geapprecieerd. ,-)

Met vriendelijke groet,
Carl Janssen

Carl Janssen wrote:

> ErrorDocument 401
> http://www.mijndomein.be/error/error.php?code=401 en dit bestand
> bestaat wel degelijk.

En toch zit daar je fout/probleem.

# <http://httpd.apache.org/docs-2.0/en/...#errordocument>
#
# ...if you use a remote URL in an ErrorDocument 401, the client will
# not know to prompt the user for a password since it will not receive
# the 401 status code. Therefore, if you use an ErrorDocument 401
# directive then it must refer to a local document...

Op te lossen door een lokale verwijzing te gebruiken, dus iets zoals
dit: ErrorDocument 401 /full/path/to/error.php?code=401

--
Jeffrey Drooghenbroodt
http://www.pebbels.be/

Rookartikelen kunnen gevaarlijke suggestieve boodschappen bevatten.

"Jeffrey Drooghenbroodt" <jeffrey.drooghenbroodt@g.invalid> schreef in
bericht newsns953B6799F12B1TR0LL4D81E@g.invalid...
>
> En toch zit daar je fout/probleem.
>
> # <http://httpd.apache.org/docs-2.0/en/...#errordocument>
> #
> # ...if you use a remote URL in an ErrorDocument 401, the client will
> # not know to prompt the user for a password since it will not receive
> # the 401 status code. Therefore, if you use an ErrorDocument 401
> # directive then it must refer to a local document...
>
> Op te lossen door een lokale verwijzing te gebruiken, dus iets zoals
> dit: ErrorDocument 401 /full/path/to/error.php?code=401

Je hebt gelijk. Alleen blijkt het niet het full path te moeten zijn. De
/home/mijnaccount/public_html/mijnsubdomein/ moest er hier bij mij vanaf
vooraleer het werkte.

Fijn, het probleem van de die 401.shtml is dus opgelost. Hij gaat nu naar
het door mij gedefinieerde 401 error document. Bedankt voor de tip!

Helaas is hiermee het 'hoofdprobleem' nog niet opgelost, maar dat was
waarschijnlijk ook niet je bedoeling? ;-)

Enfin, nog steeds geen aanmeldingsvenster dus. :-(

Carl Janssen wrote:

> Je hebt gelijk. Alleen blijkt het niet het full path te moeten
> zijn. De /home/mijnaccount/public_html/mijnsubdomein/ moest er
> hier bij mij vanaf vooraleer het werkte.

En is /home/bla/bla/bla toevallig niet het volledige pad? Ja toch?

> Enfin, nog steeds geen aanmeldingsvenster dus. :-(

En toch zou dat moeten.

Van zodra je errordocument een lokale verwijzing heeft, moet de client
een 401 krijgen én een aanmeldingsvenster tevoorschijn toveren (zie m'n
4 lijntjes apache.org copy-paste).

Zoniet: heb je een URL van de boosdoener (desnoods per mail)?

--
Jeffrey Drooghenbroodt
http://www.pebbels.be/

Rookartikelen kunnen gevaarlijke suggestieve boodschappen bevatten.

"Robrecht Jacques" <Robrecht.Jacques@advalvas.be> schreef in bericht
news:41102bcc$0$410$ba620e4c@news.skynet.be...
>
> Probeer eens met een andere browser waarmee je de site nog niet bezocht
> hebt. Die zal dan ook nog geen passwd/user informatie hebben.

Ik had het gisteren al eens met Mozilla geprobeerd, maar met hetzelfde
resultaat. Daarnet ook nog eens Opera vanonder het stof uitgehaald en ook
daar hetzelfde scenario. Ik krijg steeds een 401 error (weliswaar de juiste
nu, zie daarvoor de reactie van Jeffrey Drooghenbroodt)

> Hmm. Waarom zou het met 404 werken en niet met 401??? Configureer je
> apache zelf of is het gehost?

Mijn sites zijn gehost. Maar goed, dit probleem is dus opgelost. Met dank
aan Jeffrey Drooghenbroodt. ;-)

> Hmm, dan heeft het wellicht niets met het cachen van user/passwd te maken.

Ik ben weliswaar geen kenner, maar ik denk het ook ja. ;-)

> Mijn eerste idee was een cache probleem, maar dat lijkt al redelijk
> ontkracht. Je kan het helemaal ontkrachten door bv AuthName een andere
> waarde te geven. Dan zou je echt wel een aanmeldingsvenster moeten
> krijgen want voor die AuthName/server/user heeft de browser helemaal nog
> geen passwd (maw niets in cache).

Bij deze is het ontkracht. Net even die AuthName gewijzigd, maar nog steeds
geen aanmeldingsvenster.

> Ik zal nog wat verder nadenken, misschien kom ik tot nog een andere
> mogelijk reden (of een manier om het apache-proces beter te
> volgen/debuggen).

OK. Ik denk met je mee, zij het wel op een holiday ritme bij deze
temperaturen. :-)

"Jeffrey Drooghenbroodt" <jeffrey.drooghenbroodt@g.invalid> schreef in
bericht newsns953BA12C11BABTR0LL4D81E@g.invalid...
>
> En is /home/bla/bla/bla toevallig niet het volledige pad? Ja toch?

Ja, dat is het volledig path. Ik zei net dat het bij mij *niet* het
volledige path moet zijn. Wanneer ik het volledig path gebruik wordt er
volgens mijn error log op zoek gegaan naar

/home/mijnaccount/public_html/mijnsubdomein/home/mijnaccount/public_html/err
or/error.php

en dat levert dan weer een 404 error op.

Op dit moment gebruik ik als path /error/error.php?code=401 en dat lijkt te
werken.

> > Enfin, nog steeds geen aanmeldingsvenster dus. :-(
>
> En toch zou dat moeten.

Secondje, ik geef je even m'n computer door. Vecht het met hem even uit.
:-)

> Van zodra je errordocument een lokale verwijzing heeft, moet de client
> een 401 krijgen én een aanmeldingsvenster tevoorschijn toveren (zie m'n
> 4 lijntjes apache.org copy-paste).
>
> Zoniet: heb je een URL van de boosdoener (desnoods per mail)?

You've got mail.

Organization: ...
Message-ID: <Xns953BA68EFA44CTR0LL4D81E@g.invalid>
User-Agent: Xnews/06.08.25
X-Face: $13SO7ha~H'u]FNboQt$yp)DD<&vQh6q$96x&',wz[EGteU|,yX+2uCl\=GlZu#zjl8QRsX#[)/BD:{jpm&nAb2$xwo<L~l]a.*SC*/%*ku*x-4w7wPR6jXy4x34%8SLgRf&A!DJX1?{?bOH=;\HZPu?pOQo)wtK k`rL",#aV"ZQ]'"P\=0hT+Jxhhmh>:j;;-(qn,+<kY{?-6lFG_;Sd\xE,K`
X-Mailer: Microsoft Outlook Express 3.01.1604.1281
Reply-To: jeffrey.drooghenbroodt@gmail.com
Lines: 22
Date: Wed, 04 Aug 2004 14:22:24 GMT
NNTP-Posting-Host: 213.118.116.215
X-Complaints-To: abuse@telenet.be
X-Trace: phobos.telenet-ops.be 1091629344 213.118.116.215 (Wed, 04 Aug 2004 16:22:24 MEST)
NNTP-Posting-Date: Wed, 04 Aug 2004 16:22:24 MEST
Xref: nl-news.euro.net be.comp.internet.design:35114 nl.internet.www.server-side:35959

Carl Janssen wrote:

> Op dit moment gebruik ik als path /error/error.php?code=401 en dat
> lijkt te werken.

Pfff, vanwaar haalde ik die full path eigenlijk? Gelukkig heb je dat
netjes opgelost zoals het hoort.

>> > Enfin, nog steeds geen aanmeldingsvenster dus. :-(
>>
>> En toch zou dat moeten.
>
> Secondje, ik geef je even m'n computer door. Vecht het met hem
> even uit.

Graag.

--
Jeffrey Drooghenbroodt
http://www.pebbels.be/

Rookartikelen kunnen gevaarlijke suggestieve boodschappen bevatten.