19-10-2024, 03:12
Wenn du mit Webanwendungen arbeitest, wirst du möglicherweise auf das CORS-Problem stoßen, insbesondere wenn du versuchst, Ressourcen von einer anderen Domain abzurufen. Ich war schon dort, und es kann ziemlich nervig sein, wenn die Dinge nicht so funktionieren, wie du es erwartest. Also lass uns durchgehen, wie man CORS in IIS konfiguriert. Vertrau mir; sobald du den Dreh raus hast, ist es gar nicht so abschreckend.
Zuerst musst du Zugriff auf den Server haben, auf dem IIS läuft. Egal, ob du auf einem lokalen Computer oder einem Remote-Server arbeitest, stelle sicher, dass du die richtigen Berechtigungen hast, um Änderungen vorzunehmen. Ich verbinde mich normalerweise über das Remote-Desktop-Protokoll, wenn ich nicht auf der physischen Maschine bin. Das gibt mir vollen Zugriff auf alles, was ich benötige.
Sobald du eingeloggt bist, öffne den IIS-Manager. Es ist ziemlich einfach: Suche einfach nach dem Symbol im Startmenü, und du wirst es ohne viel Aufwand finden. Wenn der IIS-Manager geöffnet ist, siehst du deinen Server im linken Bereich aufgeführt. Klicke darauf, um die auf diesem Server gehosteten Websites zu sehen.
Nimm dir einen Moment Zeit, um herauszufinden, für welche Website du CORS aktivieren möchtest. Aus meiner Erfahrung ist es oft am besten, diese Änderungen auf einer bestimmten Website vorzunehmen, anstatt global, insbesondere wenn du dir nicht sicher bist, wie sich deine Änderungen auf andere Anwendungen auswirken. Klicke also auf die Website, und du wirst die Funktionsansicht gleich in der Mitte bemerken.
Hier musst du dich auf die HTTP-Antwortheader-Funktion konzentrieren. Wenn du sie nicht in der Liste siehst, keine Sorge. Manchmal kann sie unter den anderen Funktionen verborgen sein. Wenn sie fehlt, musst du die Funktion möglicherweise über deinen Server-Manager installieren, aber wahrscheinlich wird sie direkt dort sein.
Klicke nun auf die HTTP-Antwortheader, und wenn du zum richtigen Bildschirm gelangst, wirst du nach "Hinzufügen" im Aktionsbereich auf der rechten Seite suchen. Wenn du darauf klickst, erscheint ein Popup, und hier gibst du die Informationen ein. Du fragst dich vielleicht, was du eingeben sollst, also lass mich das ein wenig für dich aufschlüsseln.
Zunächst musst du einen Header mit dem Namen "Access-Control-Allow-Origin" hinzufügen. Hier gibst du an, welche Domains berechtigt sind, Ressourcen von deiner Website abzurufen. Wenn du nur eine bestimmte Domain zulassen möchtest, gibst du diese Domain hier ein und achtest darauf, das Protokoll anzugeben, wie http:// oder https://. Wenn du beispielsweise Anfragen von "http://example.com" zulassen möchtest, gibst du diesen Wert einfach ein.
Wenn du entwickelst und mehrere Domains oder sogar jede Domain zu Testzwecken zulassen musst, kannst du das Platzhalterzeichen "*" verwenden. Aber sei vorsichtig damit. Auch wenn es verlockend sein mag, '*' zu setzen, nur um die Dinge zum Laufen zu bringen, kann dies deine Anwendung Risiken bei plattformübergreifenden Anfragen aussetzen. Wenn Sicherheit während der Entwicklung kein primäres Anliegen ist, mach ruhig. Aber sobald du deine Anwendung live schaltest, ist es immer am besten, spezifische Domains anzugeben, die auf deine Ressourcen zugreifen dürfen.
Nachdem du den Namen und den Wert für den Header eingegeben hast, klicke auf OK, um ihn zu speichern. Du solltest jetzt sehen, dass der Header in den Antwortheadern aufgeführt ist. Aber CORS dreht sich nicht nur um diesen einen Header; es gibt andere Header, die je nach Funktion deiner Anwendung berücksichtigt werden müssen.
Wenn deine Anwendung beispielsweise Anfragen stellt, die Anmeldeinformationen benötigen, wie Cookies oder HTTP-Authentifizierung, musst du auch einen anderen Header namens "Access-Control-Allow-Credentials" hinzufügen. Setze den Wert auf true. Das ist entscheidend, um sicherzustellen, dass deine Anwendung korrekt funktioniert, wenn sie auf Ressourcen zugreift, die eine Authentifizierung über verschiedene Ursprünge hinweg erfordern.
Wenn du es mit komplizierten Anfragen zu tun hast, wie solchen, die die PUT- oder DELETE-Methoden verwenden, möchtest du diese Methoden ebenfalls zulassen. Das kannst du tun, indem du den Header "Access-Control-Allow-Methods" hinzufügst. Hier kannst du die Methoden auflisten, die du erlauben möchtest, wie GET, POST, PUT und DELETE. Trenne sie einfach durch Kommas.
Ähnlich, wenn deine Anwendung spezifische benutzerdefinierte Header sendet, musst du dem Server ebenfalls mitteilen, dass diese erlaubt sind. Du machst das mit "Access-Control-Allow-Headers". Wenn du beispielsweise einen Header wie "X-Custom-Header" sendest, füge ihn in den Wert ein, wobei du wieder mehrere Header durch Kommas trennen kannst.
Jetzt, während alles bisher reibungslos zu sein scheint, vergiss nicht zu überprüfen, ob deine Anwendung OPTIONS-Anfragen benötigt. Dies wird typischerweise in einem Preflight-Anfrage-Szenario verwendet. Wenn deine Anwendung solche macht, möchtest du sicherstellen, dass der Server entsprechend antwortet. Stelle dazu sicher, dass dein Server so konfiguriert ist, dass er OPTIONS-Anfragen korrekt behandelt.
Nachdem du all diese Änderungen vorgenommen hast, möchtest du normalerweise deine IIS-Website neu starten, um sicherzustellen, dass alle Änderungen wirksam werden. Klicke einfach mit der rechten Maustaste auf deine Website im IIS-Manager und wähle "Neu starten". Dies ist normalerweise der letzte Feinschliff, aber es ist eine gute Praxis, den Ereignisanzeige oder deine Anwendungsprotokolle danach zu überprüfen. Manchmal können die Protokolle ziemlich aufschlussreich sein, wenn etwas nicht wie erwartet funktioniert.
Es kann auch hilfreich sein, deine CORS-Konfiguration direkt zu testen. Du kannst Tools wie Postman oder sogar die Entwicklertools deines Browsers verwenden. Öffne den Netzwerk-Tab, mache Anfragen an deine API und überprüfe die Antwortheader. Du möchtest deine Access-Control-Header dort sehen. Wenn etwas nicht sichtbar ist, weißt du, dass du zurückgehen und deine Konfigurationen überprüfen musst.
Denk daran, dass das CORS-Verhalten je nach Art und Weise, wie die Anfragen gestellt werden, welche Header enthalten sind und ob Anmeldeinformationen involviert sind, variieren kann. Wenn du feststellst, dass einige Konfigurationen nicht wirksam werden, überprüfe die gesendeten Anfragen nochmals.
Angenommen, du hast auf der Client-Seite Herausforderungen, und du schaust dir an, wie du dein JavaScript anpassen kannst, um CORS richtig zu handhaben. Beim Senden von Anfragen mit fetch oder XMLHttpRequest hast du diese Optionen, um anzupassen, wie die Anfrage gesendet wird. Du kannst beispielsweise angeben, ob die Anfrage Anmeldeinformationen enthält, indem du credentials: 'include' in deinen fetch-Optionen setzt - dies muss zu deinen IIS-Einstellungen passen, die du gerade konfiguriert hast.
Zusammenfassend lässt sich sagen, dass es schnell zur zweiten Natur wird, wenn du anfängst, an CORS-Einstellungen zu arbeiten. Du siehst, wie sie mit den Anfragen deiner Anwendungen verbunden sind, und kannst die Einstellungen je nach deinen spezifischen Anwendungsfällen feinabstimmen.
Mit diesen Tipps zur Konfiguration von CORS in IIS solltest du gut gerüstet sein, um plattformübergreifende Anfragen zu verwalten, ohne dir die Haare raufen zu müssen. Wenn du diesen Schritten folgst und ein Auge auf deine Protokolle hast, solltest du eine reibungslose Erfahrung beim Einrichten der Dinge haben, wie du es benötigst. Denk einfach daran, dass mit Macht auch Verantwortung einhergeht. Sei vorsichtig, wie großzügig du den Zugriff auf deine Ressourcen erlaubst, insbesondere in einer Produktionsumgebung.
Ich hoffe, du fandest meinen Beitrag nützlich. Übrigens, hast du eine gute Backup-Lösung für Windows Server in Betrieb? In diesem Beitrag erkläre ich, wie man Windows Server richtig sichert.
Zuerst musst du Zugriff auf den Server haben, auf dem IIS läuft. Egal, ob du auf einem lokalen Computer oder einem Remote-Server arbeitest, stelle sicher, dass du die richtigen Berechtigungen hast, um Änderungen vorzunehmen. Ich verbinde mich normalerweise über das Remote-Desktop-Protokoll, wenn ich nicht auf der physischen Maschine bin. Das gibt mir vollen Zugriff auf alles, was ich benötige.
Sobald du eingeloggt bist, öffne den IIS-Manager. Es ist ziemlich einfach: Suche einfach nach dem Symbol im Startmenü, und du wirst es ohne viel Aufwand finden. Wenn der IIS-Manager geöffnet ist, siehst du deinen Server im linken Bereich aufgeführt. Klicke darauf, um die auf diesem Server gehosteten Websites zu sehen.
Nimm dir einen Moment Zeit, um herauszufinden, für welche Website du CORS aktivieren möchtest. Aus meiner Erfahrung ist es oft am besten, diese Änderungen auf einer bestimmten Website vorzunehmen, anstatt global, insbesondere wenn du dir nicht sicher bist, wie sich deine Änderungen auf andere Anwendungen auswirken. Klicke also auf die Website, und du wirst die Funktionsansicht gleich in der Mitte bemerken.
Hier musst du dich auf die HTTP-Antwortheader-Funktion konzentrieren. Wenn du sie nicht in der Liste siehst, keine Sorge. Manchmal kann sie unter den anderen Funktionen verborgen sein. Wenn sie fehlt, musst du die Funktion möglicherweise über deinen Server-Manager installieren, aber wahrscheinlich wird sie direkt dort sein.
Klicke nun auf die HTTP-Antwortheader, und wenn du zum richtigen Bildschirm gelangst, wirst du nach "Hinzufügen" im Aktionsbereich auf der rechten Seite suchen. Wenn du darauf klickst, erscheint ein Popup, und hier gibst du die Informationen ein. Du fragst dich vielleicht, was du eingeben sollst, also lass mich das ein wenig für dich aufschlüsseln.
Zunächst musst du einen Header mit dem Namen "Access-Control-Allow-Origin" hinzufügen. Hier gibst du an, welche Domains berechtigt sind, Ressourcen von deiner Website abzurufen. Wenn du nur eine bestimmte Domain zulassen möchtest, gibst du diese Domain hier ein und achtest darauf, das Protokoll anzugeben, wie http:// oder https://. Wenn du beispielsweise Anfragen von "http://example.com" zulassen möchtest, gibst du diesen Wert einfach ein.
Wenn du entwickelst und mehrere Domains oder sogar jede Domain zu Testzwecken zulassen musst, kannst du das Platzhalterzeichen "*" verwenden. Aber sei vorsichtig damit. Auch wenn es verlockend sein mag, '*' zu setzen, nur um die Dinge zum Laufen zu bringen, kann dies deine Anwendung Risiken bei plattformübergreifenden Anfragen aussetzen. Wenn Sicherheit während der Entwicklung kein primäres Anliegen ist, mach ruhig. Aber sobald du deine Anwendung live schaltest, ist es immer am besten, spezifische Domains anzugeben, die auf deine Ressourcen zugreifen dürfen.
Nachdem du den Namen und den Wert für den Header eingegeben hast, klicke auf OK, um ihn zu speichern. Du solltest jetzt sehen, dass der Header in den Antwortheadern aufgeführt ist. Aber CORS dreht sich nicht nur um diesen einen Header; es gibt andere Header, die je nach Funktion deiner Anwendung berücksichtigt werden müssen.
Wenn deine Anwendung beispielsweise Anfragen stellt, die Anmeldeinformationen benötigen, wie Cookies oder HTTP-Authentifizierung, musst du auch einen anderen Header namens "Access-Control-Allow-Credentials" hinzufügen. Setze den Wert auf true. Das ist entscheidend, um sicherzustellen, dass deine Anwendung korrekt funktioniert, wenn sie auf Ressourcen zugreift, die eine Authentifizierung über verschiedene Ursprünge hinweg erfordern.
Wenn du es mit komplizierten Anfragen zu tun hast, wie solchen, die die PUT- oder DELETE-Methoden verwenden, möchtest du diese Methoden ebenfalls zulassen. Das kannst du tun, indem du den Header "Access-Control-Allow-Methods" hinzufügst. Hier kannst du die Methoden auflisten, die du erlauben möchtest, wie GET, POST, PUT und DELETE. Trenne sie einfach durch Kommas.
Ähnlich, wenn deine Anwendung spezifische benutzerdefinierte Header sendet, musst du dem Server ebenfalls mitteilen, dass diese erlaubt sind. Du machst das mit "Access-Control-Allow-Headers". Wenn du beispielsweise einen Header wie "X-Custom-Header" sendest, füge ihn in den Wert ein, wobei du wieder mehrere Header durch Kommas trennen kannst.
Jetzt, während alles bisher reibungslos zu sein scheint, vergiss nicht zu überprüfen, ob deine Anwendung OPTIONS-Anfragen benötigt. Dies wird typischerweise in einem Preflight-Anfrage-Szenario verwendet. Wenn deine Anwendung solche macht, möchtest du sicherstellen, dass der Server entsprechend antwortet. Stelle dazu sicher, dass dein Server so konfiguriert ist, dass er OPTIONS-Anfragen korrekt behandelt.
Nachdem du all diese Änderungen vorgenommen hast, möchtest du normalerweise deine IIS-Website neu starten, um sicherzustellen, dass alle Änderungen wirksam werden. Klicke einfach mit der rechten Maustaste auf deine Website im IIS-Manager und wähle "Neu starten". Dies ist normalerweise der letzte Feinschliff, aber es ist eine gute Praxis, den Ereignisanzeige oder deine Anwendungsprotokolle danach zu überprüfen. Manchmal können die Protokolle ziemlich aufschlussreich sein, wenn etwas nicht wie erwartet funktioniert.
Es kann auch hilfreich sein, deine CORS-Konfiguration direkt zu testen. Du kannst Tools wie Postman oder sogar die Entwicklertools deines Browsers verwenden. Öffne den Netzwerk-Tab, mache Anfragen an deine API und überprüfe die Antwortheader. Du möchtest deine Access-Control-Header dort sehen. Wenn etwas nicht sichtbar ist, weißt du, dass du zurückgehen und deine Konfigurationen überprüfen musst.
Denk daran, dass das CORS-Verhalten je nach Art und Weise, wie die Anfragen gestellt werden, welche Header enthalten sind und ob Anmeldeinformationen involviert sind, variieren kann. Wenn du feststellst, dass einige Konfigurationen nicht wirksam werden, überprüfe die gesendeten Anfragen nochmals.
Angenommen, du hast auf der Client-Seite Herausforderungen, und du schaust dir an, wie du dein JavaScript anpassen kannst, um CORS richtig zu handhaben. Beim Senden von Anfragen mit fetch oder XMLHttpRequest hast du diese Optionen, um anzupassen, wie die Anfrage gesendet wird. Du kannst beispielsweise angeben, ob die Anfrage Anmeldeinformationen enthält, indem du credentials: 'include' in deinen fetch-Optionen setzt - dies muss zu deinen IIS-Einstellungen passen, die du gerade konfiguriert hast.
Zusammenfassend lässt sich sagen, dass es schnell zur zweiten Natur wird, wenn du anfängst, an CORS-Einstellungen zu arbeiten. Du siehst, wie sie mit den Anfragen deiner Anwendungen verbunden sind, und kannst die Einstellungen je nach deinen spezifischen Anwendungsfällen feinabstimmen.
Mit diesen Tipps zur Konfiguration von CORS in IIS solltest du gut gerüstet sein, um plattformübergreifende Anfragen zu verwalten, ohne dir die Haare raufen zu müssen. Wenn du diesen Schritten folgst und ein Auge auf deine Protokolle hast, solltest du eine reibungslose Erfahrung beim Einrichten der Dinge haben, wie du es benötigst. Denk einfach daran, dass mit Macht auch Verantwortung einhergeht. Sei vorsichtig, wie großzügig du den Zugriff auf deine Ressourcen erlaubst, insbesondere in einer Produktionsumgebung.
Ich hoffe, du fandest meinen Beitrag nützlich. Übrigens, hast du eine gute Backup-Lösung für Windows Server in Betrieb? In diesem Beitrag erkläre ich, wie man Windows Server richtig sichert.
