PSR-11 ist eine PHP-Standard-Empfehlung (PHP Standard Recommendation), die sich mit der Container-Interface-Definition beschäftigt. Sie beschreibt ein einheitliches Interface für Dependency Injection Container, das in PHP-Projekten verwendet werden kann. Dependency Injection Container sind Werkzeuge, die Klassen und ihre Abhängigkeiten verwalten und auflösen.

Ziel von PSR-11

PSR-11 wurde eingeführt, um sicherzustellen, dass verschiedene Frameworks, Bibliotheken und Tools interoperabel mit Dependency Injection Containern arbeiten können. Durch die Einhaltung dieses Standards wird es möglich, verschiedene Container in einem Projekt zu verwenden, ohne den Code ändern zu müssen.

Kernkomponenten des PSR-11

PSR-11 definiert zwei Interfaces:

1. ContainerInterface

   • Das zentrale Interface, das Methoden bereitstellt, um Abhängigkeiten aus dem Container zu holen.

namespace Psr\Container;

interface ContainerInterface {
    public function get(string $id);
    public function has(string $id): bool;
}

• • get(string $id): Gibt die Instanz (oder den Service) zurück, die im Container unter einer bestimmten ID registriert ist.
  • has(string $id): Prüft, ob der Container eine Instanz mit der angegebenen ID enthält.

• 2. NotFoundExceptionInterface

  • Wird ausgelöst, wenn ein Service nicht im Container gefunden wird.

namespace Psr\Container;

interface NotFoundExceptionInterface extends ContainerExceptionInterface {
}

3. ContainerExceptionInterface

• • Wird für generelle Fehler im Container verwendet.

Vorteile von PSR-11

• Interoperabilität: Verschiedene Frameworks und Bibliotheken können denselben Container nutzen.
• Standardisierung: Einheitliche API für Containerzugriffe.
• Erweiterbarkeit: Entwickler können eigene Container erstellen, die den PSR-11-Spezifikationen entsprechen.

Typischer Anwendungsfall

PSR-11 wird häufig in Frameworks wie Symfony, Laravel, oder Zend Framework (jetzt Laminas) verwendet, die Dependency Injection Container bereitstellen. Auch Tools wie PHP-DI oder Pimple unterstützen PSR-11.

Beispiel

Ein einfaches Beispiel für den Einsatz von PSR-11:

use Psr\Container\ContainerInterface;

class MyService {
    public function __construct(private string $message) {}
    public function greet(): string {
        return $this->message;
    }
}

$container = new SomePSR11CompliantContainer();
$container->set('greeting_service', function() {
    return new MyService('Hello, PSR-11!');
});

if ($container->has('greeting_service')) {
    $service = $container->get('greeting_service');
    echo $service->greet(); // Ausgabe: Hello, PSR-11!
}

Fazit

PSR-11 ist eine wichtige Schnittstelle für modernes PHP-Entwickeln, da sie Abhängigkeiten und deren Auflösung standardisiert. Dies führt zu flexibleren und besser wartbaren Anwendungen.

Dependency Injection (DI) ist ein Entwurfsmuster in der Softwareentwicklung, das darauf abzielt, die Abhängigkeiten zwischen verschiedenen Komponenten eines Systems zu verwalten und zu entkoppeln. Es handelt sich um eine Form der Inversion of Control (IoC), bei der die Steuerung über die Instanziierung und Lebensdauer von Objekten von der Anwendung selbst an einen externen Container oder ein Framework übergeben wird.

Warum Dependency Injection?

Das Hauptziel von Dependency Injection ist es, lose Kopplung und hohe Testbarkeit in Softwareprojekten zu fördern. Indem die Abhängigkeiten einer Komponente explizit von außen bereitgestellt werden, kann der Code einfacher getestet, gewartet und erweitert werden.

Vorteile von Dependency Injection

