[PHP] "onder water" authen

[Verwijderd]

ik heb een php bestand gemaakt, www.domein.nl/beschermt.php waar een overzicht op wordt getoond. dit bestand heb ik beschermt dmv

PHP:

header("WWW-Authenticate: Basic realm=blaat");

werkt allemaal prima, je krijgt van de browser een promt naar je user-id en je pass. nadat je deze gegeven heb, krijg mag je beschermt.php zien.

maar nu wil/moet ik die stap automatiseren. een ander php bestand op een andere server moet de inlog "voor me doen". maar op zo'n manier dat de gebruiker de logingegevens niet ziet (oftwel "onder water").

een oplossing die ik bedacht: een php pagina (www.anderdomein.nl/doe_de_login_voor_me.php) bouwen die een redirect doet naar beschermt.php met de user-id en pass in de url, als volgt:

PHP:

$user-id = "pietje";
$pass = "fikkie";
//url maken aan de hand van de logingegevens
$url = "http://" . $user-id . ":" . $pass . "@www.domein.nl/beschermt.php?var=waarde";
//redirect
header("Location: $url");

dit werkt je wordt automatisch ingelogt en je kan het overzicht op beschermt.php zien, maar het nadeel is dat de inlog gegevens gewoon in de adres bar staan van de browser en dat mag niet, want de logingegevens mogen niet aan de gebruiker worden getoont. Het moet dus anders opgelost worden, maar hoe?

ik zit te denken aan een oplossing waarbij doe_de_login_voor_me.php een soort header meestuurt waar de login meteen in verwerkt is.
je kan immers ook een header als:

PHP:

header("Refresh: 5;url=$PHP_SELF")

meesturen.

ik heb een heleboel gelezen over headers op http://www.ietf.org/rfc/rfc2617.txt en daar las ik iets als

basic-credentials = base64-user-pass
base64-user-pass = <base64 [4] encoding of user-pass, except not limited to 76 char/line>
user-pass = userid ":" password
userid = *<TEXT excluding ":">
password = *TEXT

maar ik begrijp niet hoe ik dit vervolgens in php (bv in de header) moet meegeven, om geauth te worden. de header wordt namelijk naar de client gestuurd en niet andersom (naar de server om te authentificeren).

iemand een oplossing, of tip hoe ik hiermee verder kom?

[drm]

Als je URL fopen wrappers aan hebt staan, kan je ook de url openen, die je in het stukje code genereert, en vervolgens uitlezen, en door sturen naar de client (soort include dus). Sterker nog, je kunt dan ook gewoon de url includen....

hth

[Verwijderd]

Zo te zien werk je dus niet met een htacces.

Dan kan je natuurlijk van uit dat eerste form de user en zijn wachtwoord (eventueel nog ( base64 ) geencrypt) naar je authenticate script posten, en er daarop checken.

sim-pel

[SchizoDuckie]

een form posten?

edit:
ik ben niet de enige met die gedachte

CURL helpt je waarschijnlijk dit te doen.

[ Voor 76% gewijzigd door SchizoDuckie op 25-11-2002 15:35 ]

[Verwijderd]

drm schreef op 25 November 2002 @ 15:32:
Als je URL fopen wrappers aan hebt staan, kan je ook de url openen, die je in het stukje code genereert, en vervolgens uitlezen, en door sturen naar de client (soort include dus). Sterker nog, je kunt dan ook gewoon de url includen....

hth

Best leuk, maar je zit nog steeds (gelukkig) met die authenticate.

[Verwijderd]

Papa Eend schreef op 25 november 2002 @ 15:35:
een form posten?

edit:
ik ben niet de enige met die gedachte

CURL helpt je waarschijnlijk dit te doen.

Ach het is heel simpel.

Je kijkt of je de post variabelen binnen krijgt.
Zo ja: Check ze.

Als ze niet goed zijn of je krijgt die post vars niet dan laat je gewoon het authenticate scherm zien, anders mogen ze door.

[sjon.]

