Ontwerpen usermanagement
Pagina: « vorige 1 2 3 4 5 volgende »
Quote:
Ik denk echter dat dat niet de bedoeling van Wouter was. Wat ikzelf nu van plan ben is in de 'Storage' klasse een aantal basis methoden zou gaan schrijven. Bijvoorbeeld om kunnen te schrijven naar een bestand en opslaan in de database. Ik zou dus SessionStorage laten extenden van Storage en e.v.t. de SessionHandlerInterface implementeren. Graag jullie meningen!
Ik hou erg van al die 'magic' interfaces in PHP, maar ik begrijp dat je dat niet wilt.
Het was ook niet mijn eerste bedoeling. Mijn bedoeling was dat je een Storage interface ging maken die voorschrijft welke methods er verplicht moeten zijn. Vervolgens laat je alle Storage klassen deze implementeren:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
<?php
interface StorageInterface
{
public function set($id, $value);
public function get($id);
}
class SessionStorage implements StorageInterface
{
public function __construct($session_id = null)
{
session_start($session_id);
}
public function set($id, $value)
{
$_SESSION[$id] = $value;
}
public function get($id)
{
if (!isset($_SESSION[$id])) {
throw new \InvalidArgumentException('Session '.$id.' has not been set');
}
return $_SESSION[$id];
}
}
class FileStorage implements StorageInterface
{
protected $file;
public function __construct($fileName)
{
if (file_exists($fileName)) {
$this->file = fopen($fileName, 'a');
} else {
throw new \InvalidArgumentException('File '.$fileName.' is not found in '.getcwd());
}
}
public function set($id, $value)
{
fwrite($this->file, "\n[$id] ".$value);
}
public function get($id)
{
while ($line = fgets($this->file)) {
if (preg_match('/^\['.$id.'\]/', $line)) {
return end(explode('] ', $line);
}
}
throw new \InvalidArgumentException('Key '.$id.' has not been set');
}
}
class YmlFileStorage extends FileStorage
{
// ...
}
?>
interface StorageInterface
{
public function set($id, $value);
public function get($id);
}
class SessionStorage implements StorageInterface
{
public function __construct($session_id = null)
{
session_start($session_id);
}
public function set($id, $value)
{
$_SESSION[$id] = $value;
}
public function get($id)
{
if (!isset($_SESSION[$id])) {
throw new \InvalidArgumentException('Session '.$id.' has not been set');
}
return $_SESSION[$id];
}
}
class FileStorage implements StorageInterface
{
protected $file;
public function __construct($fileName)
{
if (file_exists($fileName)) {
$this->file = fopen($fileName, 'a');
} else {
throw new \InvalidArgumentException('File '.$fileName.' is not found in '.getcwd());
}
}
public function set($id, $value)
{
fwrite($this->file, "\n[$id] ".$value);
}
public function get($id)
{
while ($line = fgets($this->file)) {
if (preg_match('/^\['.$id.'\]/', $line)) {
return end(explode('] ', $line);
}
}
throw new \InvalidArgumentException('Key '.$id.' has not been set');
}
}
class YmlFileStorage extends FileStorage
{
// ...
}
?>
Het is maar net welke insteek je hebt. Op jouw manier bepaal jij als ontwikkelaar hoe de afnemers van jouw app de rechten moeten uitdelen. Op mijn manier laat je die keuze aan hen over.
En natuurlijk moet je dan gaan doornormaliseren, waardoor je queries complexer worden, maar dat is dan gewoon de keuze die je maakt, en dat is pesoonlijk ;-)
Het enige wat ik wil zeggen is dat de 'persoonlijke' rechten al mogelijk zijn mits je groepen van 1 persoon toelaat. Dat je met zo'n model dus als ontwikkelaar de gebruiker beperkt ben ik het niet mee eens. Je doet het alleen op een, wat mij betreft, transparantere manier. In de GUI kan je namelijk nog precies hetzelfde als wat jij kan.
Alweer erg bedankt voor je duidelijk antwoord. Ik apprecieer dit ten zeerste. Uiteraard ook de reacties van de andere mensen in dit topic.
Ik denk dat dit inderdaad een goede structuur geeft. Bij SessionStorage ben ik dan ook wel van plan de interface die eigenlijk voor PHP 5.4 bedoeld is te gaan gebruiken.
@Ger & Erwin
Reacties hierover zijn natuurlijk wél gewenst. Als er geen discussie is, dan kan je er ook niets van leren.
Het model van Ger vind ik erg mooi, maar dan weer net iets te ver gaan. Voor ingewikkelde queries heb ik geen angst, maar de vraag is natuurlijk: is het noodzakelijk? En dan denk ik in dit geval van niet.
Mijn plan is dus een user tabel, een group table en tot slot een permissions table. In eerste instantie vond ik dit geen prettig idee. Ik wil niet dat de eindgebruiker verplicht is een groep te maken voor 1 specifieke gebruiker. Maar, ik heb er eens verder over nagedacht. Ik kan dit probleem in de GUI inderdaad netjes oplossen (eigenlijk wat Erwin ook al aangeeft).
Nogmaals bedankt voor alle jullie reacties!
Ik ga nu nog wat inspiratie op doen voor mijn database klasse. Dan kan het echte werk beginnen. Moest er iemand nog leuke voorbeeldjes hebben van een database klasse die werkt met PDO, altijd welkom!
Pimple? Doctrine?
Pimple is toch een DI container?
Ja, sorry, ik bedoelde Propel
Propel er erg leuk uitzien en zelfs werken. Alleen vind ik dat persoonlijk te vergaand. Veel extra code om het, naar mijn mening, jezelf makkelijk te maken. Iets wat ik persoonlijk niet altijd nodig vind. Daarom ga ik toch eerder gaan voor een eenvoudige database klasse die een paar standaard zaken voor mij afhandelt. (zoals bv. de error reporting)
Bijvoorbeeld iets als dit
Ik vind die Bijvoorbeeld iets als dit
Alleen de naam van die klasse waar je naar link schrikt mij al af. Ik zou je misschien door dit laten inspireren, maar zeker niet gebruiken. Singleton, het idee alleen al... ;)
Inspireren, inderdaad. Singleton ga ik sowieso niet voor, ben ik ook geen fan van.
Ik zou wel eens gaan kijken naar PHP iterators kan je leuke dingen mee doen in combinatie met dit.
Zoals bv. in Java method.next()? Lijkt me idd plan, moet ik me binnen PHP wel nog in verdiepen. (In Java ook hoor haha)
iterator of iteratoraggregate of 1 van al die andere spl.iterators
Bijv. Gewijzigd op 05/07/2012 23:37:46 door Wouter J
Ook zou ik dit over meerdere objecten spreiden:
Code (php)
1
2
3
4
2
3
4
- Database (connectie en uitvoeren query)
- Result (het resultaat van een query)
- DataResult (resultaat van een select query)
- ...Result (resultaat van een UPDATE, DELETE of INSERT query)
- Result (het resultaat van een query)
- DataResult (resultaat van een select query)
- ...Result (resultaat van een UPDATE, DELETE of INSERT query)
En misschien zelf een query object om je queries op te kunnen bouwen.
Ik zocht alleen een voorbeeld.
Ik heb al heel wat van mijn applicatie ontworpen. Eigenlijk de 'basis' classes. Ik vind nu dat het tijd is om verder te gaan met het "User Management". Vandaar dat ik terug een reactie plaats in dit topic.
Ik ben naar Wouters' model de Strategy patern aan het toepassen. Alleen zit ik nu met een vraag of een bepaalde strategy wel echt als een strategy te beschouwen valt. Namelijk AdminAccesStrategy.
Mijn bedoeling hiermee is te bepalen of het gaat om een gebruiker die in het admin gedeelte mag of die dat net niet mag. Alleen vraag ik me af, of dit wel een correcte wijze is. Zou ik dit bijvoorbeeld beter in de Authentication doen?
Want als ik dan verder denk, wil ik eigenlijk elke pagina met meer functies dan 'bekijken' toch enkele rechten toekennen. Mijn uiteindelijk doel, is een CMS te ontwikkelen. Er gaan dus werkelijk bezoekers zijn (die niet ingelogd zijn), leden (die dus beperkte rechten hebben, bijvoorbeeld bepaalde beveiligde pagina's bekijken) en dan verschillende soorten admins (die dus toegang hebben tot een controlepaneel).
Ik vraag me alleen af, hoe ik dit deel van de rechten het best kan implementeren. Dus eigenlijk bepalen of een gebruiker al dan niet een bepaalde pagina mag bekijken.
En eventueel combinaties daarvan. Het is maar wat je in ontwerp voor detaillering wenst, voor welke methode je gaat.
Ik implementeer authentication in een aparte service, ongeveer zoals CodeIgniter en Zend Framework dat doen en bij mij maakt authetication dus geen deel uit van het domein.
sorry als ik het wat boud opschrijf.
Gewijzigd op 28/08/2012 23:18:47 door John Berg
Daarom zit ik te denken om alle rechten op te halen en deze toe te voegen aan het User object. Dit in de vorm van een array.
Code (php)
1
2
3
2
3
<?php
$rights = array('editUser' => true, 'removeUser' => true, 'deletePage' => false, 'editPage' => false)
?>
$rights = array('editUser' => true, 'removeUser' => true, 'deletePage' => false, 'editPage' => false)
?>
Bij de authorization zou ik dan kunnen nagaan of een gebruiker de rechten heeft voor bepaalde zaken al dan niet te doen. Bv. d.m.v. $auth->getPermission('editUser').
Daar bovenop zou ik een bitwise model willen toevoegen. Wat eigenlijk het access level bepaald. Bv. op pagina x moet de bitwise oplossing minimaal 128 zijn. (wat dan een combinatie is van een aantal permissies)
Wat denken jullie hiervan? Of heeft er iemand nog een leuk idee?
Ook nog best lastig, als je in het backend de rechten van een user wil instellen, en je hebt veel pagina's.