eliminate inline <script> in file generated by doxygen - doxygen

A proposed change to the Content Security Policy (CSP) of our web server to disallow inline script
is causing a problem with the documentation generated by doxygen. Specifically, the problem occurs
in the generated index.html file, and the following lines:
<!-- Generated by Doxygen 1.8.15 -->
<script type="text/javascript" src="menudata.js"></script>
<script type="text/javascript" src="menu.js"></script>
<script type="text/javascript">
/* #license magnet:?xt=urn:btih:cf05388f2679ee054f2beb29a391d25f4e673ac3&dn=gpl-2.0.txt GPL-v2 */
$(function() {
initMenu('',false,false,'search.php','Search');
})
/* #license-end */</script>
If the initMenu() code is put into a separate file that is just included like other JavaScript files, everything
works just fine. Is there a doxygen option to put all JavaScript into files rather that inline? We can
post process the generated file to do this, but may not know when the "pattern" of this code may
change due to updates in doxygen itself. And we may not know if using additional doxygen features will result in other inline JavaScript.
Any suggestions would be welcome.
Thank you
Fritz Sieker

First off Content Security Policy is useful but far from being an absolute authority. There are other completely useless headers such as those that block referrers based on "privacy".
Secondly there is no such thing as "text/javascript", perhaps they meant application/javascript?
If you're using good (though very non-common practices) you don't have any script elements in the body element (use defer="true" on script elements in the head). By doing that you'll better understand the structure of JavaScript and that in turn will help you become more proficient/capable/help more people/make more money/etc.
You can use document.getElementsByTagName('body')[0].getElementsByTagName('script') to find all the script elements in the body element that don't belong there.
If you do have script elements in the body element beforehand and moving them to the head element is not feasible right now you're likely going to have to work with inherent logic, in short those script elements will always be inserted in to the DOM in a specific and reasonably easily reproducible area of your code (like as the very last elements). In such a case you can find them via the following:
document.getElementsByTagName('body')[0].lastChild
document.getElementsByTagName('body')[0].lastChild.previousSibling
document.getElementsByTagName('body')[0].lastChild.previousSibling.previousSibling
Keep in mind that pressing Enter in your code to make it more readable will insert a textNode so you may want to append nodeName to those instances and look for "script":
console.log(document.getElementsByTagName('body')[0].lastChild.nodeName);
There is the DOM TreeWalker that might help you out here, subjective to the end result in your DOM. I don't know offhand if you can transverse all the elements in reverse (probably).
Once you know what you want to delete instead of making everything convoluted just send that object (or id) to the following:
function element_del(id)
{
if (typeof id=='string' && id_(id) && id_(id).parentNode.removeChild)
{
id_(id).parentNode.removeChild(id_(id));
}
else if (typeof id=='object' && typeof id.parentNode=='object') {id.parentNode.removeChild(id);}
}
//Example:
element_del(document.getElementsByTagName('body')[0].lastChild);
I hope this helps!

Related

Dynamically inject content into JSDoc #example

I'm using JSDoc to document my javascript API.
I have an #example where I exhibit a minimized loader script (similar to the Google Analytics script). The loader script loads additional javascript from https://<server>/myProduct/lib/script.js.
My JSDoc documentation is bundled with myProduct, so there are aways /myProduct/lib/script.js and /myProduct/docs/ side-by-side. However, myProduct can be hosted by my customers anywhere, so I don't know what the <server> is.
I would like to be able to use document.location.href to detect current browser URL, and display a working loader script in my #example, so that customer can simply copy & paste a working script from documentation without having to manually edit the <server> part.
My question is: Does JSDoc offer any means to dynamically inject content into #example?
I could just manually edit the JSDoc output and include some custom javascript manually, which replaces <server> with the actual current server on run-time. However, this would be tedious to do every time my documentation updates.
No, JsDoc doesn't provide for injecting external content, and while it is certainly possible to create a JsDoc plugin to include external content during document generation, I don't think this would get you where you need to be.
I think the simplest answer would be to post-process the output of JsDoc to add a simple script, like
<script>
// retrieve the hostname from the current url.
const getServiceHostName = () =>
document.location.href.replace(/http:\/\/([\/]+)\/.+$/, '$1');
// replace the content of the span#service-host with the current hostname.
document.onload = function () {
document.getElementById("service-host").textContent=getServiceHostName();
};
</script>
to your html files just above the </body> tag.
Then, in the example content, insert a <span id="service-host"></span> where you'd like the service hostname to appear.
Another approach might be to take advantage of the fact that JsDoc passes the content attached to the #description tag directly into the html output.
So, this appears to do the expected:
/**
* Hostname: "<span id="service-host">hostname</span>"
*
* <script src="https://code.jquery.com/jquery-3.6.0.min.js"
* integrity="sha256-/xUj+3OJU5yExlq6GSYGSHk7tPXikynS7ogEvDej/m4="
* crossorigin="anonymous"></script>
*
* <script>
* $(document).ready(function() {
* $("#service-host").html(document.location.href);
* });
* </script>
*
* #name How-To-Monkey-Patch-JsDoc
*
*/
Note that the content of #example is wrapped in <pre><code>...</code></pre> in the html output which will definitely cause you problems, but it should be easy to post-process the html inline using the code above, by adding some recognizable token (perhaps [[HOSTNAME]]) into the example content and on document load, replace it with the desired value.
Please note also that this approach has the possibility of opening your docs to security issues, which is why I'd use the first solution above.