Waarom wil je nu een afgeschermde pagina aan iedereen laten zien ?? Wat is dan nog 't nut van dat afschermen ??? Want volgens mij probeer je nu een oplossing te vinden voor iets wat geen probleem is... Wat probeer je precies te bereiken ??

[Verwijderd]

includen dmv

PHP:

include('http://user:[e-mail]/beschermt.php?var=waarde')

werkt (verbazend genoeg), maarrr omdat er gevaarlijke tekens in beschermt.php voor komen (<? en ?> bv) struikelt de parser.

enne dat form posten begrijp ik volgens mij niet helemaal goed. mijn users krijgen helemaal geen form om de login gegevens te posten. bovendien zou ik dat wel doen, dan moet zit ik nog steeds met het probleem hoe kom ik dan zonder de login gegevens voor beschermt.php bloot te geven op bescherm.php ?

[ Voor 3% gewijzigd door Verwijderd op 25-11-2002 16:05 ]

[Verwijderd]

sjon. schreef op 25 november 2002 @ 15:42:
Wat probeer je precies te bereiken ??

ok, wat meer achtergrond info.

beschermt.php is een xml bestand met een stukje (of dump) van een database voor een bepaalde user met een bepaalde parameter. vandaar beschermt.php?var=waarde
elke user heeft een aparte login, zodat elke user een eigen dump krijgt.

deze users kunnen deze dumps op hun eigen sites aanbieden (bijv www.anderdomein.nl/dump_ophalen.php). oftewel de content van die users komt dus live van www.domein.nl/beschermt.php die achter een login staat. het is belangerijk dat de login gegevens naar de dump niet zichtbaar zijn.

[martinvw]

Verwijderd schreef op 25 november 2002 @ 15:47:
includen dmv

PHP:

include['http://user:[e-mail]/beschermt.php?var=waarde']

werkt (verbazend genoeg), maarrr omdat er gevaarlijke tekens in beschermt.php voor komen (<? en ?> bv) struikelt de parser.

enne dat form posten begrijp ik volgens mij niet helemaal goed. mijn users krijgen helemaal geen form om de login gegevens te posten. bovendien zou ik dat wel doen, dan moet zit ik nog steeds met het probleem hoe kom ik dan zonder de login gegevens voor beschermt.php bloot te geven op bescherm.php ?

lijkt me sterk dat hij het vierkante haakjes goed vind:

PHP:

include('http://user:[e-mail]/beschermt.php?var=waarde')

[Verwijderd]

doh, spelfoutje (verbeterd inmiddels)

[drm]

NextGeneration:
Best leuk, maar je zit nog steeds (gelukkig) met die authenticate.

Volgens mij snap je mij niet goed. Gelukkig snapt 10US mij wel goed

[Verwijderd]

uhm drm, sorry ik begrijp het niet...

Verwijderd schreef op 25 november 2002 @ 15:47:
enne dat form posten begrijp ik volgens mij niet helemaal goed. mijn users krijgen helemaal geen form om de login gegevens te posten. bovendien zou ik dat wel doen, dan moet zit ik nog steeds met het probleem hoe kom ik dan zonder de login gegevens voor beschermt.php bloot te geven op bescherm.php ?

[Verwijderd]

drm schreef op 25 november 2002 @ 16:12:

[...]

Volgens mij snap je mij niet goed. Gelukkig snapt 10US mij wel goed

Arg , je hebt gelijk , denk vautje.

[Olaf van der Spek]

Verwijderd schreef op 25 november 2002 @ 15:53:
ok, wat meer achtergrond info.

beschermt.php is een xml bestand met een stukje (of dump) van een database voor een bepaalde user met een bepaalde parameter. vandaar beschermt.php?var=waarde
elke user heeft een aparte login, zodat elke user een eigen dump krijgt.

deze users kunnen deze dumps op hun eigen sites aanbieden (bijv www.anderdomein.nl/dump_ophalen.php). oftewel de content van die users komt dus live van www.domein.nl/beschermt.php die achter een login staat. het is belangerijk dat de login gegevens naar de dump niet zichtbaar zijn.

Dus alleen bepaalde remote sites mogen die beschermde PHP benaderen?
Moet die remote site de PHP benaderen of moet de user die de remote site benadert dat zelf doen?

