ACL - Allow, Deny für Module, Controller, Actions

[Mr.AndersoN]

Hi,

in meinem aktuellen Projekt bin ich auf das Problem gestoßen, dass man für alle drei Resourcentypen (Module, Controller, Actions) keine Zugriffsbeschränkung treffen kann.
Man kann Resourcen zwar selbst als Module oder Controller oder Actions implementieren und die Priviligien dementsprechend auch...aber wie gesagt: oder

Nach einigen Überlegungen, wie man eine Zugriffsbeschränkung unter Anbetracht von allen Resourcentypen lösen könnte, bin ich auf die Assertions gestoßen, die in der ZF-Doku beschrieben werden:
http://framework.zend.com/manual/de/zend.acl.advanced.html#zend.acl.advanced.assertion s

Daraufhin hab ich mich mal 10 Minuten hingesetzt und folgende(r) Lösung(sansatz) ist dabei herrausgekommen:

Klassen:
http://ubuntuusers.de/paste/21955/
http://ubuntuusers.de/paste/21956/Verwendung:
$acl->allow('<role>', '<module>', '<controller>', new Grusch_Assertion_Action('<action>', Zend_Acl::TYPE_ALLOW));
$acl->deny('<role>', '<module>', '<controller>', new Grusch_Assertion_Action('<action>', Zend_Acl::TYPE_DENY));Je nachdem, wie die Resourcen implementiert wurden, muss man entsprechend die Assertion für den Controller oder für die Action benutzen.
Ein Assertion für Module könnte man ebenso noch implementieren.

Mich würde eure Meinung dazu interessieren.
Ich empfinde es als eine schnelle und leichte Lösung. Es ist leicht intigriert, ohne, dass man seine Implementation für Auth abändern muss.

[KingCrunch]

in meinem aktuellen Projekt bin ich auf das Problem gestoßen, dass man für alle drei Resourcentypen (Module, Controller, Actions) keine Zugriffsbeschränkung treffen kann.Module, Controller und Actions sindper se keine Resourcentypen!!! Eine Resource ist ein abstrakter Begriff, der rein von der Definition kein äquivalent als Objekt hat ;) Zudem ist es Absicht, das pro Regel und pro Abfrage immer nur genau eine Resource abgefragt werden kann.

[Octavian]

Definier doch einfach eine Resource als "<module>_<controller>_<action>".
Oder von mir aus auch als Resource "<module>_<controller>" und dann als Priviledge "<action>" beim allow/deny.
Dann kannst du doch schön für jede Seite (Action) festlegen welche Rollen die Erlaubnis dafür bekommen sollen.

[t-mow]

Definier doch einfach eine Resource als "<module>_<controller>_<action>".
Oder von mir aus auch als Resource "<module>_<controller>" und dann als Priviledge "<action>" beim allow/deny.
Dann kannst du doch schön für jede Seite (Action) festlegen welche Rollen die Erlaubnis dafür bekommen sollen.

So mach ich's bisher auch. MODUL_CONTROLLER ist meine Resource, die Action das Privileg... also einfach mit einem _ verknüpft :)

[Nilson]

Musst mal im Forum suchen, habe damals ne Lösung noch nen bissle umgeschrieben, sodass du alles an die DB gebunden laden kannst und auch Module auf Bezug von Controller unterschieden werden....wende das so nun schon ne Weile an und läuft wirklich super, wenn man das ganze dingens noch cached....sprich den ganzen Abruf der Resourcen,Roles und Privileges dann haste auch die Performance im Griff...

MFG Nilson

[Mr.AndersoN]

Mir gings um eine schnelle Lösung, ohne erst meine Auth-Implementation abzuändern.
Hatte auch erst im Sinn, einfach Modul und Controller in die Resource zu stecken, bin dann aber auf o.g. Lösung gestoßen.

@Königsmüsli
In meiner ACL-Implementation ist eine Resource sehr wohl ein Synonym für die jeweiligen Module.
Was du denkst, was ich glaube:
Modul -> Resource
Was ich meine:
Resource -> Modul
Zum letzten: Bei mir wird weiterhin nur eine Resource abgefragt - die Actions sind bei mir Behauptungen...

[KingCrunch]

die Actions sind bei mir Behauptungen...Sie sind was? Oo

[Mr.AndersoN]

Fragst du das auch, wenn dir jemand das Wort "Ausnahme" für eine Exception an den Kopf knallt? :rolleyes:

[budcha]

dann sei konsequent, denglish ist nun mal lingua franka ... aber zuerst denglish und dann nur auf deutsch ist verwirrend.

grundlegend:
In meiner ACL-Implementation ist eine Resource sehr wohl ein Synonym für die jeweiligen Module.

in der idee der acl aber nunmal nicht, vondaher ist die aussage: "Resource = (Modul || Controller || Action || SomeNiceClass || EverythingYouWant)" schonmal besser, als das einengendere Konzept das ein Modul per se eine Resource darstellt.

was mich jetzt interessieren würde: wieso mußt du deine auth implementierung ändern, wenn du anstatt eine assertion zu benutzen, die modul_controller variante verwendet hättest?

[Mr.AndersoN]

Für jemanden, der beide Sprachen beherrscht, sollten gewisse Grundbegriffe keinesfalls verwirrend sein.

Die Idee der ACL ist es, eine Resource nicht an ein bestimmtes Objekt zu binden und dies jedem aufzuzwingen. Das ist mir sehr wohl klar. In meinem "speziellen" Fall (meine Implementation der ACL) ist eine Resource nunmal das Modul...ich verstehe nicht, was daran so unverständlich ist...

Zu deinem Interesse:
In der Auth-Implementation weise ich nunmal der Resource ihr Ziel zu - bei mir Module, das könnte natürlich auch der Controller, die Action oder was auch immer sein.
Wenn die Resource nun aber zwei Ziele hat - was im übrigen nach KingCrunch der Resourcendefinition noch weiter entfernt ist - muss ich diese beiden Ziele in meiner Auth-Implementation auseinander nehmen und entsprechend weiterverarbeiten.