User id watermark while viewing assets and download

Hi ​@Jangra98 

For rendering a watermark while users are viewing the asset, this can be achieved either through a frontend overlay approach (CSS/JS) or by leveraging Dynamic Media capabilities, if enabled.

However for downloads, I would recommend a more controlled approach—rerouting all download requests through a custom Sling Servlet. This servlet can dynamically apply the user-specific watermark and stream the modified asset back to the user, ensuring better security and traceability.

​@Jangra98, the right answer depends a lot on which delivery path you are watermarking and which AEM flavor you are on. A few quick clarifiers will narrow it down.

• Are you watermarking previews inside the AEM admin UI, an external preview portal (Asset Share Commons, custom React app), Content Hub, or direct delivery URLs to end users?
• Is this AEMaaCS, AEM 6.5, or AMS, and do you have Dynamic Media in play?
• Is the goal deterrent (something like visible "Name @ Org" overlay) or forensic (invisible traceable mark for leak attribution)?

Assuming visible deterrent watermarks on view and download, here is how I would approach it:

1. View-time with Dynamic Media. -> Inject the user identity into the Image Serving URL and let Dynamic Media composite the text on the served image. No native imaging libs needed on the AEM side. Use the text, textPs, and textAttr modifiers on the rendition URL to control content, position, and font styling. Generate the URL on the server in the servlet or component, do not let the client construct the text parameter, otherwise the user can spoof it.
2. Download-time on AEMaaCS. -> You cannot ship native imaging libs like ImageMagick to the cloud runtime. Practical options are Dynamic Media renditions with the text overlay at request time, an App Builder action that proxies through an external imaging service, or a Sling servlet that streams the original through a watermark microservice and writes the response with Cache-Control private no-store and a sensible Content-Disposition. Avoid generating one rendition per user and storing it in the DAM, it does not scale and pollutes the asset tree.

Caching gotcha is that Dispatcher and the CDN cache by URL. A per-user watermark URL must be non-cacheable, or user A will see user B's watermark on a cached response. Mark the URL pattern as a deny rule in the dispatcher cache section, and apply the same non-cacheable rule on the CDN. Also strip the watermark URL pattern from any auto warming cache jobs that you may run.

If compliance is the motivation for this implementation, the watermark is half the answer. Pair it with a download audit log that captures who, what, when, which version, and which watermark token. Otherwise you can see the leak but cannot trace it.

If the use case is closer to controlled distribution to external parties, the DRM Request feature through Content Hub and Workfront just landed and is a closer fit than rolling watermarks yourself. There is a recent blog on it on this same board