[jochemd]

Verwijderd schreef op 25 november 2002 @ 15:26:

ik heb een heleboel gelezen over headers op http://www.ietf.org/rfc/rfc2617.txt en daar las ik iets als
[...]

maar ik begrijp niet hoe ik dit vervolgens in php (bv in de header) moet meegeven, om geauth te worden. de header wordt namelijk naar de client gestuurd en niet andersom (naar de server om te authentificeren).

Moet je nog even iets verder lezen, deel 2 van die RFC (Digest i.p.v. Basic Authentication) legt uit hoe je dit voor meerdere servers implementeert.

[Verwijderd]

Alleen ondersteund PHP volgens mij alleen Basic...

[Verwijderd]

OlafvdSpek schreef op 25 November 2002 @ 21:57:
[...]

Dus alleen bepaalde remote sites mogen die beschermde PHP benaderen?
Moet die remote site de PHP benaderen of moet de user die de remote site benadert dat zelf doen?

een bepaalde (remote php) site benadert die xml dump (beschermt.php) om zelf live pagina's te maken voor zijn eigen bezoekers. die bezoekers mogen zelf niet zien waar die info vandaan komt of wat de login ervan is.

je kan mijn probleem vergelijken met de volgende (voorbeeld) case:
een site van bijvoorbeeld de volleybalbond houdt van elke volleybal club de uitslagen en spelers bij. deze informatie is niet openbaar, alleen club "de volley" mag zijn eigen gegevens zien. daarom biedt de volleybalbond voor elke club een eigen xml dump aan met gegevens over die club, maar achter een authoristatie dmv WWW-auth (zie eerste post), laten we dit bestand "beschermt.php" noemen.
nou heeft de club "de volley" een eigen site. als een bezoeker van de "volley"-site bijvoorbeeld de wedstrijd uitslagen van "de volley" wil zien, gaat hij naar "haal_uitslagen_op.php". deze pagina haalt de xml dump (beschermt.php) op van de volleybal bond site (dus een remote site) en autoriseert zich dus (anders krijg je die dump niet). maar de bezoeker van "de volley" site mag niets zien van een login op beschermt.php want anders zou die zelf die dump kunnen gaan ophalen (en heeft ie toegang tot de volleybalbond dumps), wat niet de bedoeling is.

jochemd schreef op 25 November 2002 @ 22:14:
[...]

Moet je nog even iets verder lezen, deel 2 van die RFC (Digest i.p.v. Basic Authentication) legt uit hoe je dit voor meerdere servers implementeert.

php ondersteund alleen basic auth...helaas. ik ben dus genoodzaakt dit op te lossen met basic authentication.

[jochemd]

Verwijderd schreef op 26 November 2002 @ 10:18:

php ondersteund alleen basic auth...helaas. ik ben dus genoodzaakt dit op te lossen met basic authentication.

Nou en? Dan schrijf je het toch zelf? Je hoeft alleen maar en HTTP 401 te kunnen versturen en een Authorization header te kunnen lezen. ColdFusion ondersteunt het ook niet en daar heb ik het ook zelf voor geschreven.

[Verwijderd]

jochemd schreef op 26 november 2002 @ 13:17:
[...]

Nou en? Dan schrijf je het toch zelf? Je hoeft alleen maar en HTTP 401 te kunnen versturen en een Authorization header te kunnen lezen. ColdFusion ondersteunt het ook niet en daar heb ik het ook zelf voor geschreven.

dat lukt ook allemaal. maarrr ik wil die user-id en pass "onder water" (niet zichtbaar voor de gebruikers van die pagina) doorgeven (met php of in de header zelf) maar ik weet niet hoe dat moet.... en dat is dus de vraag.

[martinvw]

je kan tochzelf een socket openen, dan een post of een get simuleren en dan gaat het volledig buiten user om. Want alles wat er in jou script gebeurt ziet de user niet, die ziet slechts de output.

[ Voor 34% gewijzigd door martinvw op 26-11-2002 16:39 ]

[Olaf van der Spek]

