Der Inhalt des gesamten Modifikatorteils der Anforderungszeichenfolge, einschließlich des optionalen Suffixes für die Sperre, kann durch Anwendung der standardmäßigen Base64-Kodierung verdeckt werden.
Der Server versucht zu dekodieren, ob attribute::RequestObfuscation
festgelegt ist. Wenn die Dekodierung fehlschlägt, wird die Anfrage abgelehnt. Wenn sowohl die Sperrung von Anforderungen als auch die Verschleierung von Anforderungen angewendet werden, muss das Suffix "Sperren"vor der Base64-Kodierung generiert und angehängt werden.
Wenn Sie diese Funktion aktivieren, beachten Sie, dass die Verwendung dieser Funktion gewissen Einschränkungen unterliegt, darunter:
- Die Dynamic Media-Benutzeroberfläche zeigt möglicherweise nicht die richtigen Details für das Feld Zuletzt veröffentlicht an. Dies wirkt sich jedoch nicht auf die Veröffentlichung aus.
- Derzeit funktioniert das HLS-Video-Streaming nicht, wenn die Verschleierung von Anfragen und die Sperrung von Anfragen aktiviert sind.
- Derzeit funktionieren einige Dynamic Media-Viewer nicht, wenn die Verschleierung von Anfragen und die Sperrung von Anfragen aktiviert sind.
http://server/myTemplate?$txt=my text string&$img=myImage
kodiert in:
http://server/myTemplate?dHh0PW15IHRleHQgc3RyaW5nJiRpbWc9bXlJbWFnZQ==
Alle Vorkommen von '=', '&' und '%' in Wertzeichenfolgen müssen mit '%xx'-Kodierung maskiert werden, bevor die Anfrage verschleiert wird. Es ist nicht erforderlich, den Modifikator-Teil der Anforderung entweder vor oder nach der Verschleierung durch HTTP zu kodieren, selbst wenn die Anforderungssperrung angewendet wird, da die Base64-Kodierung für die HTTP-Übertragung sicher ist.
HTTP-Kodierung, Anforderungssperrung, Attribut::RequestObfuscation