1. Lose Kopplung: Komponenten sind weniger abhängig von der genauen Implementierung anderer Klassen und können leicht ausgetauscht oder geändert werden.
2. Erhöhte Testbarkeit: Komponenten können leichter in Isolation getestet werden, indem Mock- oder Stub-Objekte verwendet werden, um echte Abhängigkeiten zu simulieren.
3. Wartbarkeit: Der Code wird durch die Trennung von Zuständigkeiten verständlicher und wartbarer.
4. Flexibilität und Wiederverwendbarkeit: Komponenten können wiederverwendet werden, da sie nicht fest an bestimmte Implementierungen gebunden sind.

Grundlegende Konzepte

Es gibt drei Hauptarten von Dependency Injection:

1. Constructor Injection: Abhängigkeiten werden über den Konstruktor einer Klasse bereitgestellt.

public class Car {
    private Engine engine;

    // Dependency wird durch den Konstruktor injiziert
    public Car(Engine engine) {
        this.engine = engine;
    }
}

2. Setter Injection: Abhängigkeiten werden über Setter-Methoden bereitgestellt.

public class Car {
    private Engine engine;

    // Dependency wird durch eine Setter-Methode injiziert
    public void setEngine(Engine engine) {
        this.engine = engine;
    }
}

3. Interface Injection: Abhängigkeiten werden durch ein Interface bereitgestellt, das die Klasse implementiert.

public interface EngineInjector {
    void injectEngine(Car car);
}

public class Car implements EngineInjector {
    private Engine engine;

    @Override
    public void injectEngine(Car car) {
        car.setEngine(new Engine());
    }
}

Beispiel für Dependency Injection

Um das Konzept besser zu veranschaulichen, schauen wir uns ein konkretes Beispiel in Java an.

Klassisches Beispiel ohne Dependency Injection

public class Car {
    private Engine engine;

    public Car() {
        this.engine = new PetrolEngine(); // Feste Kopplung an PetrolEngine
    }

    public void start() {
        engine.start();
    }
}

In diesem Fall ist die Car-Klasse fest an eine bestimmte Implementierung (PetrolEngine) gebunden. Wenn wir den Motor ändern möchten, müssen wir den Code der Car-Klasse anpassen.

Beispiel mit Dependency Injection

public class Car {
    private Engine engine;

    // Constructor Injection
    public Car(Engine engine) {
        this.engine = engine;
    }

    public void start() {
        engine.start();
    }
}

public interface Engine {
    void start();
}

public class PetrolEngine implements Engine {
    @Override
    public void start() {
        System.out.println("Petrol Engine Started");
    }
}

public class ElectricEngine implements Engine {
    @Override
    public void start() {
        System.out.println("Electric Engine Started");
    }
}

Jetzt können wir die Abhängigkeit von Engine zur Laufzeit bereitstellen, was bedeutet, dass wir problemlos zwischen verschiedenen Motorimplementierungen wechseln können:

public class Main {
    public static void main(String[] args) {
        Engine petrolEngine = new PetrolEngine();
        Car carWithPetrolEngine = new Car(petrolEngine);
        carWithPetrolEngine.start();  // Output: Petrol Engine Started

        Engine electricEngine = new ElectricEngine();
        Car carWithElectricEngine = new Car(electricEngine);
        carWithElectricEngine.start();  // Output: Electric Engine Started
    }
}

Frameworks zur Unterstützung von Dependency Injection

Es gibt viele Frameworks und Bibliotheken, die Dependency Injection unterstützen und vereinfachen, wie:

• Spring Framework: Ein weit verbreitetes Java-Framework, das umfangreiche Unterstützung für DI bietet.
• Guice: Ein DI-Framework von Google für Java.
• Dagger: Ein weiteres DI-Framework von Google, oft verwendet in Android-Anwendungen.
• Unity: Ein DI-Container für .NET-Entwicklungen.
• Autofac: Ein populäres DI-Framework für .NET.

Implementierung in verschiedenen Programmiersprachen

Dependency Injection ist nicht auf eine bestimmte Programmiersprache beschränkt und kann in vielen Sprachen implementiert werden. Hier sind einige Beispiele:

C#-Beispiel mit Constructor Injection

public interface IEngine {
    void Start();
}

public class PetrolEngine : IEngine {
    public void Start() {
        Console.WriteLine("Petrol Engine Started");
    }
}