Verwijderd schreef op 26 November 2002 @ 16:07:
dat lukt ook allemaal. maarrr ik wil die user-id en pass "onder water" (niet zichtbaar voor de gebruikers van die pagina) doorgeven (met php of in de header zelf) maar ik weet niet hoe dat moet.... en dat is dus de vraag.

Dan moet je het anders aanpakken. Op domein 2 encrypt je met key K het IP(A) van de user (met BlowFish bijvoorbeeld). De ciphertext stuur je dan naar de user en de user stuurt het naar domein 1 (via ?a=########) bijvoorbeeld.
Bij domein 1 encrypt je met key K ook het IP(A) van de user en je vergelijkt dit met wat je binnenkreeg. Als het klopt laat je de user toe, anders niet.

[martinvw]

is dat niet erug ingewikkeld oplossing voor zijn probleem of snap ik het niet

[DiedX]

PHP:

    $ch = curl_init();                                              // Zet cURL maar aan
    $url = "http://www.clanbase.com/auth.php?page=news";                // Bij deze pagina gaan we checken.

    $up = "$cbid:$password";                                            // Zet de cbid en wachtwoord in een extra var
    curl_setopt($ch,CURLOPT_URL,$url);                                  // Welke website?
    curl_setopt($ch,CURLOPT_USERPWD,$up);                               // Welke username / password combinatie?
    curl_setopt($ch,CURLOPT_HEADER,1);                                  // We willen extended headers!
    curl_setopt($ch,CURLOPT_NOBODY,0);                                  // Dus geen body
    curl_setopt($ch,CURLOPT_RETURNTRANSFER,1);                          // STFU!!!
    $result = curl_exec($ch);                                           // Voer het maar uit
    
    $string = "302";                                                // Onze referentiestring (302 = Authenticated!)
        
    if(strstr($result,$string))                                     // Als de string voorkomt
        {
            ZetSessie($UserID);
        } 
        
    }
}

[ Voor 4% gewijzigd door DiedX op 26-11-2002 23:02 . Reden: Code -> PHP. THNX! ]

[Olaf van der Spek]

M4rt1nvW schreef op 26 November 2002 @ 16:50:
is dat niet erug ingewikkeld oplossing voor zijn probleem of snap ik het niet

Het klinkt ingewikkelder dan het is. Hij heeft mijn eerste vraag trouwens niet beantwoord, maar ik neem aan dat er tussen de twee servers geen connectie gewenst is.

Wel dus, zie ik ook net pas. Dan is mijn oplossing niet nodig, maar wel mogelijk.

[ Voor 17% gewijzigd door Olaf van der Spek op 26-11-2002 17:00 ]

[DiedX]

DiedX schreef op 26 november 2002 @ 16:52:

code:

}

Sorry voor mijn (zeer)brakke PHP overigens Wellicht kan je hier wat mee?

[martinvw]

ohw, okeej maar hier uit:

Verwijderd schreef op 26 november 2002 @ 16:07:
[...]

dat lukt ook allemaal. maarrr ik wil die user-id en pass "onder water" (niet zichtbaar voor de gebruikers van die pagina) doorgeven (met php of in de header zelf) maar ik weet niet hoe dat moet.... en dat is dus de vraag.

Maak ik dat niet op, maar als OlafvdSpek gelijk heeft dan is zijn oplossing wel iets beter.

DiedX schreef op 26 november 2002 @ 16:55:
[...]
Sorry voor mijn (zeer)brakke PHP overigens Wellicht kan je hier wat mee?

Daar hebben we een edit en [php ] -tags voor dus zet je php code de volgdende keer tussen

PHP:

dan highlight hij het ook nog eens.
nofi

[ Voor 28% gewijzigd door martinvw op 26-11-2002 17:02 ]

[Olaf van der Spek]

Verwijderd schreef op 26 November 2002 @ 10:18:
een bepaalde (remote php) site benadert die xml dump (beschermt.php) om zelf live pagina's te maken voor zijn eigen bezoekers. die bezoekers mogen zelf niet zien waar die info vandaan komt of wat de login ervan is.

