[Idee] Simples Rechtesystem

[Jay]

Ich möchte mit einfachsten Mitteln ein Rechtesystem erstellen. Jetzt habe ich mir sowas überlegt. Es folgt einem einfachen Prinzip. Alle Methoden die Daten ändern bekommen zB das Prefix Write.

Hier ein Beispiel:

 <?php
class PermissionProtector {
    
    public function __call ($function,$parameters) {
        
        list ($permissionType,$function) = explode ('__',$function);
        
        switch ($permissionType) {
            
            case 'Write':
                // TODO check the users permission
            break;
 
        }
        
        // Now call the function
        call_user_method_array($function,$this,$parameters);
    }
}
 
class TesterClass extends PermissionProtector {
    function schreibFunktion() {
        echo 'hey';
    }
}
 
$obj = new TesterClass();
$obj->Write__schreibFunktion();
?>  

Was haltet ihr von der Idee?

MfG Fat Tony

[Ben]

Nette Idee, irgendwie .. .. also .. irgendwie .. nett .. ^^
Muss ich, wenn ich etwas mehr Konzetrationsfähigkeit aufbringe, mal drüber grübeln ..

[niklasboelter]

ist handlich und doch extrem erweiterbar.
gefaellt mir die idee :)

[Ben]

Ich frage mal weiter .. wie genau überprüfst Du denn die Rechte des Users?
Jou, Du rufst Daten aus der Datenbank ab .. klasse *gg* .. aber wie genau speicherst Du die Rechte?

Danke für die Antwort.
Grüße Ben.

[axo]

uh, ganz schlecht, sorry :)
1. mit einem einfachen verschreiber hat man die komplette protection rausgenommen.
2. __call() halte ich für das größte übel der menschheit ... eine methode sollte zur interpretier/kompilierzeit zur verfügung stehen, und der interpreter soll sich darum kümmern, ob die methode existiert oder nicht, sonst verdirbt man die schnittstelle.
ich erschlage jeden, der mich dazu zwingt, erst seine __call() - methode zu verstehen, bevor ich weiß, wie ich ein objekt verwenden kann bzw. welche methoden mir (wann!?! ) zur verfügung stehen.
2. gibt es ein schönes design pattern für sowas, das heißt access proxy.

 <?php

interface A {
    function foo();
    function bar();
}

class someObj implements A {
    function foo() {
        // do something
    }
    function bar() {
        // do something else
    }
}

class Proxy implements A {
    protected $a;
    function __construct (A $a) {
        $this -> a = $a;
    }
    function foo() {
        $this -> a -> foo();
    }
    function bar() {
        $this -> a -> bar();
    }

}

class AccessProxy extends Proxy {
    private $_b; 
    
    function __construct(A $a, User $b) {
        parent::__construct($a);
        $this -> _b = $b;
    }
    
    function foo() {
         if($this -> _b -> hasAccess()) {
             $this -> _a -> foo();
         }
         throw new InvalidAccessException();
    }
    
}


// usage:

$user = new User();

$ap = new AccessProxy(new someObj(),$user);
try {
  $ap -> foo();
} catch (Exception $e) {
    echo "sorry, no access!";
}


?>  

verstehen, anwenden.
im beispiel kann man auch schön sehen, wie der accessProxy nur den zugriff auf eine methode verhindert, und die
methode bar() gar nicht anfasst :)


grüße
axo

[Ben]

Yeah. Fein. An das Proxy hatte ich auch mal (etwas länger her) gedacht, aber ich muss zugeben, dass ich es bis heute nicht so gaaaaaaaaaanz verstanden habe. Hehe ...
Mit Deinem Quellcode werd ich mal rumspielen ..

Grüße Ben.

[beny_mcde]

kann mich nur der meinung von axo anschließen...
für das rechte system ist das proxy pattern erste sahne...

jetzt fragt man sich natürlich warum wurden diese methoden (auch __get und __set) überhaupt eingeführt?

in manschen fällen kann man sie sehr gut einsetzten, wenn z.B. hohe flexibilität gefordert wird.

ich könnte mir vorstellen eine OO Datenbank abstraktion mit __call __get und __set zu bauen.
das dann etwa so aussieht

 $db = new DBObject('localhost','root','geheim','db1');
 $usertable = $db->tables->users();
 $usertable->row(1)->name='beny';

aber wo ist hier der clou?
die methode users im unterobjekt tables des DBObjects existiert garnicht,
vielmehr wird hier mit der __call methode gearbeitet, die prüft ob die tabelle users in der db vorhanden ist, wenn ja wird ein Table objekt erzeugt.
die funktion row gibt den datensatz anhand der als parameter übergebenen id zurück, das datensatz objekt hat natürlich auch keine variable, die name heißt, sondern arbeitet hier mit den __get __set methoden und prüft ob das feld vorhanden ist...

das passt jetzt zwar nich unbedingt zu der überschrift des threads aber trotzdem, es musste halt raus

[axo]

naja, es ist halt eine andere art der programmierung... im prinzip unterstützt das ganze die 'weiche typisierung', die programme stark vereinfachen kann, aber programme auch schwieriger machen kann.
nimm als beispiel nur mal die proxyklasse ... die könnte man natürlich auch einfach als

 class Proxy extends someOtherObject {
   proteced $a;
   public function __construct(someOtherObject $a) {
       $this -> a = $a;
  }

  public function __call($method, $args) {
         return $this -> a -> {$method}($args);
  }
} 
  

