OOP database
Pagina: « vorige 1 2 3 4 volgende »
Lord Gaga op 07/01/2013 19:49:06:
Nou, in dit geval is dat nog niet echt mogelijk, maar stel dat ik een veld heb waarin het aantal 'coins' van de gebruiker worden opgeslagen.
Als die gebruiker bijvoorbeeld zijn email wil veranderen, dan gaat hij naar zijn settings, op dat moment wordt, neem ik aan, een user object gemaakt met daarin al zijn data.
Als er ondertussen bijvoorbeeld een moderator is die hem een x aantal coins geeft, worden die weer overschreven op het moment dat de gebruiker zijn email aanpast.
Of zie ik dit nu verkeerd?
Als die gebruiker bijvoorbeeld zijn email wil veranderen, dan gaat hij naar zijn settings, op dat moment wordt, neem ik aan, een user object gemaakt met daarin al zijn data.
Als er ondertussen bijvoorbeeld een moderator is die hem een x aantal coins geeft, worden die weer overschreven op het moment dat de gebruiker zijn email aanpast.
Of zie ik dit nu verkeerd?
Als een user naar een pagina toe gaat waar hij munten kan krijgen, dan wordt er een user object gemaakt. Als hij dan iets doet, worden zijn munten geupdate aan de hand van het aantal dat in je user object zit. Als in de tussentijd een admin munten geeft, wordt het toch verkeerd geupdate als je geen koppeltabel gebruikt? Enige manier hoe je dit kan voorkomen is of een koppel tabel aanmaken, of helemaal geen user object aanmaken, maar in dat laatste geval kan je net zo goed alle code die hierboven staat weggooien
Not Moose op 08/01/2013 12:20:12:
Om even hier op terug te komen
Als een user naar een pagina toe gaat waar hij munten kan krijgen, dan wordt er een user object gemaakt. Als hij dan iets doet, worden zijn munten geupdate aan de hand van het aantal dat in je user object zit. Als in de tussentijd een admin munten geeft, wordt het toch verkeerd geupdate als je geen koppeltabel gebruikt? Enige manier hoe je dit kan voorkomen is of een koppel tabel aanmaken, of helemaal geen user object aanmaken, maar in dat laatste geval kan je net zo goed alle code die hierboven staat weggooien
Lord Gaga op 07/01/2013 19:49:06:
Nou, in dit geval is dat nog niet echt mogelijk, maar stel dat ik een veld heb waarin het aantal 'coins' van de gebruiker worden opgeslagen.
Als die gebruiker bijvoorbeeld zijn email wil veranderen, dan gaat hij naar zijn settings, op dat moment wordt, neem ik aan, een user object gemaakt met daarin al zijn data.
Als er ondertussen bijvoorbeeld een moderator is die hem een x aantal coins geeft, worden die weer overschreven op het moment dat de gebruiker zijn email aanpast.
Of zie ik dit nu verkeerd?
Als die gebruiker bijvoorbeeld zijn email wil veranderen, dan gaat hij naar zijn settings, op dat moment wordt, neem ik aan, een user object gemaakt met daarin al zijn data.
Als er ondertussen bijvoorbeeld een moderator is die hem een x aantal coins geeft, worden die weer overschreven op het moment dat de gebruiker zijn email aanpast.
Of zie ik dit nu verkeerd?
Als een user naar een pagina toe gaat waar hij munten kan krijgen, dan wordt er een user object gemaakt. Als hij dan iets doet, worden zijn munten geupdate aan de hand van het aantal dat in je user object zit. Als in de tussentijd een admin munten geeft, wordt het toch verkeerd geupdate als je geen koppeltabel gebruikt? Enige manier hoe je dit kan voorkomen is of een koppel tabel aanmaken, of helemaal geen user object aanmaken, maar in dat laatste geval kan je net zo goed alle code die hierboven staat weggooien
Ik kan in de save functie toch ook gewoon controleren welke setters er zijn aangeroepen en aan de hand daarvan een query generen.
Stel ik gebruik setUsername(), setEmail() en dan save(), dan kan ik in save() toch 'zien' dat setUsername() en setEmail() zijn aangeroepen en dan alleen die aanpassen.
Precies, maar wat nou als je ook setCoints() hebt gebruikt?
Dan zou de save() functie zien dat setUsername(), setEmail() en setCoins() zijn aangeroepen en past alleen die drie 3 variabelen aan.
En wat nou als een admin ook de coins van je user aanpast? Ik snap het niet, je beschrijft een situatie waarbij het duidelijk is dat je coins overschreven kunnen worden, en dan begrijp je niet dat het nu nog steeds kan gebeuren ...
Stel nu dat jij naar de settingspagina gaat, worden al jouw gegevens uit de tabel in het object gezet.
Ondertussen leeg ik jouw voor en achternaam.
In de database heb jij dus geen voor en achternaam meer.
In jouw object staan echter nog wél een voor een achternaam.
Als jij op de settingspagina nu zou 'saven', dan zouden de voor en achternaam van het object dus weer in de database worden gezet, dat mag dus niet, want die heb ik net verwijderd.
Wat er dus gebeurd is dat een oude actie (het verwijderen van voor en achternaam) weer worden ontdaan, omdat die wijziging niet is doorgevoerd in het object (wat volgens mij ook niet kan)
Gewijzigd op 08/01/2013 12:49:01 door Lord Gaga
Oke maar de vraag is waarom zou iemand je achternaam en voornaam legen? Je moet je applicatie zo bouwen dat zo weinig mogelijk mensen die gegevens kunnen aanpassen (het liefst alleen de user zelf) dan krijg je dit soort problemen ook niet. Overigens is de kans dat twee mensen dezelfde data op hetzelfde moment aanpassen verwaarloosbaar (tenzij je applicatie verkeerd gebouwd is)
Wat nou als ik iemands rank wil aanpassen (vanwege ontslag bijv.)
Als diegene die ontslagen wordt naar een pagina gaat (met zijn huidige rank) waar een save() kan worden uitgevoerd, hoeft hij alleen maar te 'saven' en dan wordt zijn rank weer terug gezet naar hoe het was..
Hoe zou je dit dan beveiligen?
Als je niet wil dat hij het aan kan passen, moet je hem de rechten niet geven. Dan dondert het niet wat hij probeert op te sturen, dan werkt die update gewoon niet.
Heeft hij wel de rechten dan kan hij het aanpassen, wat er ook eerst stond.
Als iemand met rank 3 naar zijn settings gaat, wordt er voor hem een user object aangemaakt met rank 3.
Als ik hem in de tussentijd rank 1 geef en hij voert daarna een save uit, dan word de rank uit zijn user object weer opnieuw in de database gezet en heeft hij weer rank 3?
Gewijzigd op 08/01/2013 19:05:51 door Lord Gaga
Ja, maar dat gebeurt toch ook als er rank 1 stond en die gast zelf er weer rank 3 van maakt? Wat is het verschil?
Hoe bedoel je? Hij kan zelf zijn rank niet aanpassen?
Als hij zelf zijn rank niet kan aanpassen dan heb je dus helemaal geen probleem, want dan gaat dat dus niet mee in die update die je van zijn pagina krijgt. Tenminste, als je het goed hebt opgezet.
Jawel, want de userMapper haalt ALLE gegevens uit het object en slaat ze opnieuw op, dus dat betekent dat als hij de pagina met rank 3 bezoekt, die rank in het user object wordt gezet en die dus wordt opgeslagen als er een save wordt uitgevoerd.
Erwin H op 08/01/2013 19:08:54:
Tenminste, als je het goed hebt opgezet.
Dat heb je dus niet....
Wat je vergeten bent is dat je die rechten er op de een of andere manier in moet verwerken. Die UserMapper is dom wat rechten betreft, die krijgt wat hij krijgt en voert het uit. Alleen een rechten class bepaalt wat wel en niet mag worden aangepast door de ingelogde (of niet ingelogde) gebruiker. Heeft deze gast geen rechten om zijn rank aan te passen, dan moet die rechten class dat weten en zorgen dat die gegevens dus ook niet aangepast kunnen worden.
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
<?php
public function save(User $user)
{
$query = '
UPDATE
users
SET
activated = ' . $this->SQL->real_escape_string($user->getActivated()) . ',
username = "' . $this->SQL->real_escape_string($user->getUsername()) . '",
password = "' . $this->SQL->real_escape_string($user->getPassword()) . '",
email = "' . $this->SQL->real_escape_string($user->getEmail()) . '",
birthday = "' . $this->SQL->real_escape_string($user->getBirthday()) . '",
gender = "' . $this->SQL->real_escape_string($user->getGender()) . '",
dateTime = "' . $this->SQL->real_escape_string($user->getDateTime()) . '",
IP = "' . $this->SQL->real_escape_string($user->getIP()) . '"
WHERE
ID = ' . $this->SQL->real_escape_string($user->getID());
$this->SQL->query($query);
}
?>
public function save(User $user)
{
$query = '
UPDATE
users
SET
activated = ' . $this->SQL->real_escape_string($user->getActivated()) . ',
username = "' . $this->SQL->real_escape_string($user->getUsername()) . '",
password = "' . $this->SQL->real_escape_string($user->getPassword()) . '",
email = "' . $this->SQL->real_escape_string($user->getEmail()) . '",
birthday = "' . $this->SQL->real_escape_string($user->getBirthday()) . '",
gender = "' . $this->SQL->real_escape_string($user->getGender()) . '",
dateTime = "' . $this->SQL->real_escape_string($user->getDateTime()) . '",
IP = "' . $this->SQL->real_escape_string($user->getIP()) . '"
WHERE
ID = ' . $this->SQL->real_escape_string($user->getID());
$this->SQL->query($query);
}
?>
De gebruiker heeft rank 3 en opent de settings pagina.
Op dat moment wordt er dus een object aangemaakt:
'username' => 'Blaat'
'password' => 'Blaat'
'rank' => 3
'coins' => 10
Terwijl hij op die pagina verander ik in de database zijn rank naar 1.
Als hij daarna op de settings pagina zijn gegevens opslaat wordt save() dus uitgevoerd.
En in save() worden alle gegevens uit het object dus weer in de database gezet:
'username' => 'Blaat'
'password' => 'Blaat'
'rank' => 3
'coins' => 10
En dit geldt niet alleen voor de rank, dit geldt voor alle velden in de user tabel.
Rank ligt nu toevallig aan de rechten, maar hoe gaat dit met eventuele andere velden, want daarbij kan dit ook het geval zijn.
Gewijzigd op 08/01/2013 19:16:29 door Lord Gaga
Als hij de rechten niet heeft, dan is er ook niets aan de hand, want dan moet je dat via een rechten check oplossen. Doe je dat niet, check je bij een update dus niet of hij de rechten heeft, dan heb je een veel groter probleem overigens.
1 = gebruiker
2 = moderator
3 = admin
4 = etc.
Hoe controlleer ik bij het saven dan of hij de rechten heeft? Want de rank wordt uit het user object gehaald, die op dat moment nog de oude gegevens heeft..
Als de rank uit het user object wordt gehaald dan doe je het verkeerd. Uberhaupt ben ik geen voorstander van user gegevens op die manier opslaan en vasthouden. Als die gegevens allemaal in de database staan dan ben je het dubbel aan het opslaan, waarbij je problemen kan krijgen op het moment dat gegevens op een andere plek kunnen worden aangepast.... zoals je nu door hebt.
Eigenlijk moet je de gegevens gewoon vasthouden op 1 plek (database dus) en elke keer dat je het nodig hebt ophalen. Dat moet je hier dus ook doen en dan kan je zien wat de gebruiker mag en niet mag, op het moment dat het van toepassing is.
Gewijzigd op 08/01/2013 19:37:51 door Erwin H
Want zo'n user object houdt altijd de inhoud vast toch? Daar dient die toch voor..