Ik heb een vraag over passwords.
Stel je voor, ik maak nou een pagina aan, website.nl/pagina/
Als ik deze directory beveilig met een wachtwoord op de directory via hosting, Is dit veilig?
Kunnen mensen nog steeds op deze pagina komen zonder wachtwoord?
Ik heb geen idee wat clean_value precies doet. Het is een eigen gemaakte functie zie ik.

Het script kan je hier vinden:
http://clayweb.nl/downloads/multisess_0.83.rar

Het is wel behoorlijk verouderd, maar het geeft een inzicht om het te kunnen beveiligen. Hoewel ik zelf het liefst alles nu in PHP-sessies zou doen.
Hartelijk bedankt Aar!
Graag gedaan.
Nog even ter duidelijkheid: Gebruik op eigen risico, ontwikkeling is al tijden gestopt.
Naar iets als dit was ik echt opzoek, zeer simpel hoe je gegevens uit de database haalt.
Wist niet dat het zo makkelijk kon.

Bedankt hiervoor!

[size=xsmall]Toevoeging op 01/07/2015 16:21:11:[/size]

Kan ik ook nog een <a href toevoegen aan deze echo?
Geen idee hoe:S


echo "<br />uw website: " .$get_userdata['website'] ;


[size=xsmall]Toevoeging op 01/07/2015 16:21:45:[/size]

dit zal wel niet werken :
<a href=".$get_userdata['website']">.$get_userdata['website']</a>
Ik zou het zo doen:
<a href="<?php echo $get_userdata['website']; ?>"><?php echo $get_userdata['website']; ?></a>
Enkele kanttekeningen bij dit script:
- _real_escape_string() functies werken alleen goed als de character encoding goed ingesteld staat, wat niet gebeurt bij het maken van een verbinding met je database

- mysql_functies ... :(

- je tabeldefinities van je SQL-bestand hebben ook geen character sets gedefinieerd, dus tis maar net wat de default van je database is?

- zoals al zo vaak de revu is gepasseerd, in de volgende constructie:
<?php
if ($someCondition === false) {
    // check failed, redirect
    header('Location: some_url');
}
// SOME IMPORTANT CODE HERE
// ...
?>

Wordt "// SOME IMPORTANT CODE HERE" gewoon uitgevoerd, ook al evalueert $someCondition tot false. Zet na een header("Location: some_url"); altijd een exit. Strict genomen moet some_url ook eigenlijk een volledige URL zijn, en niet een relatieve. En (voor de puristen) het is dus niet location:some_url maar Location: some_url.

- de cookies die je instelt hebben geen pad (4e parameter). Deze zijn dus enkel geldig in de directory waar je deze instelt, ik weet niet of dat heel erg handig is

- als je zomaar klakkeloos $get_userdata['website'] afdrukt (ook bijvoorbeeld in een adminpaneel) ben je mogelijk vatbaar voor crossite scripting; als je op die manier zijn/haar cookies steelt ben je al binnen, want ik zie nergens een IP-controle; ESCAPE DUS ALTIJD OUTPUT; hierbij is het wederom belangrijk dat je de goede character encoding instelt (dus ook voor je -volledige en kloppende- HTML-document)
het escapen voorkomt ook dat dit mogelijk je site-design breekt, stel dat een of andere clown ergens "</div>" invult en je dit niet escaped... need I say more...

- ik zou geen if-statement verwachten die een formulier verwerkt in een bestand genaamd "functions.php" eigenlijk

Misschien ben ik aan het muggeziften, maar als je dit wilt gaan gebruikmaken voor de opslag van klantinformatie moet je hier wellicht nog even over nadenken. Je wilt waarschijnlijk niet dat in het ergste geval je klantinformatie op straat komt te liggen. Of dat iemand de boel op zijn kop zet door in te breken en... creatief met taalgebruik is... die je klanten vervolgens weer te zien krijgen

Als je dit soort dingen gaat bouwen/gebruiken moet je enigszins van de hoed en de rand weten, of een pakket gaan gebruiken die zijn sporen verdiend heeft.

Ik snap dat dit een oud script is enzo (binnenkort 10-jarig feestje als ik de SQL dump mag geloven :)), maar ja, ik zou persoonlijk iets nieuws schrijven.
True, het is inderdaad een oud script, en tegenwoordig zou ik het veel beter doen met PHP-sessies. Het ging mij om hem een idee te geven hoe je een inlogsysteem met cookies (redelijk) veilig kan maken. Voor productie raad ik dit ZEKER af, tenzij je de boel grondig doorlicht.

De bedoeling was dat ik nog een IP-check zou inbouwen in de logincheck(), die een gebruikte inlogsessie alleen op een bepaald IP zou toestaan.

Verder over character-encoding... Ook belangrijk, maar het ging hier om de veiligheid, dus dit stukje vind ik wel een beetje muggezifterij om een oud script.
Verder heb ik hem ook gewaarschuwd dat er het één en ander aan rammelt. Uiteraard zijn er nog andere actuele scripts en tutorials op internet als je goed zoekt.

Reageren