View in Browser on HTML files render them as plain text

[pl_componize]

When I use the Share "View in Browser" doclib action on an HTML file, it always renders it as plain text. Is this normal behavior?
I double checked the mimetype and it's set correctly to HTML.

[loftux]

I just test in Chrome and Firefox, and see the same thing. The file has html ending.
File viewed via Share proxy displays text
http://localhost:8080/share/proxy/alfresco/api/node/content/workspace/SpacesStore/4998bd36-eebb-49dd...
File displayed via Explorer renders html
http://localhost:8080/alfresco/d/d/workspace/SpacesStore/4998bd36-eebb-49dd-a966-87dc89fa2b06/file.h...

So this may be a bug, you can file one at http://issues.alfresco.com

[erikwinlof]

Hi,

The reason for this is browser security since the user created html could contain "hidden" javascript (i.e. inside <script type="text/javascript">alert('xss);</script> elements and/or <img onerror="javascript: alert('xss')"> etc etc). Therefore, user created html content, that is being brought back from the repository through Share's (Spring Surf's) proxy is automatically set to be of type "text/plain" instead of "text/html". This way the browser won't execute any potential dangerous javascript code composed by the author.

If you do want to display the html inline you could create a custom Share web tier webscript that takes the html content and "strips" it from unsafe html blocks and attributes.
A webscript that looks *something * like this:


safe-html-proxy.get.js
————————
var connector = remote.connect("alfresco"),
   result = connector.get("api/node/content/workspace/" + args.nodeRef.replace(":/", "")),
   html = eval('(' + result.response + ')');
model.safeHtml = stringUtils.stripUnsafeHTML(html);

safe-html-proxy.get.html.ftl
——————————–
${safeHtml}

In other words in the doclib, create a custom link action that points to your custom webscript:
share/service/acme/utils/safe-html-proxy?nodeRef=workspace://SpacesStore/246724d2-f642-47e4-8d83-380e60fc0801

PS. This is basically what the wiki and blog posts are doing in Share.

[erikwinlof]

PS2. While were on the subject: When you create your own webscripts make sure you always use the "?html" and "?js_string" freemarker macros (depending on where you output them) when outputting user created content.
I.e.

custom-webscript.get.html.ftl
———————————–
<!– encode as js string to make sure '"' characters are escaped –>
<script type="text/javascript">
alert("${title?js_string}");
</script>

<!– encode as html string to make sure < and > characters are escaped –>
<h3>${title?html}</h3>

[srosenberg]

I am sorry.  I am going to have to claim "shenanigans" on this solution.   This issue is NOT SOLVED.   Content created in HTML format, has but one function… to support the intention of viewing a RENDERED PAGE in some kind of browser!   Why else would we want to save content in HTML format inside the repository to begin with?  Granted, there are some unsafe HTML tags that should definitely be stripped out.  However, when you press the "View in Browser" link, one should be able to see something that is representative of the HTML content, using the text/html mimetype.   We shouldn't have to mire ourselves in additional ftl's or scripting. The only thing that is preventing us from seeing our HTML is a text/plain content type header vs a text/html one.  Even with the ftl scripting, we wont be able to see anything close to a rendered page without the text/html mime-type.   Please get on the ball on this one Alfresco Developers.  This work-about solution is not a solution that satisfies the nature of the problem. 

If the above solution does solve the problem, and I missed something, I would be glad to hear it out with step by step instructions on how this thing that SHOULD ALREADY BE THERE, can be added to seamlessly show rendered HTML content by simply pressing the View in Browser link.

[kevinr]

Hi,

Yes you are correct, and yes I agree with you the current solution is far from ideal - more a knee-jerk reaction to what can be perceived as a potential severe security hole.

I will get this looked at ASAP and ensure that we have a better solution going forward.

Thanks,

Kevin

[kevinr]

https://issues.alfresco.com/jira/browse/ALF-13806

[kevinr]

The issue has now been resolved for Alfresco Enterprise 4.0.2 and Community HEAD (rev 35696). The next nightly build will therefore also contain the fix.

Apologies again for this. A knee-jerk last minute fix for a perceived security issue at the end of the 4.0 bug fixing phase caused the original issue.

https://issues.alfresco.com/jira/browse/ALF-13806

Kevin