gitea: External markup renderer doesn't show any embedded images

@pavilo Does that mean that I’d need to recompile Gitea with the modified sanitizer.go in order to display Jupyter notebooks? Is it possible to expose these settings in app.ini instead?

I’m not sure it’s exactly the same issue, but <img> tags with relative image path in .md files needs to be switched to ‘raw’ path, like github and gogs handle them.

It looks like the root cause for this is in the sanitizer. It removes a lot of things, such as inline (incl scoped) CSS, images with data URIs, iframes etc. Is it possible to add an external sanitization configuration per markup handler? To make something meaningful our of the external markup renderer one may have to use things like scoped CSS, images (both data URI and links to raw project resources) and unfortunately sometimes also javascript (e.g. MathJax, jupyter widgets etc). In extreme cases an iframe may be required too.

This configuration mostly works for a jupyter notebook with python code and embedded images:

sanitizer.policy.AllowImages()
sanitizer.policy.AllowDataURIImages()
sanitizer.policy.AllowLists()
sanitizer.policy.AllowTables()
sanitizer.policy.AllowAttrs("class").Globally() // may targeted at concrete elements e.g. div, span, a, h1 ...
sanitizer.policy.AllowAttrs("type", "scoped").OnElements("style")

I got kind of a workaround. Not a good solution, but a workaround:

It looks to me that the sanitizer does not disturb a div tag with an ID.

So in Windows I wrote a batch file which just echoed that div thus:

@echo ^<div id='splview-%1' ^>Click here to view this file^</div^>

In the above statement %1 is the name of the temporary file that Gitea creates just before executing this batch file. (In Linux bash script, I think the parameter is $1 )

Now, before echoing out that statement, I of course did all the work (shhh…dont tell Gitea) and saved the converted HTML file somewhere else

Then in the custom template at custom\templates\custom\footer.tmpl at the Gitea executable folder; I wrote this script block

$('div[id^="splview-"]').click(function () {
    alert($(this).attr('id'));  
  //Instead of alerting... you should parse the id and
 //do whatever else that is needed to display the freshly constructed html
});

In my case, I am over-writing just one HTML file so for each file that uses this route, the eventual batch file generated HTML would be the same file (i.e. it is overwritten) – at least that is what I plan to do.

I have reached till here – now I need to write the code for popping up a separate window to display that batch file generated HTML …

Note: I had ensured that the custom/conf/app.ini file was configured to execute that batch file, as the external renderer, for the given filetype

Hope this works out. Fingers crossed