OOP database

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Pagina: « vorige 1 2 3 4 volgende »

Moose -

Moose -

08/01/2013 12:20:12
Quote Anchor link
Om even hier op terug te komen

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 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
 
PHP hulp

PHP hulp

27/04/2024 02:18:11
 
Lord Gaga

Lord Gaga

08/01/2013 12:29:36
Quote Anchor link
Not Moose op 08/01/2013 12:20:12:
Om even hier op terug te komen

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 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.
 
Moose -

Moose -

08/01/2013 12:33:59
Quote Anchor link
Precies, maar wat nou als je ook setCoints() hebt gebruikt?
 
Lord Gaga

Lord Gaga

08/01/2013 12:34:46
Quote Anchor link
Dan zou de save() functie zien dat setUsername(), setEmail() en setCoins() zijn aangeroepen en past alleen die drie 3 variabelen aan.
 
Moose -

Moose -

08/01/2013 12:42:16
Quote Anchor link
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 ...
 
Lord Gaga

Lord Gaga

08/01/2013 12:47:53
Quote Anchor link
Het gaat me er niet om dat 2 mensen op hetzelfde moment hetzelfde veld aanpassen, maar dat de andere velden worden aangepast.

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
 
Moose -

Moose -

08/01/2013 18:26:27
Quote Anchor link
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)
 
Lord Gaga

Lord Gaga

08/01/2013 18:51:29
Quote Anchor link
Ja, dat is zo, maar ik wil in de user tabel ook een rank opslaan.

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?
 
Erwin H

Erwin H

08/01/2013 18:59:25
Quote Anchor link
Als het leeg is en hij vult het weer opnieuw in, dan komt het toch ook gewoon terug?
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.
 
Lord Gaga

Lord Gaga

08/01/2013 19:05:22
Quote Anchor link
Jawel toch?

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
 
Erwin H

Erwin H

08/01/2013 19:06:22
Quote Anchor link
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?
 
Lord Gaga

Lord Gaga

08/01/2013 19:07:30
Quote Anchor link
Hoe bedoel je? Hij kan zelf zijn rank niet aanpassen?
 
Erwin H

Erwin H

08/01/2013 19:08:54
Quote Anchor link
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.
 
Lord Gaga

Lord Gaga

08/01/2013 19:10:14
Quote Anchor link
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

Erwin H

08/01/2013 19:13:15
Quote Anchor link
Dat zeg ik:
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.
 
Lord Gaga

Lord Gaga

08/01/2013 19:15:34
Quote Anchor link
Op dit moment is dit de save functie:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
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);
            }

?>


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
 
Erwin H

Erwin H

08/01/2013 19:23:27
Quote Anchor link
Nogmaals, als de gebruiker de rechten heeft om het aan te passen maakt het niets uit. Vervelend dat het weer terug gaat, maar dat mag. Jij kan (bijna) niet weten of hij het echt terug wilde of gewoon heeft laten staan.

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.
 
Lord Gaga

Lord Gaga

08/01/2013 19:25:58
Quote Anchor link
En die rechten worden dus bepaald aan de hand van de rank toch?
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..
 
Erwin H

Erwin H

08/01/2013 19:37:32
Quote Anchor link
Geen idee, jij bepaalt de rechten volgens mij....

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
 
Lord Gaga

Lord Gaga

08/01/2013 19:42:12
Quote Anchor link
Maar hoe je dat dan in OOP? :/
Want zo'n user object houdt altijd de inhoud vast toch? Daar dient die toch voor..
 

Pagina: « vorige 1 2 3 4 volgende »



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.