Request obfuscation

The contents of the entire modifiers part of request string, including the optional lock suffix may be obscured by applying standard base64 encoding.

The server attempts to decode if attribute::RequestObfuscation is set. If decoding fails, the request is rejected. If both request locking and request obfuscation are applied, the lock suffix must be generated and appended before base64 encoding.

IMPORTANT

If you enable this feature, be aware that there are certain limitations to its use that include the following:
- The Dynamic Media user interface may not show the correct details for the Last Published field. However, this affect does not impact publishing.
- Currently, HLS video streaming does not work when Request obfuscation and Request locking are enabled.
- Currently, some Dynamic Media Viewers do not work when Request obfuscation and Request locking are enabled.

Example

http://server/myTemplate?$txt=my text string&$img=myImage

encodes to:

http://server/myTemplate?dHh0PW15IHRleHQgc3RyaW5nJiRpbWc9bXlJbWFnZQ==

Any occurrences of ‘=’, ‘&’, and ‘%’ in value strings must be escaped using ‘%xx’ encoding, before the request is obfuscated. It is not necessary to otherwise http-encode the modifiers part of the request either before or after obfuscation, even if request locking is applied, since base64 encoding is safe for http transmission.

View next:

A virtual event April 27-28.

Expand your skills and get inspired.

Privacy (UPDATED)

Request obfuscation

Example

See also

Resources on adobe.com

On this page

View next: