Ik ben bezig met een bestaand inlogscript.
Met een vinkje kun je aangeven of je 30 dagen automatisch ingelogd wilt blijven.
Alleen werkt dat met de gebruikersnaam en het wachtwoord in twee cookies opgeslagen.
Ik heb in de DB een tabel aangemaakt met 2 cookies.
De eerste gebaseerd op een gecodeerde tijd die is ingesteld bij het aanmaken van de registratie.
De tweede gebaseerd op het IP, maar dient uitsluitend om bij andere locatie het automatisch inloggen te blokkeren.

Er wordt een sessie aangemaakt met de gegevens uit tabel 1
De codering voor de cookie opslag zitten in tabel 2.
De link tussen tabel 1 en tabel 2 wordt gemaakt via het id.
Moet/kan dat met meerdere sessies tegelijk?
Ik heb eerlijk gezegd geen idee hoe ik dit omgebouwd krijgt!
Iemand die me verder kan helpen?
Waarom sla je het wachtwoord op in een cookie? Klinkt behoorlijk gevaarlijk!
Dat was zo in het bestaande script.
Ik weet dat het onveilig is.
Vandaar dat ik een tabel heb aangemaakt in de DB die alleen via het id een link heeft met de accountgegevens.
Een veld dat ik noem 'cookip' met een gecodeerd IP adres.
De ander veld noem ik 'cookw'. En is gecodeerde afgeleide van de aanmaaktijd van het het account.
In het bestaande script wordt gewerkt met de gebruikersnaam en het wachtwoord uit tabel 1.
Dat geeft dus bij een session ook geen probleem.
Maar als ik het om wil bouwen moet ik ipv de gegevens uit tabel 1, gebruik maken van tabel 2.
En hoe dat moet heb ik geen idee van.
Ik ben inmiddels zover dat ik gegevens uit verschillende tabellen in 1 sessie kwijt kan.

'vrijw en 'basis' zijn de twee tabellen.
Uit 'vrijw'haal ik webs, faceb, youtu.
Uit 'basis' de overige gegevens.


$query = $this->query("SELECT webs, faceb, youtu, first_name, middle_name, last_name, email_address, birth, username, password FROM vrijw, basis WHERE vrijw.id = $idee AND basis.id = $idee");


Voor de koppeling tussen beide tabellen gebruik ik het ID.
Nu heb ik nog 1 probleem, waar ik niet zo snel uit kom.
Voor het testen heb ik als referentie $idee aangemaakt en een waarde aan toegekend.
Die waarde moet ik zien te halen uit onderstaande.
Maar krijg dat niet goed voor elkaar.


function set_session($username, $password) {
	
			$query = $this->query("SELECT id FROM ".DBTBLE." WHERE username='$username' AND password='$password'");
.
.
.
$idee=34;


Iemand die me weer even op gang kan brengen?

Over het algemeen leer je enkel de userID op te slaan in de sessie. De rest van alle user gegevens bewaar je in de database en haal je bij ieder request waarbij je het nodig hebt weer uit de database.

een user wachtwoord in het bijzonder mag je NERGENS opslaan BEHALVE in de user tabel maar dan wel goed gecodeerd. Hiervoor gebruik je het liefst (op het moment van schrijven) BCrypt.
BCrypt kan ik in april gaan toepassen.
De server gaat eind maart over op PHP 5.6.

Ik leer eerst vanuit een bestaand oud inlogscript de verbeteringen aan te brengen.
Daarna komen de veranderingen zoals met name op dit forum worden aangedragen.
Het gaat dan om SQLi en waarschijnlijk ook de sessies opslaan in de database.
Dus als nu nog de value van de ID op een of andere manier is te vangen, dan lees ik het graag.

De sessies opslaan in de database?
Makes no sense. Verdiep je eerst eens goed in wat een sessie doet en hoe dit werkt. Iig zijn sessies bedoeld voor tijdelijke opslag.. hetgeen in de sessie opgeslagen is mag en zal verloren gaan. Je moet het zien als opslag voor een periode tussen twee of meer requests. Klassiek voorbeeld is het userid zodat je applicatie weet wie ingelogd is
Databases kunnen het sessiemanangement ook prima verzorgen hoor, maar inderdaad, de data in sessies zijn meestal wat meer van tijdelijke aard.

Het klinkt alsof TS een hoop oude code aan het de-spaghetti-seren is.

Zoals @Frank al aangaf hoef je in je sessie (voor het user management, althans) enkel een user id te onthouden.

Om een login te onthouden zou je daarvoor een cookie kunnen introduceren, bijvoorbeeld "rememberme" of "remember_login" of wat dan ook. In dit cookie zou je bijvoorbeeld enkel een random hash op kunnen slaan, die verder niets van doen heeft met gebruikersgegevens en zeker niet met je wachtwoord. Vervolgens houd je in een aparte tabel deze hashes bij, en aan welke user en bijvoorbeeld IP-adres deze gekoppeld is, en hoe lang deze login (op die specifieke machine) onthouden moet worden. Als iemand je site bezoekt controleer je eerst op het bestaan van dit cookie en bijbehorende gegevens, waarna je een gebruiker onder water automatisch inlogt als dit nodig zou zijn.

In je applicatie is het handig om een soort van user object te hebben, die je als kapstok voor gebruikersgegevens van de ingelogde persoon gebruikt. Deze kleed je aan met behulp van het user id in je sessie, en de gegevens van dit user object ververs je elke page-request.
sorry, maar merk dat ik reactie heb geplaatst die bij andere vraag hoort...
Even kijken of ik die kan verplaatsen.
Ik zie de andere vraag niet meer, haha.
Misschien samengevoegd?
Voor password versleuteling in oudere php versies kun je password compat gebruiken. Deze vindt je hier: https://github.com/ircmaxell/password_compat

Toevoeging op 18/03/2016 12:56:53:

Verder verkrijg je het userid uiteraard wanneer je het inlogformulier verwerkt. Je hebt dan een gebruikersnaam die je probeert te vinden in je user tabel. Indien je die gevonden hebt ga je het password dat uit het inlogformulier encrypten en vergelijk je deze met het encrypte password uit de database. Klopt die ook dan pak je uit de resultset het userid en schrijf je die in de sessie.

Toevoeging op 18/03/2016 13:01:17:

SELECT * FROM users WHERE username='frank'

Tip: overweeg je gebruikers in te laten loggen (ook) met hun emailadres ipv hun gebruikersnaam
". Vervolgens houd je in een aparte tabel deze hashes bij, en aan welke user en bijvoorbeeld IP-adres deze gekoppeld is"

Als je het ipadres erbij betrekt, zal iemand die zijn laptop meeneemt naar school dus aldaar weer uitgelogd zijn.

Of iemand die zijn smartphone via wifi inlogt en vervolgens buiten op het netwerk van Vodafoon komt uitloggen.
Of als hij van de ene naar de andere gsm mast gaat mogelijk ook weer een ander ipadres krijgen.

Als het niet heeeel kritisch is (zoals een bank of zo) , zou ik het ipadres achterwege laten.

Reageren