Waarom moet dat dan met HTTP authenticatie?
Waarom niet gewoon http://...?n=Olaf&p=Spek laten uitvoeren door domein 2 en dan het resultaat 'parsen' en doorsturen naar de user?

[jochemd]

Verwijderd schreef op 26 November 2002 @ 16:07:
[...]

dat lukt ook allemaal. maarrr ik wil die user-id en pass "onder water" (niet zichtbaar voor de gebruikers van die pagina) doorgeven (met php of in de header zelf) maar ik weet niet hoe dat moet.... en dat is dus de vraag.

Het gebeurt in een header en is dus niet zichtbaar voor de gebruiker. Ik heb in je specificaties nog niets gelezen dat niet werkt met Digest Authentication.

[martinvw]

header ontvang je gewoon en kan je met een packetsniffer opvangen.

Directe communicatie tussen server of codering zijn de enige opties. Althans dat denk ik

[Verwijderd]

M4rt1nvW schreef op 26 november 2002 @ 17:29:
header ontvang je gewoon en kan je met een packetsniffer opvangen.

Directe communicatie tussen server of codering zijn de enige opties. Althans dat denk ik

Kan je mij uit leggen waarom 'directe communicatie' niet te sniffen is?

[Olaf van der Spek]

Dat is niet te sniffen door de user, omdat het niet naar de user wordt verzonden.

[BobDay]

waarom laad je beschermt.php niet gewoon checken of de aanvraag van het juiste domein komt

[Olaf van der Spek]

Omdat dat absoluut niet veilig is.

[BobDay]

is dat te faken dan?

[Verwijderd]

wow, wat een reacties. ik zal me best doen om ze allemaal te behandelen.

M4rt1nvW schreef op 26 November 2002 @ 16:28:
je kan tochzelf een socket openen, dan een post of een get simuleren en dan gaat het volledig buiten user om. Want alles wat er in jou script gebeurt ziet de user niet, die ziet slechts de output.

klopt alles gebeurd buiten de user om, maar ik heb nog niet echt kaas gegeten van sockets. ik zal me er eens in verdiepen...tanx

DiedX, tanx voor je code (je kan idd beter [ p h p ] tags gebruiken in je post ) ik zal het eens proberen. ik was in me zoektocht al eens wat tegengekomen over cURL. das niet standaard geinstalled volgens mij, dus even kijken of ik de systeembeheerder dat kan installen

OlafvdSpek schreef op 26 November 2002 @ 16:59:
[...]
Waarom moet dat dan met HTTP authenticatie?
Waarom niet gewoon http://...?n=Olaf&p=Spek laten uitvoeren door domein 2 en dan het resultaat 'parsen' en doorsturen naar de user?

ik heb gekozen voor http authenticatie omdat ik dit gebruiksvriendelijker vond...stel dat de beheerder van "de volley" de kale xml dump wil bekijken dan surft ie gewoon naar "beschermt.php" --> krijgt een prompt, vult ze gegevens in en klaar ingelogt. maar ik kan idd net zo goed bij niet ge-auth een formuliertje maken en ervoor zorgen dat beschermt.php zowel $get['user-id'] / ['pass'] als $_post kan ontvangen. ben je idd van een hoop gedonder af...

hele nuchtere tip! tanx... soms zit je er zo diep in, dat je de makkelijkere oplossingen gewoon niet meer ziet. ik ga d'r es over nadenken of ik die HTTP authenticatie niet gewoon laat varen, het kan immers ook gewoon met php...

jochemd schreef op 26 November 2002 @ 17:10:
[...]
Het gebeurt in een header en is dus niet zichtbaar voor de gebruiker. Ik heb in je specificaties nog niets gelezen dat niet werkt met Digest Authentication.

het vragen naar de user-id en wachtwoord ($PHP_AUTH_USER en $PHP_AUTH_PW) en het controleren daarvan gebeurd idd in de header. maar waar het om gaat is dat die het op of ingeven van de user-id en wachtwoord, automatisch gebeuren, dus niet door de gebruiker dmv een prompt (want die mag die gegevens niet weten/zien). dat bedoel ik met "onder water" authen.