public class ElectricEngine : IEngine {
    public void Start() {
        Console.WriteLine("Electric Engine Started");
    }
}

public class Car {
    private IEngine _engine;

    // Constructor Injection
    public Car(IEngine engine) {
        _engine = engine;
    }

    public void Start() {
        _engine.Start();
    }
}

// Verwendung
IEngine petrolEngine = new PetrolEngine();
Car carWithPetrolEngine = new Car(petrolEngine);
carWithPetrolEngine.Start();  // Output: Petrol Engine Started

IEngine electricEngine = new ElectricEngine();
Car carWithElectricEngine = new Car(electricEngine);
carWithElectricEngine.Start();  // Output: Electric Engine Started

Python-Beispiel mit Constructor Injection

In Python ist Dependency Injection ebenfalls möglich, obwohl es aufgrund der dynamischen Natur der Sprache oft einfacher ist:

class Engine:
    def start(self):
        raise NotImplementedError("Start method must be implemented.")

class PetrolEngine(Engine):
    def start(self):
        print("Petrol Engine Started")

class ElectricEngine(Engine):
    def start(self):
        print("Electric Engine Started")

class Car:
    def __init__(self, engine: Engine):
        self._engine = engine

    def start(self):
        self._engine.start()

# Verwendung
petrol_engine = PetrolEngine()
car_with_petrol_engine = Car(petrol_engine)
car_with_petrol_engine.start()  # Output: Petrol Engine Started

electric_engine = ElectricEngine()
car_with_electric_engine = Car(electric_engine)
car_with_electric_engine.start()  # Output: Electric Engine Started

Fazit

Dependency Injection ist ein mächtiges Entwurfsmuster, das Entwickler dabei unterstützt, flexible, testbare und wartbare Software zu erstellen. Durch die Entkopplung von Komponenten und die Verlagerung der Steuerung über Abhängigkeiten auf ein DI-Framework oder einen DI-Container, wird der Code leichter erweiterbar und verständlich. Es ist ein zentrales Konzept in der modernen Softwareentwicklung und ein wichtiges Werkzeug für jeden Entwickler.

Inversion of Control (IoC) ist ein Konzept in der Softwareentwicklung, das sich auf die Steuerung der Flussrichtung eines Programms bezieht. Anstatt dass der Code selbst die Kontrolle über den Ablauf und die Instanziierung von Abhängigkeiten übernimmt, wird diese Kontrolle an ein Framework oder einen Container übergeben. Dies erleichtert die Entkopplung von Komponenten und fördert eine höhere Modularität und Testbarkeit des Codes.

Hier sind einige Schlüsselkonzepte und -prinzipien von IoC:

1. Abhängigkeitsinjektion (Dependency Injection): Eine der häufigsten Implementierungen von IoC. Bei der Abhängigkeitsinjektion wird eine Komponente nicht selbst instanziiert, sondern sie erhält ihre Abhängigkeiten vom IoC-Container. Es gibt drei Hauptarten der Injektion:

   • Konstruktorinjektion: Abhängigkeiten werden über den Konstruktor einer Klasse übergeben.
   • Setter-Injektion: Abhängigkeiten werden über Setter-Methoden übergeben.
   • Interface-Injektion: Eine Schnittstelle definiert Methoden zur Übergabe der Abhängigkeiten.

2. Ereignisgesteuerte Programmierung (Event-driven Programming): Hierbei wird der Ablauf eines Programms durch Ereignisse gesteuert, die von einem Framework oder einem Event-Manager verwaltet werden. Anstatt dass der Code selbst entscheidet, wann bestimmte Aktionen ausgeführt werden, reagiert er auf Ereignisse, die von einem externen Steuerungssystem ausgelöst werden.

3. Service Locator Pattern: Ein weiteres Muster zur Implementierung von IoC. Ein Service-Locator bietet eine zentrale Stelle, an der Abhängigkeiten aufgelöst werden können. Klassen fragen den Service-Locator nach den benötigten Abhängigkeiten an, anstatt sie selbst zu erstellen.

