HTML5 or Frameless export contain inline script -> browsers do not show menu

[volkerr24776593]

Hey,

we currently face the following problem. We want to serve our documentation (frameless or HTML5 export of Robohelp 2020.8) as a web page next to our application. However, browsers do display the content but do NOT display the menu part (left hand side) or upper part of the documentation.

The browser (e.g. Edge) complains about inline scripts in the export HTM-files. Is there ANY way to generate security-compliant HTM files NOT containing any inline script?

Example of the index.html: the following part seems not to be accepted by the browser:

<script type="text/javascript">//<![CDATA[

gRootRelPath = ".";
gCommonRootRelPath = ".";
//]]></script>

Cheers Volker

[volkerr24776593]

Here is a screenshot of the console

[Amebr]

I think you'll have to contact support for this one. The email address is recommended as it goes to a dedicated Robohelp team: https://helpx.adobe.com/contact/enterprise-support.other.html#robohelp

[Peter Grainge]

A normal output from RoboHelp will display with the issue you are reporting. See RoboHelp Tour Introduction (grainge.org) on my site.

You must have something in your content that is causing that problem. Generate an output from the About RoboHelp sample project and you will not see that problem. Search your source files for part of the above such as gRootRelPath. See what that finds.

________________________________________________________

My site www.grainge.org includes many free Authoring and RoboHelp resources that may be of help.

[volkerr24776593]

Hey Thanks for the reply: however, the example project export contains the same problematic inline scripts... cheers Volker 

[Peter Grainge]

Then the problem is at your end as those projects are squeaky clean and the script is not causing anyone else a problem.

________________________________________________________

My site www.grainge.org includes many free Authoring and RoboHelp resources that may be of help.

[Amebr]

I was thinking that they might be running in to cross site scripting security features because of the "as a web page next to our application" hence my suggestion to contact support, as that code is automatically put in the output as part of the generation process.

I've done some more searching and I think it's this security feature on Volker's web server:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src

I think that setting would need to be changed but might not be possible or at least not easy depending on corporate security policies. So contacting support might still be the best option.

[Peter Grainge]

More your area than mine. That script is indeed in the topics in the RoboHelp Tour but there it is not causing a problem. That further supports your theory.

I notice @volkerr24776593 says 

However, browsers do display the content but do NOT display the menu part (left hand side) or upper part of the documentation.

@Amebr Does that suggest something wrong with the call and could that be related? I don't know but wonder if you do?

________________________________________________________

My site www.grainge.org includes many free Authoring and RoboHelp resources that may be of help.

[Amebr]

It is possible the help call is the problem. But the variables relate to file paths, so if they aren't being set, then it's possible various parts of the page aren't referenced properly so aren't being loaded.

I'm not familiar enough with how the new ui output is structured or any help call changes to offer advice about that. 

[Amebr]

The required help call will probably be different between Responsive and Frameless as well, I think.

[volkerr24776593]

Hey Thanks for your replies. The menu actually renders correctly if I open the same files from the file system.

furthermore, generating the html5 export of the robohelp sample project still contains these inline scripts edge is complaining about... I guess I need to deep dive into CSP with one of our developers...

[volkerr24776593]

Actually, inline scripts are security risks, however adobe does not seem to care about this. So our approach to host the exported help pages is to set up a separate ngnix server below a separate path with a CSP directive to tell the browser to actually accept inline scripts... 

[Peter Grainge]

OK but it doesn't seem to be an issue for anyone else. That's not to disagree but it is something you will need to take up with Adobe.

________________________________________________________

My site www.grainge.org includes many free Authoring and RoboHelp resources that may be of help.

[OCIE26080753zp6w · Accepted solution]

This is an issue for us as well. All of the inline java scripts are causing content security policy threat warnings. In order for the project documents to be useable, the content security policy needs to allow "unsafe-inline scripts", but that is a security concern that gets flagged when our application is scanned for vulnerabilities.

[volkerr24776593 · Accepted solution]

Hey,

solution is for a kubernetes environment hosting the HTML/Framless export

Do NOT do this inside an Angular development under "/assert/xxx"

What to do

• setup a separate ngnix-image under "/documentation" hosting the Adobe export
• Define approvate CSP-Header (most likely: allow any inline script for that documentation content under /documentation

Cheers Volker