jochemd, bedoel jij dus dat je een header zou kunnen maken zoiets als:

PHP:

header('WWW-Authenticate: Basic realm="blaat" base64(pietje:fikkie)');
header('HTTP/1.0 401 Unauthorized');
echo "Geen toegang.";

waarmee je dus de inloggegevens al meestuurt? want ik vind het header verhaal nogal vaag.

[DiedX]

Verwijderd schreef op 26 November 2002 @ 22:14:
DiedX, tanx voor je code (je kan idd beter [ p h p ] tags gebruiken in je post ) ik zal het eens proberen. ik was in me zoektocht al eens wat tegengekomen over cURL. das niet standaard geinstalled volgens mij, dus even kijken of ik de systeembeheerder dat kan installen

No problem. Ik heb 'm ondertussen aangepast, bedankt ook M4rt1nvW voor de tip!
(Ik programmeer zoveel PHP (NOT!) dat dit mijn eerste code-post wordt).

Ik ben wel heel erg benieuwd of je dit lukt. Naar mijn idee, en met mijn code (goed voor 2 dagen werk uitzoeken) denk ik dat je er uit moet kunnen komen!

succes!

[Olaf van der Spek]

BobDay schreef op 26 november 2002 @ 21:16:
is dat te faken dan?

Je bedoelt de referer? Ja.

[Olaf van der Spek]

Verwijderd schreef op 26 november 2002 @ 22:14:
ik heb gekozen voor http authenticatie omdat ik dit gebruiksvriendelijker vond...stel dat de beheerder van "de volley" de kale xml dump wil bekijken dan surft ie gewoon naar "beschermt.php" --> krijgt een prompt, vult ze gegevens in en klaar ingelogt. maar ik kan idd net zo goed bij niet ge-auth een formuliertje maken en ervoor zorgen dat beschermt.php zowel $get['user-id'] / ['pass'] als $_post kan ontvangen. ben je idd van een hoop gedonder af...

hele nuchtere tip! tanx... soms zit je er zo diep in, dat je de makkelijkere oplossingen gewoon niet meer ziet. ik ga d'r es over nadenken of ik die HTTP authenticatie niet gewoon laat varen, het kan immers ook gewoon met php...

Je kunt natuurlijk ook HTTP authenticatie gebruiken, maar dat is iets lastiger te implementeren. Die headers met u/p kun je vast wel meesturen met je request.

[Verwijderd]

OlafvdSpek schreef op 27 november 2002 @ 16:29:
[...]

Je kunt natuurlijk ook HTTP authenticatie gebruiken, maar dat is iets lastiger te implementeren. Die headers met u/p kun je vast wel meesturen met je request.

joh, 3 keer raden waar dit topic overgaat.... HTTP authenticatie, maar dan de user en pass meesturen met de header...
en nee het is helemaal niet lastig te implementeren (zie eerste post, daar wordt uitgelegd hoe dat moet), maar het is vervolgens wel moeilijk om ook de user en pass mee te sturen in die header.

[Olaf van der Spek]

Verwijderd schreef op 28 november 2002 @ 10:33:
joh, 3 keer raden waar dit topic overgaat.... HTTP authenticatie, maar dan de user en pass meesturen met de header...

Als je het in de 'URL' zet is het geen HTTP authenticatie meer IMO.

en nee het is helemaal niet lastig te implementeren (zie eerste post, daar wordt uitgelegd hoe dat moet), maar het is vervolgens wel moeilijk om ook de user en pass mee te sturen in die header.

Wat is er moeilijk aan?
Weet je niet welke headers je moet meesturen?
Weet je niet hoe je headers mee moet sturen naar domein 2?

[drm]

[nohtml]

OlafvdSpek:
Als je het in de 'URL' zet is het geen HTTP authenticatie meer IMO.

Toch gek dat er dan "http://" in die url staat...

[Olaf van der Spek]

drm schreef op 28 November 2002 @ 17:04:
Toch gek dat er dan "http://" in die url staat...

De authenticatie heeft niks meer met het HTTP protocol te maken. Dat er http in de URL voorkomt maakt niet uit.

