© Excellent backgrounds/Shutterstock.com
HTTP Basic Authentication Custom Scope für RESTful Web Services

Out of Scope


Das korrekte Funktionieren von Scopes in CDI setzt bestimmte Rahmenbedingungen voraus. So werden mit @SessionScoped annotierte Beans bei einem HTTP-Request über die mitgesendete JSESSIONID identifiziert und können deshalb über mehrere Requests hinweg eindeutig einem Client zugeordnet werden. Doch was passiert in einer Umgebung, in der die Existenz der JSESSIONID nicht garantiert ist, aber dennoch Sessions benötigt werden? Dieser Artikel beschreibt, wie mithilfe eines Custom Scopes und mit HTTP Basic Access Authentication ein zu @SessionScoped äquivalentes Verhalten auch ohne Nutzung der JSESSIONID erreicht werden kann.

Die Zuordnung von CDI Beans zu einem bestimmten Kontext ist ein wesentliches Erfolgskonzept des Frameworks. Dabei reicht die Verwendung der standardmäßig mitgelieferten Scopes für die Erzeugung und Zerstörung von Objekten durch den jeweiligen CDI-Container in den meisten Fällen vollkommen aus. Allein die Verwendung von @ConversationScoped, in der die Lebensdauer einer mit diesem Scope annotierten Bean programmatisch zur Laufzeit gesteuert werden kann, sollte eine Vielzahl von speziellen Anwendungsfällen abdecken. Eine Limitation der Standard-Scopes von CDI liegt deshalb eher in der technischen Umsetzung als in den fachlich abbildbaren Anwendungsfällen.

Unter der Haube

Die mitgelieferten Standard-Scopes orientieren sich an den in Webanwendungen verwendeten Lebensdauern von Objekten [1]. Beispielsweise lebt eine mit @RequestScoped annotierte Bean für die Dauer eines HTTP-Requests, eine mit @SessionScoped annotierte Bean für die Dauer von mehreren HTTP-Requests. Dementsprechend verwenden die Scopes für die konkrete technische Umsetzung auch Mechanismen, die aus der Servlet-Spezifikation stammen [2]. Schaut man sich beispielsweise die Umsetzung des @SessionScoped-Kontexts genauer an, wird man feststellen, dass hier eine HttpSession für das temporäre Speichern der entsprechend annotierten Bean-Instanzen zum Einsatz kommt. Zusätzlich werden Serlvet Listener und Filter dazu verwendet, die Zuordnung eines Kontexts zur richtigen Bean-Instanz zu Beginn eines HTTP-Requests vorzunehmen.

Dieses Vorgehen setzt voraus, dass der Client – bei Webanwendungen wird dies in den meisten Fällen ein Browser sein – bei jedem Request eine Identifikation mitsendet, die der Server für die Zuordnung der entsprechenden Bean-Instanzen verwendet. Diese künstliche Session-ID wird im Servlet-Kontext durch die JSESSION­ID repräsentiert und ist entweder als Cookie hinterlegt...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang