Da nun klar umrissen ist, wie die Web Services abzusichern sind, können alle Einzelteile zusammengefügt werden. Zuerst ein Blick auf die Struktur des selbst erstellten SOAP-Headers (Listing E).
Alle selbst erstellten SOAP-Header müssen die SoapHeader-Klasse erben, was die Serialisierung und die Übertragung innerhalb des SOAP-Envelope ermöglicht. Es werden zwei Eigenschaften definiert: ClientId und WSToken, welche die Daten für die Authentifizierung enthalten. Man muss also für jeden zulässigen Benutzer des Web Services gültige Anmeldeinformationen bereitstellen. Zum Beispiel ist Tom’s Books ein gültiger Web Service-Benutzer für John, also würde er Tom mitteilen, wie dessen ClientId und WSToken lauten. Tom würde dann diese Informationen an Johns Web Services in einem eigens erstellten SOAP-Header übermitteln, so dass eine Authentifizierung stattfinden kann.
Man benötigt auch eine allgemeine Methode, um die eigentliche Authentifizierung durchzuführen. Dazu wird zuerst ein separater Ordner für die Web Services erstellt. Dieser separate Ordner ist notwendig, um eine neue Web.config-Datei zu speichern, welche die oben beschriebenen Sicherheitsmaßnahmen festlegt. Diese Sicherheitsmaßnahmen werden nur auf Dateien innerhalb des Web Services-Verzeichnisses angewandt.
Dazu klickt man mit der rechten Maustaste auf die Hauptanwendung WSB2BJohn im Solution-Explorer und fügt einen neuen Ordner namens ws hinzu. Dann klickt man mit der rechten Maustaste auf den neu erstellten Ordner und fügt eine neue Klasse namens WSUtil.vb hinzu, in die man den Code aus Listing F kopiert.
Zur Erstellung der beiden Authentifizierungsmethoden wird eine objektorientierte Technik namens Polymorphie verwendet. Dies erlaubt die Authentifizierung zweier unterschiedlicher Arten von selbst erstellten SOAP-Headern. Da die Authentifizierung bei jedem Aufruf einer Web-Methode erfolgt, kann man sich durch Caching der CLIENT-Tabelle in einer Application-Variablen beim Programmstart einige Datenbankabfragen sparen. Dazu wird der Code aus Listing G dem Ereignis Application_Start in der Datei Global.asax hinzugefügt.
Der Code in Listing G fügt einfach ein DataSet in eine Application-Variable ein, die eine Referenz zu allen gültigen Web Service-Clients enthält. Durch Nachschlagen in diesem DataSet in der Authenticate()-Methode der WebUtil-Klasse kann man feststellen, ob ein bestimmter Benutzer eines Web Service autorisiert ist. Da die CLIENT-Tabelle nur eine Reihe enthält, belastet dieses Verfahren den Server nicht, es entlastet aber die Datenbank.
Mit einem Blick auf die ursprünglichen Anforderungen stellt man fest, dass Web Services für die folgenden Elemente benötigt werden: Order und Book. Man sollte berücksichtigen, dass die Anforderungen von John festlegen, dass nur bestimmte Funktionen für externe Benutzer zugänglich sein sollen, weshalb man nur Zugriff auf die folgenden Funktionen gewähren muss: Create Order, Get Orders und Search Books.
Dazu klickt man mit der rechten Maustaste auf den Ordner ws und fügt zwei Web Services namens OrderWS.asmx (Listing H) und BookWS.asmx (Listing I) hinzu, indem man den Code aus Listing H in den Web Service OrderWS und den Code aus Listing I in den Web Service BookWS kopiert.
Die Hintermänner haben es unter anderem auf Daten von Facebook-Geschäftskonten abgesehen. Opfer werden über angebliche…
Bis 2027 werden 90 Prozent der Unternehmen eine Hybrid-Cloud-Strategie umsetzen.
Apple belegt in der Statistik von Counterpoint die ersten drei Plätze. Samsungs Galaxy S24 schafft…
Kontinuierliche Content Produktion und Markenaufbau sind essentieller Pfeiler von langfristigen Unternehmenserfolg. Das ist mittlerweile auch…
KI-Funktionen beschleunigen die Erholung des PC-Markts. Der Nettogewinn legt um 44 Prozent zu, der Umsatz…
Googles App-Entwickler-Kit dient der Tarnung des schädlichen Codes. Der Sicherheitsanbieter Jamf hält die Schadsoftware für…