Typoscript filelink - Wrap URL within link

First, here is the Typoscript :
20 = TEXT
20 {
value {
field = field_title
wrap = |.txt
}
filelink {
stdWrap.wrap = <li>|</li>
path = fileadmin/txt-files/
}
}
The result I get is :
<li>
<a href="/fileadmin/txt-files/Title.txt">
<img src="typo3/sysext/frontend/Resources/Public/Icons/FileIcons/txt.png">
</a>
</li>
And what I need is :
<li>
<a href="/fileadmin/force_download_script.php?filepath=/fileadmin/txt-files/Title.txt">
<img src="typo3/sysext/frontend/Resources/Public/Icons/FileIcons/txt.png">
</a>
</li>
I need to make the link downloadable, rather than opening the file in the browser. For that I have a force_download_script.php, but when I do that :
wrap = fileadmin/force_download_script.php?filepath=|txt
instead of the current wrap, filelink doesn't find the file anymore.
I have tried using ATagBeforeWrap.wrap but it doesn't look like it's made for that purpose. I also tried typolinkConfiguration.wrap without any success.
Any idea of how to achieve that ? Using a COA maybe ?
Thank you !
I would not do this with a script, but with server configuration. If you use Apache and have .htaccess enabled, you can add the configuration to a .htaccess file in the directory where the files are located. See https://css-tricks.com/snippets/htaccess/force-files-to-download-not-open-in-browser/
Alternatively you can also use the HTML5 download attribute. This is not supported by Internet Explorer however (it is supported by Edge though).
The issue can get quite a bit complicated, but step by step:
your code above might be wrong if it's not just a copy & paste fault:
wrap = fileadmin/force_download_script.php?filepath=|.txt
The dot before txt was missing.
Nevertheless it is still interesting if the php-script is triggered.
It's possible that the script is not triggered due to some settings in typo3conf/LocalConfiguration.php respectively some settings in the install-tool.
Depending on the TYPO3-Version it's also possible that the script is not triggered at all because all scripts are being required now in an extension. That means you might need to create an extension for that script.
Also simple wrapping of the result with the script-path might not be enough, but you have to call it explicitly by TypoScript perhaps by including the script as user-function or lib.
The admin-panel might be useful to debug some things about your script but if not you've to include some debug-output first in your own code, if that's not enough in the core (temporary).
So you've to find out if your script is triggered and if not, the reason for it.
Are you sure .filelink is what you are looking for?
.filelink is for a set of files. For all files in the folder given by .path a link will be generated. see manual
From your description you want a text wrapped with a link to one single file. That would be more a problem for .typolink where you specify the link in .parameter.
if you really want a link list of multiple files, each wrapped with your script you need to modify .typolinkConfiguration.parameter which will be used internaly by .filelink.
Anyway it might be possible to do a wrap which then would be:
.typolinkConfiguration.parameter.wrap = /fileadmin/force_download_script.php?|
Maybe it is easier to build your list with .stdWrap.filelist, where you can use the filenames in any way to wrap your own href parameter for an A-tag.
To use the TYPO3 core solution with file links you can use this guide:
Create a file storage where you want your "secured" files in TYPO3 backend
Do not set the checkbox "Is public?" in the storage record
The links will be rendered with eID and file parameters
You can look into the FileDumpController handling these links: https://github.com/TYPO3/TYPO3.CMS/blob/2348992f8e3045610636666af096911436fa1c89/typo3/sysext/core/Classes/Controller/FileDumpController.php
You can use the included hook to extend this controller with your logic.
Unfortunately I can't find any official documentation for this feature, but will post it when I find something or wrote it myself. ;)
Maybe this can help you, too: https://extensions.typo3.org/extension/fal_securedownload/
Here is the official part, but it's not much: https://docs.typo3.org/typo3cms/CoreApiReference/ApiOverview/Fal/Administration/Storages.html?highlight=filedumpcontroller

Mezzanine/TinyMCE filtering script type

