Hello,
We have a business requirement to host static webpages from AEM. Our AEM version is the latest AEM as a Cloud Service - 6.5.
We need to host a project folder, containing multiple HTML files, javascript, and style files. When we access the URL to the index.html file in dam, the browser downloads the HTML file, instead of rendering it on the screen.
We have tried to:
1) unchecked "Enable For All Resource Paths" option in the Apache Sling Content Disposition Filter;
2) removed the blacklisted "html/text" configuration.
Has anyone found a workaround to hosting and rendering static HTML pages in dam?
Any help is appreciated.
Solved! Go to Solution.
Views
Replies
Total Likes
Hi @kbsniquer
To address the issue of hosting and rendering static HTML pages directly from DAM in AEM as a Cloud Service, you can follow these steps:
Configure MIME Type: Check and ensure that the MIME type for HTML files is configured to allow rendering. Navigate to the OSGi configuration console (/system/console/configMgr) and review the MIME type mappings.
Update Content Disposition Filter: Adjust the Content Disposition Filter to handle HTML files appropriately. You can do this by modifying the configuration for the Apache Sling Content Disposition Filter. Ensure that the filter allows rendering HTML files.
Use Custom Sling Mapping: Consider creating a custom Sling mapping to handle the rendering of HTML files. This involves creating a servlet that serves HTML content directly. Below is an example of a simple servlet:
@SlingServlet(paths = "/content/dam/project/html", extensions = "html", methods = "GET")
public class HtmlServlet extends SlingSafeMethodsServlet {
@Override
protected void doGet(SlingHttpServletRequest request, SlingHttpServletResponse response) throws ServletException, IOException {
// Get the path of the requested HTML file
String path = request.getRequestPathInfo().getResourcePath();
// Read the content of the HTML file from DAM
InputStream htmlStream = request.getResource().adaptTo(InputStream.class);
// Set the content type
response.setContentType("text/html");
// Copy the content to the response
IOUtils.copy(htmlStream, response.getOutputStream());
}
}
Dispatcher Configuration: If you are using the AEM Dispatcher, check its configuration to ensure that HTML files are not being cached or treated differently. Adjust the dispatcher configurations if needed.
Hi @kbsniquer
The issue could be with the mime type or content-disposible-header.
Can you try with curl and check the response headers?
Hi @kbsniquer
To address the issue of hosting and rendering static HTML pages directly from DAM in AEM as a Cloud Service, you can follow these steps:
Configure MIME Type: Check and ensure that the MIME type for HTML files is configured to allow rendering. Navigate to the OSGi configuration console (/system/console/configMgr) and review the MIME type mappings.
Update Content Disposition Filter: Adjust the Content Disposition Filter to handle HTML files appropriately. You can do this by modifying the configuration for the Apache Sling Content Disposition Filter. Ensure that the filter allows rendering HTML files.
Use Custom Sling Mapping: Consider creating a custom Sling mapping to handle the rendering of HTML files. This involves creating a servlet that serves HTML content directly. Below is an example of a simple servlet:
@SlingServlet(paths = "/content/dam/project/html", extensions = "html", methods = "GET")
public class HtmlServlet extends SlingSafeMethodsServlet {
@Override
protected void doGet(SlingHttpServletRequest request, SlingHttpServletResponse response) throws ServletException, IOException {
// Get the path of the requested HTML file
String path = request.getRequestPathInfo().getResourcePath();
// Read the content of the HTML file from DAM
InputStream htmlStream = request.getResource().adaptTo(InputStream.class);
// Set the content type
response.setContentType("text/html");
// Copy the content to the response
IOUtils.copy(htmlStream, response.getOutputStream());
}
}
Dispatcher Configuration: If you are using the AEM Dispatcher, check its configuration to ensure that HTML files are not being cached or treated differently. Adjust the dispatcher configurations if needed.
Hi partyush,
Thanks for the response
I did create a servlet but when I am clicking on URL:
http://localhost:4502/content/dam/html-content/test.html
nothing is happening and it seems it is not going in servelt code
servelt is not reachable
Here is my code:
Views
Replies
Total Likes
Hi @kbsniquer!
While serving HTML files from DAM is certainly possible, this is not a common use case.
Please be aware that serving HTML files directly from DAM might have several implications, including security concerns. Can you make sure that uploaded HTML files are always trustworthy, conform to your corporate UI and other guidelines for publications and that they don't introduce security vulnerabilities that might affect the whole website/platform? Allowing content authors to upload any HTML file basically circumvents the whole quality assurance cycle that is built around AEM (and potentially Cloud Manager, etc.). You would have to implement a business workflows to ensure that uploaded files have been checked, tested, validated and - if needed - sanitized before they are published.
That being said, you seem to have gotten pretty far already by changing the relevant configurations. Please be aware, that you are circumventing/weakening built-in security measures that have been put into place for reasons (see above).
I'd recommend to double check on the use case and if this approach is the best option to solve it based on the background I have shared.
Depending on the business requirements, it could be an option to host the static HTML files directly on the webserver / dispatcher instead.
If you still want to proceed with the approach of serving HTML files from DAM, you would need to set correct response headers for these files. This could happen on AEM side but might cause unexpected side-effects. It's probably easier to set/overwrite the required HTTP headers on dispatcher level. Any rule to set desired HTTP headers should be restricted as much as possible in terms of requests they apply to to avoid side effects (e. g. by path /content/dam/... and extension/file type).
There is also an older thread with similar requirements that might be interesting to you.
Hope this helps!