[drm]

Sorry, je maakt me aan het lachen. Als er ftp:// in had gestaan was het ook geen file transfer protocol geweest? Waar is die protocol-aanduiding in de url dan voor, denk je?

[Olaf van der Spek]

Jawel, ik zeg ook niet dat het geen HTTP protocol meer is, maar als je bijvoorbeeld inlogt zoals op GoT dan is dat geen HTTP authenticatie IMO.

[drm]

Je kunt op GoT ook niet met http://sjaak:[e-mail]/ inloggen

[Olaf van der Spek]

drm schreef op 28 November 2002 @ 18:05:
Je kunt op GoT ook niet met http://sjaak:[e-mail]/ inloggen

Nee, maar mijn reactie was op de andere methode: ?u=sjaak&p=wachtwoord.

[drm]

Hm, dat haal ik er niet uit, maar volgens mij zitten we dan met z'n drieen gewoon strak langs elkaar te lullen

[Verwijderd]

goed, lui ik ben er uit. om even het langselkaar lullen te beëindigen, hier de oplossing.

ik moest dus een bestand benaderen (beschermt.php), met een andere bestand (haal_op.php). beschermt.php is beschermt dmv http (basic) authenticatie, deze werd door php vanuit de header aangeroepen. zie http://www.zend.com/manual/features.http-auth.php

als je handmatig (met je browser) naar beschermt.php zou surfen loop je tegen een prompt ("geef usernaam en wachtwoord") op (precies zoals je ook bij een .htacces beveiligde directory zou zien). na het geven van de login gegevens kon je beschermt.php zien. met basic http auth kan je ook de login gegevens in de url meegeven. zoals http://user:[e-mail]/path/beschermt.php?var=waarde

ik wilde alleen niet dat die logingegevens zo zichtbaar bleven. ik dacht dat ik beschermt.php kon aanroepen met bepaalde headers waarin de logingegevens al verwerkt stonden. dit is niet gelukt. logisch, want je kan niet een bestand oproepen en er zelf even een eigen header aan toe voegen... ik kan niets toevoegen aan beschermt.php want de gebruiker heeft geen toegang tot de source en kan het al helemaal niet wijzigen (is ook niet de bedoeling!)

de oplossing is door van haal_op.php een soort wrapper (zo noem ik het maar, ik bedoel ermee een soort omhulsel file voor beschermt.php) te maken. met de php functie readfile() (zie http://www.zend.com/manual/function.readfile.php) kan je een willekeurig (zowel remote als local) bestand aan de hand van een ingegeven url lezen.
in mijn geval wil ik dus www.domein.nl/beschermt.php lezen. door in readfile() naast die url ook de login gevegens (dmv user:pass@) te zetten heeft haal_op.php toegang en laat zonder problemen "beschermt.php" zien. beschermt.php tussen quotes, want inprincipe is het alleen een weergave van beschermt.php en niet het file zelf.

waarom heb ik nou www auth gebruikt en niet gewoon een simpel php login scrippie gemaakt, zodat ik ook dmv de url (www.domein.nl/beschermt.php?user=sjaak&pass=fikkie) ook zou kunnen inloggen (dmv $_get[]).
tsja, ik heb daar nou eenmaal niet voor gekozen
en bovendien, ook met die methode zou ik een wrapper moeten hebben gemaakt om de login gegevens te verbergen. dus het probleem (de login gegevens worden blootgegeven in de url) had hetzelfde geweest en de oplossing ook.

ik ben misschien niet duidelijk genoeg geweest, vandaar dat sommige mensen langselkaar heen gingen praten. maar ik hoop dat het probleem en de oplossing na (iniedergeval) deze post duidelijk is.

[Olaf van der Spek]

drm schreef op 28 november 2002 @ 18:23:
Hm, dat haal ik er niet uit,

Dat zou je uit
[rml]OlafvdSpek in "[ PHP] "onder water" authen"[/rml] kunnen halen.

maar volgens mij zitten we dan met z'n drieen gewoon strak langs elkaar te lullen

Dat idee heb ik ook ja.