Ankündigung

Einklappen
Keine Ankündigung bisher.

Anwendungsmodule einschränken

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Anwendungsmodule einschränken

    Hallo,

    ich arbeite gerade an einem größeren Framework und bin auf ein konzeptionelles Problem gestoßen. Das Framework dient als Grundlage für mehrere Anwendungen die teilweise auch von Dritten erweitert werden sollen. Hierfür möchte ich ein Modulsystem integrieren, dass es ermöglicht, über verschiedene Repositories Funktionalitäten nachzuinstallieren. Soweit eigentlich kein Problem.

    Das Problem ist jetzt aber, dass ich die Berechtigungen der verschiedenen Module eingrenzen möchte. Das heißt konkret, ich möchte z.B. bestimmen können, dass das Modul über den database abstraction layer des Frameworks nur auf bestimmte Datenbanken/Tabellen zugreifen kann. Das könnte ich mit einem entsprechenden Rechtesystem vermutlich auch noch irgendwie bewerkstelligen.

    Jetzt suche ich aber nach Möglichkeiten, dass die Module nur Schnittstellen aus dem Framework nutzen dürfen und nicht z.B. selbst eine Datenbankverbindung aufbauen und damit Zugriff auf Daten haben, die sie eigentlich nichts angehen.

    Eine langfristige Möglichkeit wäre vermutlich das Sandboxing der Module durch die Einführung einer abstrahierenden Sprache, die dann in PHP geparst wird. Aber eigentlich möchte ich vermeiden, dass die Entwickler sich neben dem Framework noch in eine Pseudosprache einarbeiten müssen.

    Kennt ihr entsprechende Ansätze für das Problem? Was würdet ihr vorschlagen?


    mfg
    Link
    "Ein Script ist nur dann gut, wenn es unabhängig von der verwendeten Plattform funktioniert"

  • #2
    Das halte ich für kaum möglich. Mein Rat: Lass es! Wer nutzt schon ein Framework, das ihn zu bestimmten Prinzipien zwingt? Biete gute Standards an, dann nutzen die Anwender vielleicht auch Deine DB-Abstraktion. Berechtigungen gehören imho auf die Anwendungsebene, nicht auf die der Implementierung.
    [COLOR="#F5F5FF"]--[/COLOR]
    [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
    „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
    [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
    [COLOR="#F5F5FF"]
    --[/COLOR]

    Kommentar


    • #3
      Naja - Wenn jede Applikation die Module mit einer eigenen Konfiguration einbinden würde, dann könnte man dort eine Art ACL implementieren.

      Kommentar


      • #4
        Ein mittelding wäre den Zugriff auf die Konfiguration via API einuschränken und die Konfiguration an sich zu verschlüsseln. Nutzt natürlich nur was, wenn die Logik, die entschlüsselt zumindest obfuscated ist, sonst isses witzlos. Aber ob dieser Aufwand sich wirklich lohnt bezweifle ich ganz stark.

        Je nach Einsatzgebiet deines Frameworks würde auch noch das Konzept eines "AppStores" funktionieren. Das Framework akzeptiert bei der automatischen Installation nur von dir zertifizierte Module. Und dafür kannst du ja dann Zertifizierungsrichtlinien aufstellen. Gegen manuelles installieren bzw. sideloaden wie es jetzt neudeutsch heißt, hast du natürlich keine Chance. Einfach irgendwo einen Satz hin, dass du / ihr für die Drittmodule nicht verantwortlich seid und die Nutzung auf eigene Gefahr ist, und gut ist.

        Kommentar


        • #5
          Zitat von GSJLink Beitrag anzeigen
          Eine langfristige Möglichkeit wäre vermutlich das Sandboxing der Module durch die Einführung einer abstrahierenden Sprache, die dann in PHP geparst wird. Aber eigentlich möchte ich vermeiden, dass die Entwickler sich neben dem Framework noch in eine Pseudosprache einarbeiten müssen.
          Sandboxing geht auch ohne eigene Sprache: http://php.net/manual/en/runkit.sandbox.php - dem Skript in der Sandbox kannst du den Zugriff auf Funktionen einschränken und ihm ausgewählte Variablen zur Verfügung stellen. Es läuft aber auch jedes Mal in einem eigenen Thread, für Framework-Module ist dieser Ansatz also ungeeignet.

          Ein mittelding wäre den Zugriff auf die Konfiguration via API einuschränken und die Konfiguration an sich zu verschlüsseln. Nutzt natürlich nur was, wenn die Logik, die entschlüsselt zumindest obfuscated ist, sonst isses witzlos
          Den Ansatz dagegen finde ich gar nicht so schlecht. Man könnte die Konfiguration und das Entschlüsselungs-Skript bzw. die Konfigurations-API oberhalb des Anwendungsverzeichnis anlegen und nachdem sie vom Core geladen wurden, open_basedir einschränken:
          As of PHP 5.3.0 open_basedir can be tightened at run-time.
          Direktzugriff mit fopen, include etc. ist ab diesem Zeitpunkt nicht mehr möglich und der Aufruf der Konfigurations-API kann auf Code-Ebene geregelt werden. Es könnte allerdings notwendig sein, die Reflection-Extension zu deaktivieren, damit der Schutz nicht ausgehebelt werden kann.
          [IMG]https://g.twimg.com/twitter-bird-16x16.png[/IMG][URL="https://twitter.com/fschmengler"]@fschmengler[/URL] - [IMG]https://i.stack.imgur.com/qh235.png[/IMG][URL="https://stackoverflow.com/users/664108/fschmengler"]@fschmengler[/URL] - [IMG]http://i.imgur.com/ZEqflLv.png[/IMG] [URL="https://github.com/schmengler/"]@schmengler[/URL]
          [URL="http://www.schmengler-se.de/"]PHP Blog[/URL] - [URL="http://www.schmengler-se.de/magento-entwicklung/"]Magento Entwicklung[/URL] - [URL="http://www.css3d.net/"]CSS Ribbon Generator[/URL]

          Kommentar


          • #6
            Erstmal danke für eure Ideen. Folgende Vorgehensweise habe ich mir überlegt:

            Ich habe eine statische Klasse, die sich um die Rechteverwaltung kümmert. Dazu wird ein XML File gelesen, in dem die Rechte definiert sind. Sämtliche Klassen des Frameworks fragen dann bei dieser Klasse nach, ob die Aktion erlaubt ist. Die Config ist ebenfalls nur über eine statische Klasse erreichbar und die sensiblen Daten darin werden über die Rechteklasse geschützt.
            Bevor das Modul jetzt geladen wird, lade ich die modulspezifische XML und setzt über open_basedir den Pfad so um, dass PHP keinen Zugriff mehr auf die XML + Config Files hat.

            Damit kann ich zwar nicht alles verbieten, ich habe aber immerhin schon mal den Zugriff auf die Datenbanken etc. eingeschränkt. An einer zusätzlichen Validierung der Module werde ich damit aber wohl nicht vorbei kommen.

            Nachteil der Methode ist dann aber noch, dass es keinen Rollback für die Einschränkung von open_basedir gibt. Trotzdem ist das Verfahren sehr praktikabel.


            mfg
            Link
            "Ein Script ist nur dann gut, wenn es unabhängig von der verwendeten Plattform funktioniert"

            Kommentar

            Lädt...
            X