I'm building a website using brython and I came by a problem that has nothign to do with it.
My problem is with Mezzanine or TinyMCE editor (I'm not sure which). To make brython work I need the script tag to be "text/python". But the editor filters it automatically to "text/javascript".
I disabled the filtering already, both in the admin panel and in the actual source code, I tried adding "text/python" to the RICHTEXT_ALLOWED defaults in the mezzanine configuration too.
Just to be clear, security is not an issue, this particular feature won't go online in the final version of the website.
Although the HTML specification does allow one to put any value other than "text/javascript" in script's type attribute, few projects do that, and Brython is one of those few. It is likely the "text/javascript" value is simply hardcoded in the editor and it won't allow you to change that.
(There is probably a big chance of having an issue closed as "won't fix/not a bug" or equivalent if you try to report this to the editor's issue tracker).
I think the workaround in this case is to write some javascript to change the text on the attribute on the relevant script tags to "text/python" prior to calling Brython. i.e., instead of triggering Brython on your page with
<body onload="brython()" >
Do something along
<body onload="function (){var x = document.getElementsByName("python"); for(var i=0; i < x.length; x++){x.type="text/python"};brython()}()" >
(and of course, add the attribute name='python' to all your python script tags)

Getting the emberjs starter-kit to work with coffeescript

i'm trying to get the starter-kit example of ember.js to work directly with an app written in coffeescript (with the use of http://coffeescript.org/extras/coffee-script.js).
I want to use this in an development environment, without the need to convert the coffescript to javascript first (manually or with tools like jitter).
Basically i just replaced the line
<script src="js/app.js"></script>
with the lines
<script src="js/libs/coffee-script-1.3.3.min.js"></script>
<script type="text/coffeescript" src="coffee/app.coffee"></script>
in the index.html
All changes i've made can be found in my fork on github at https://github.com/GordonSchmidt/starter-kit
The coffescript itself seems to be fine, because when i convert it to javascript first the starter-kit application works with this javascript. But when i use the coffeescript directly it throws the error "assertion failed: Unable to find view at path 'App.MyView'" in line 45 of ember-0.9.8.1.js. The coffee-script.js all by itself seems to work as well (see demo.html). So it has to be a conflict between ember.js and coffee-script.js.
But I'm not able to find this error. Can someone please point me in the right direction?
from coffeescript.org
The usual caveats about CoffeeScript apply — your inline scripts will
run within a closure wrapper, so if you want to expose global
variables or functions, attach them to the window object.
your coffeescript should look something like this:
<script type="text/coffeescript">
window.App = App = Em.Application.create()
App.MyView = Em.View.extend(
mouseDown: -> window.alert "hello world!"
)​
</script>
see here for a fiddle

getBoundingClientRect() is returning zero in XUL

I have a problem with my firefox extension
I have a XUL popup panel with a hbox for the tag cloud, and a JS code to add divs to this hbox:
<hbox id="tag_base" ondblclick="alert('done')"/>
JS:
var root = document.getElementById('tag_base');
var tag = document.createElement('div');
tag.textContent = 'test';
root.appendChild(tag);
var rect = tag.getBoundingClientRect()
alert(rect.top)
I need to get the dimensions of each added div, however, getBoundingClientRect simply refuses to work.
If I remove alerts, it's always zero.
With alerts the story is different:
The first time the alert is called it returns zero, although the div appears on the screen.
Any subsequent alerts return the correct coordinates.
If I set a breakpoint in Chromebug, everything is reported correctly.
If I do not interupt the execution in any way, and run a loop, only zeroes got returned.
This has got me quite confused.
Calling "boxObject" produces the same results, while "getClientRects[0]" is undefined on the first call.
Any hints on what might be causing this will be greatly appreciated.
Note :
Caution, if you use getBoundingClientRect with an element which has display:none then it will return 0, anywhere in the dom.
Although I can't find any documentation on this seemingly fundamental issue, the problem you noticed is most likely because the layout (aka "reflow") process has not yet run by the moment you ask for the coordinates.
The layout/reflow process takes the page's DOM with any styles the page has and determines the positions and dimensions of the elements and other portions of the page (you could try to read Notes on HTML reflow, although it's not targeted at web developers and probably is a bit outdated).
This reflow process doesn't run synchronously after any change to the DOM, otherwise code like
elt.style.top = "5px";
elt.style.left = "15px";
would update the layout twice, which is inefficient.
On the other hand, asking for elements position/dimension (at least via .offsetTop) is supposed to force layout to return the correct information. This doesn't happen in your case for some reason and I'm not sure why.
Please create a simple testcase demonstrating the problem and file a bug in bugzilla.mozilla.org (CC me - ***********#gmail.com).
My guess is that this is related to XUL layout, which is less robust than HTML; you could try creating the cloud in an HTML doc in an iframe or at least in a <description> using createElementNS to create real HTML elements instead of xul:div you're creating with your current code.
Be sure the DOM is ready. In my case, even when using the getBoundingClientRect function on click events. The binding of the events needed to happen when the DOM is ready.