Cookie problemen
blijkbaar niet aangeroepen wordt.
Zet ik het op andere plek dan werkt het wel.
Weet ook niet wat ik met 'define' moet.
Er zijn ook telkens voorwaarden om de functie aan te roepen.
Iemand die me op weg kan helpen?
//Cookie names in Inifile
//in het procesbestand
//functie aanroep
Code (php)
1
2
2
if(isset($_COOKIE[$this->cookie_pass]))
{ $this->set_cookie($usernameA, $password, '+'); }
{ $this->set_cookie($usernameA, $password, '+'); }
//de functie
Code (php)
1
2
3
4
5
2
3
4
5
function set_cookie($username, $password, $set) {
{
setcookie($this->cookie_user, $usernameA, $cookie_expire, '/');
setcookie($this->cookie_pass, $passwordA, $cookie_expire, '/');
}
{
setcookie($this->cookie_user, $usernameA, $cookie_expire, '/');
setcookie($this->cookie_pass, $passwordA, $cookie_expire, '/');
}
Gewijzigd op 01/09/2017 16:53:04 door Hans De Ridder
Ik wil niet vervelend zijn, maar wat is jouw reden om een gebruikersnaam en een password in een cookie op te slaan? Persoonsgegevens horen daar niet in. Hoogstens een kenmerk dat je ingelogd bent, zoals een controle-hash.
Is proefje. Want gebruik een session voor het inloggen en wijzigingen.
Maar ik wil een cookie hebben. Die verandert telkens in de database (alternatief) en als cookie value.
En die wil ik eventueel gebruiken om op de openbare pagina's zonder sessie toch een lid te herkennen.
Is overigens alleen nodig om via mail te reageren.
Ik noem het weliswaar gebruikersnaam en password.
Maar ik gebruik andere gegevens...
Dit stuk zat al ingebouwd in voorbeeld.
Maar er wordt nergens een eerste cookie aangemaakt.
Ik zou zeggen, maak die cookie bij de eerste keer inloggen.
Vandaar dat ik vroeg naar dat 'define'.
Kan er niks over vinden...
$usernameA en $passwordA. Maar die komen nergens vandaan. Wel bestaan de variabelen $username, $password.
En een define is overigens hetzelfde als een variabele. Je kan er data in opslaan, echter kan deze tussentijds NIET worden aangepast, wat met een normale variabele wel kan. Het wordt ook een constante genoemd die je met define aanmaakt.
Logisch ook, kijk maar eens naar de code die je geplaatst hebt. Je zegt letterlijk "als cookie bestaat, stel cookie in". Dat zul je dus even anders moeten doen. Wat is hier feitelijk het voordeel van een cookie tov gebruik van sessies?
Een waarde gebruik ik als gehasht lidnr (uniek). De andere wil ik telkens varieren.
Zodat beide waardes in cookies moeten overeenkomen met de opgeslagen waardes.
Hans De Ridder op 01/09/2017 17:34:38:
$usernameA en $passwordA komen van gehashte waardes.
Ik zie die niet in de functie staan, en als ze van buitenaf komen, dan moeten ze meegenomen worden als argument, of als global (liever niet op die manier).
Inloggen, wijzigingen, aanvullingen, etc. gebeurt via session.
Het openbare gedeelte is voor iedereen toegankelijk.
Maar er is een optie om als lid te reageren op bepaalde vragen.
Dat hoeft dus niet, het kan.
Daarom wil ik daar geen session gebruiken.
Toevoeging op 01/09/2017 17:46:52:
Arien, omdat ik met IPTC werk voor de opslag, kan ik op elk gewenst moment alle of enkele gegevens
gebruiken. Net als bij database.
Als ik via een unieke waarde achterhaal welke foto ik moet hebben,
Dan kan ik elke waarde gebruiken en veranderen die in de foto staan.
Dus ook de referenties naar de cookies.
Werkt perfect....
Wat de reden ook is, je pakt het verkeerd aan om een gebruikersnaam en wachtwoord in je cookie te stoppen..
Dat hele gedoe met cookies is alleen bedoeld om bij een vinkje
automatisch 30 dagen ingelogd te blijven.
Dat haal ik er toch al uit..
Maar is wel de reden waarschijnlijk dat er niet wordt geset als checkbox niet op checked staat.
Dat wordt dus slopen....
Nog wel een vraag hierover..
Ik merk als de browser vraagt om inloggegevens te bewaren (na submit), er bij wachtwoordenlijst gewoon de pagina, gebruikersnaam en wachtwoord te lezen zijn...
Omdat leden dan meestal ja zullen zeggen, is dat ook te beveiligen of te hashen?
Of niet nodig?
Gewijzigd op 01/09/2017 19:19:44 door Hans De Ridder
Dat is al beveiligd vanuit de browser zelf. Je kunt het natuurlijk gewoon uitschakelen door autocomplete="off" mee te nemen in je form.
En tevens opgeslagen in de database (IPTC).
Waar ik het verstandig vind om cookie value te wijzigen
verandert het ook in de database.
1 value is een vaste unieke waarde.
De andere wijzigt voortdurend.
Ik kan dus die twee cookies vergelijken met de waardes in de database.
In principe zou 1 cookie voldoende zijn natuurlijk.
De lidmaatschaps hash wordt elders in script gegenereerd.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
$chars = "abcdefghijkmnopqrstuvwxyz023456789";
srand((double)microtime()*1000000);
$i = 0;
$pass = '' ;
while ($i <= 7) {
$num = rand() % 33;
$tmp = substr($chars, $num, 1);
$pass = $pass . $tmp;
$i++;
}
$codeB = sha1($pass);
$cookie_nameB = "code";
$cookie_code = $codeB;
setcookie($cookie_nameB, $cookie_code, time() + (86400 * 30* 30), "/"); // 2592000 = 30 day
$cookie_nameA = "user";
$cookie_value = $lid_hash;
setcookie($cookie_nameA, $cookie_value, time() + (86400 * 30 * 30), "/"); // 2592000 = 30 day
srand((double)microtime()*1000000);
$i = 0;
$pass = '' ;
while ($i <= 7) {
$num = rand() % 33;
$tmp = substr($chars, $num, 1);
$pass = $pass . $tmp;
$i++;
}
$codeB = sha1($pass);
$cookie_nameB = "code";
$cookie_code = $codeB;
setcookie($cookie_nameB, $cookie_code, time() + (86400 * 30* 30), "/"); // 2592000 = 30 day
$cookie_nameA = "user";
$cookie_value = $lid_hash;
setcookie($cookie_nameA, $cookie_value, time() + (86400 * 30 * 30), "/"); // 2592000 = 30 day
Beiden werden gebruikt om in de database te controleren of er een match was, en indien dat geval is er ingelogd.
Dat wist ik van een vorige topic.
Ik ga dit nu toepassen voor de herkenning op de openbare pagina's.
Ik zit eraan te denken om de session voor het inloggen ook zo te gebruiken.
1 session waarde gehasht vast.
En 1 variabel..
Of is dat overtrokken en te veel?
De cookie die de session zelf aanmaakt, is die ook oproepbaar en uniek?
En kom ook opmerkingen tegen om de submits te vertragen met 2 seconden.
Omdat programma's die scannen op inputs daar een hekel aan hebben.
Is dat ook zo?
Submits kun je vertragen, zeker in het geval van mislukte inlogpogingen. Je moet er dan wel rekening mee houden dat je een tijdelijke blokkade op het IP moet doen, omdat het anders geen zin heeft. Immers; je kunt scripts gewoon meerdere malen naast elkaar oproepen.
Ik werk meestal vanuit een bestaand script.
Waar ik dan de foute zaken uithaal en veranderingen in aanbreng.
Dat leert voor mij het beste.
Dat oorspronkelijke registratie en inlogscript barste van 'not done' zaken.
Zo werden alle gegevens van een lid uit de database gehaald.
En alle gegevens meegegeven in session waardes.
De cookies waren uitsluitend bedoeld om 30 dagen ingelogd te blijven.
En bevatten de username en het wachtwoord.
Dat is er al allemaal uit gesloopt.
De IP wordt gecontroleerd. En opgeslagen.
Of een lid daar gebruik van wil maken is optioneel.
Bij meer IP's (thuis, werk, gsm) is het mogelijk om deze extra op te slaan.
De forminputs waren minimaal beveiligd.
Dat is nu allemaal veranderd.
Ik gebruik nu (experimenteel) IPTC ipv database.
De inputs zijn beveiligd en worden gecontroleerd.
De persoonlijke gegevens zitten buiten de root.
De gegevens die belangrijk zijn worden gehasht.
Referenties op cookies en sesion worden vergeleken..
Emails worden automatisch verstuurd bij vergeten gegevens met gehashte code.
Ben aardig op weg dacht ik, haha.