4. Aspektorientierte Programmierung (AOP): Hierbei wird die Querschnittsfunktionalität (wie Logging, Transaktionsmanagement) aus dem Hauptanwendungscode herausgenommen und in separate Module (Aspekte) ausgelagert. Der IoC-Container kümmert sich um die Einbindung dieser Aspekte in den Anwendungscode.

Vorteile von IoC:

• Entkopplung: Komponenten sind weniger stark miteinander verbunden, was die Wartbarkeit und Erweiterbarkeit des Codes verbessert.
• Testbarkeit: Es wird einfacher, Unit-Tests zu schreiben, da Abhängigkeiten leicht durch Mock-Objekte ersetzt werden können.
• Wiederverwendbarkeit: Komponenten können einfacher in verschiedenen Kontexten wiederverwendet werden.

Ein Beispiel für IoC ist das Spring Framework in Java, das einen IoC-Container bietet, der die Abhängigkeiten der Komponenten verwaltet und injiziert.

Server Side Includes (SSI) sind eine Technik, die es ermöglicht, HTML-Dokumente serverseitig dynamisch zu generieren. SSI verwendet spezielle Befehle, die in HTML-Kommentare eingebettet werden. Diese Befehle werden vom Webserver interpretiert und ausgeführt, bevor die Seite an den Browser des Benutzers gesendet wird.

Funktionen und Anwendungen von SSI:

1. Einfügen von Inhalten: SSI ermöglicht das Einfügen von Inhalten aus anderen Dateien oder dynamischen Quellen in eine HTML-Seite. Zum Beispiel kann man eine Kopf- oder Fußzeile in mehreren Seiten wiederverwenden, indem man sie in eine separate Datei auslagert und diese Datei mittels SSI einfügt.
   

Server Side Includes (SSI) Injection ist eine Sicherheitslücke, die in Webanwendungen auftritt, die Server Side Includes (SSI) verwenden. SSI ist eine Technik, die es ermöglicht, HTML-Dateien serverseitig dynamisch zu generieren, indem spezielle Befehle in HTML-Kommentaren eingebettet werden. Diese Befehle werden vom Webserver interpretiert und ausgeführt, bevor die Seite an den Client ausgeliefert wird.

Wie funktioniert SSI Injection?

Bei einer SSI Injection greift ein Angreifer die Webanwendung an, indem er bösartige SSI-Befehle in Eingabefelder, URLs oder andere Mechanismen einschleust, über die die Anwendung Daten vom Benutzer akzeptiert. Wenn die Anwendung diese Eingaben nicht richtig überprüft und filtert, können die eingeschleusten Befehle auf dem Server ausgeführt werden.

Beispiel eines SSI-Befehls:

Dieser Befehl würde auf einem anfälligen Server den Inhalt des aktuellen Verzeichnisses auflisten.

Mögliche Auswirkungen einer SSI Injection:

• Dateisystemmanipulation: Angreifer können Dateien lesen, ändern oder löschen.
• Remote Code Execution: Ausführung beliebiger Befehle auf dem Server, was zu einer vollständigen Kompromittierung führen kann.
• Informationsdiebstahl: Zugriff auf sensible Daten, wie Konfigurationsdateien oder Datenbankinhalte.
• Dienstunterbrechung: Durchführen von Befehlen, die den Server zum Absturz bringen oder überlasten.

Schutzmaßnahmen gegen SSI Injection:

1. Eingaben validieren und filtern: Alle Benutzereingaben sollten gründlich überprüft und auf zulässige Werte beschränkt werden.
2. Verwendung von Prepared Statements: Wo möglich, sollte man vorbereitete Anweisungen und parameterisierte Abfragen verwenden, um die Möglichkeit von Injektionen zu minimieren.
3. Beschränkung der Nutzung von SSI: Wenn möglich, sollte die Verwendung von SSI ganz vermieden werden, insbesondere wenn es keine zwingende Notwendigkeit dafür gibt.
4. Sicherheitsmechanismen des Servers nutzen: Konfigurieren Sie den Webserver so, dass er nur vertrauenswürdige SSI-Befehle akzeptiert und führt keine gefährlichen Shell-Befehle aus.

Indem diese Maßnahmen ergriffen werden, kann das Risiko einer SSI Injection erheblich reduziert werden.