implementieren, und sich auf php verlassen ... man müsste bei neuen methoden in someOtherObject nichts mehr am Proxy ändern und der würde nach wie vor alle methodenaufrufe delegieren.
das ganze geht aber nur zum preis der lesbarkeit ... kürzerer code, ab und zu unerwartetes verhalten. kommt darauf an, was einem lieber ist.
genauso die __set und __get - methoden - wenn man keine setXXX() und getYYY() - methoden schreiben will, kann man __set verwenden, darf aber dann im objekt gar keine variablen deklarieren, und hat implizites verhalten.

man _kann_ damit auf die schnauze fallen, _muss_ aber nicht.
ich für meinen teil bin lieber explizit im code, dann weiß ich in einem jahr immer noch, was ich wollte... da schreib ich lieber ein paar zeilen mehr, weiß aber, dass ich der maschine ganz genau gesagt hab, was ich will.

bei der datenbank-abstraktion das selbe - man könnte theoretisch eine wunderbare abstraktion machen, die eine komplette vererbungshierarchie durch __call(), __get() und __set() ersetzt. damit spart man sich jeweils eine klasse pro tabelle, eine klasse pro zeilentyp etc ... eine menge an code. aber man verzichtet komplett auf typisierung ... und riskiert damit fehlerhaftes default-verhalten.

[beny_mcde]

das stimmt, man sollte einfach sehr vorsichtig damit umgehen und nicht versuchen an so vielen stellen wie möglich diese methoden einzusetzen...

wobei ich es bei der datenbank echt sinnvoll finde,
da man sonst ja wie du schon sagtest immer für jede neue tabelle neuen code schreiben. oder man wendet hier codegenerierung an, so müsste es ja möglich sein mit den daten die "DESCRIPT TABLE xyz" liefert den completten code zu generieren, ich glaube im PEAR projekt gibts es solch einen ansatz schon...

schaden das folgender code nicht funktioniert so funktioniert wie ich mir überlegt habe.

  class A {
  private $val1;
  private $val2;
  
  function __construct(){}
  function __set($key,$value){
   echo "setze $key auf $value<br>";
  }
  function __get($key){
   echo "hohle $key<br>";
  }    
      
 }
 
 $a = new A();
 $a->val1='wee'; 
  

hier kommt dann "Cannot access private property A::$val1",
schön währe es wenn dieser aufruf da die variable $val1 private und somit von aussen nicht sichtbar ist auf die __get __set methode weitergeleitet würde, so hätte man innerhalb der klasse freien zugriff auf alle variablen und könnte bei externen zugriffen rechte checken und wenn es nötig ist, eingreifen.


- edit: ich sollte mir mal angewöhnen die php und nich die code tags zu verwenden um bundischen code zu kriegen...

[Jay]

@axo
Nach genau dem selben Prinzip hatte ich das vorher gelöst. Aber dann muss ich eben immer diese Abfrage machen und das war mir zu blöd.

jetzt habe ich mir diese methode überlegt.

@Ben
Die Rechte sind im Objekt User verfügbar.

 $user = new User();
//Boolsche Variable
//Sagt nur ob der User eingeloggt ist oder nicht.
$user->permissions['moduleId']; // dieses feld enthält dann die Rechte für das jeweilige Modul. 
  

[Ben]

Äh, jo .. ich meinte jetzt eher wie Du das in der Datenbank speicherst ..

[Jay]

 #
# The structure for table `groupPermissions`
#
DROP TABLE IF EXISTS `groupPermissions`;
CREATE TABLE `groupPermissions`
(
  `groupId` TINYINT UNSIGNED NOT NULL,
  `moduleId` SMALLINT UNSIGNED NOT NULL,
  `rights` CHAR (3) NOT NULL,
  FOREIGN KEY (`groupId`) REFERENCES userGroups(`groupId`)
) TYPE=MyISAM;

#
# The structure for table `userGroups`
#

DROP TABLE IF EXISTS `userGroups`;
CREATE TABLE `userGroups`
(
  `groupId` TINYINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  `name` VARCHAR(100) NOT NULL DEFAULT ''
) TYPE=MyISAM;

#
# The structure for table `users`
#

DROP TABLE IF EXISTS `users`;
CREATE TABLE `users`
(
  `userId` SMALLINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  `username` CHAR(30) NOT NULL DEFAULT '',
  `password` CHAR(32) NOT NULL DEFAULT '',
  `name` CHAR(30) NOT NULL DEFAULT '',
  `surname` CHAR(40) NOT NULL DEFAULT '',
  `email` VARCHAR(100) NOT NULL DEFAULT '',
  `registerDate` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
  `lastVisit` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
  `block` BOOLEAN DEFAULT '0',
  `userGroup` TINYINT(4) NOT NULL  DEFAULT '1',
   FOREIGN KEY (`userGroup`) REFERENCES userGroups(`groupId`)
)TYPE=MyISAM; 
  

groupPermissions.rights kann folgende Werte haben.
ned // new edit delete
ed // edit delete
...

[Ben]

Danke