External markup renderer doesn&#39;t show any embedded images #1294

@lunny commented on GitHub (Nov 29, 2017):

Some tags maybe has been removed for safety.

@lunny commented on GitHub (Nov 29, 2017): Some tags maybe has been removed for safety.

GiteaMirror commented

@lunny commented on GitHub (Dec 2, 2017):

This is because the render generated <html> tag but gitea will ignore that and sub tags.

@lunny commented on GitHub (Dec 2, 2017): This is because the render generated `<html>` tag but gitea will ignore that and sub tags.

GiteaMirror commented

@memetb commented on GitHub (Jan 1, 2018):

I'm not clear why there's a need to use jupyter at all. gogs is able to preview these files just fine without having to re-render them (which can be unsafe and time costly). Is there a reason why this feature was lost?

@memetb commented on GitHub (Jan 1, 2018): I'm not clear why there's a need to use `jupyter` at all. `gogs` is able to preview these files just fine without having to re-render them (which can be unsafe and time costly). Is there a reason why this feature was lost?

GiteaMirror commented

@ivoszz commented on GitHub (Apr 23, 2018):

Same problem for asciidoc. The rendered path for images has the form "https://name.domain/user/repo/src/branch/master/file.png instead of correct "https://name.domain/user/repo/raw/branch/master/file.png.

@ivoszz commented on GitHub (Apr 23, 2018): Same problem for asciidoc. The rendered path for images has the form "https://name.domain/user/repo/src/branch/master/file.png instead of correct "https://name.domain/user/repo/raw/branch/master/file.png.

GiteaMirror commented

@lunny commented on GitHub (Apr 29, 2018):

@ivoszz your issue is different from this one, maybe you could fire another one.

@lunny commented on GitHub (Apr 29, 2018): @ivoszz your issue is different from this one, maybe you could fire another one.

GiteaMirror commented

@pavilo commented on GitHub (Nov 23, 2018):

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")

@pavilo commented on GitHub (Nov 23, 2018): It looks like the root cause for this is in [the sanitizer](https://github.com/go-gitea/gitea/blob/801843b0115e29ba2304fa6a5bea1ae169a58e02/modules/markup/sanitizer.go). 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: ```go 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") ````

GiteaMirror commented

@bekker commented on GitHub (Nov 28, 2018):

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.

@bekker commented on GitHub (Nov 28, 2018): 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. <img width="407" alt="2018-11-28 12 38 54" src="https://user-images.githubusercontent.com/4366401/49127488-d4c98800-f30a-11e8-8572-71339bf53cdb.png">

GiteaMirror commented

@programagor commented on GitHub (Feb 22, 2019):

@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?

@programagor commented on GitHub (Feb 22, 2019): @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?

GiteaMirror commented

@Tdarnell commented on GitHub (Feb 22, 2019):

I have also run into this issue and would second disabling certain sanitiser settings in the markdown.jupyter section of app.ini

@Tdarnell commented on GitHub (Feb 22, 2019): I have also run into this issue and would second disabling certain sanitiser settings in the markdown.jupyter section of app.ini

GiteaMirror commented

@pavilo commented on GitHub (Feb 23, 2019):

@programagor - yes, recompilation may be needed. Moreover, I only tested this config as a standalone golang executable, to make sure that the jupyter page renders as expected. The integration into gitea may require additional modifications.

@pavilo commented on GitHub (Feb 23, 2019): @programagor - yes, recompilation may be needed. Moreover, I only tested this config as a standalone golang executable, to make sure that the jupyter page renders as expected. The integration into gitea may require additional modifications.

GiteaMirror commented

@stale[bot] commented on GitHub (Apr 24, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Apr 24, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

@worthy7 commented on GitHub (Apr 25, 2019):

Hi, This is a problem. I created images in my markdown file like this :

![vs-install](./doc/markdown-images/install.png)

And on my local machine using VS, markdown preview extension it can see them fine.

When uploaded to gitea, it is trying to render this:
http://localhost:3000/Me/MyProject/media/branch/master/doc/markdown-images/install.png

Which gives a 404.

As you can see, the problem is that it is ignoring subfolders doc/markdown-images/

@worthy7 commented on GitHub (Apr 25, 2019): Hi, This is a problem. I created images in my markdown file like this : `![vs-install](./doc/markdown-images/install.png)` And on my local machine using VS, markdown preview extension it can see them fine. When uploaded to gitea, it is trying to render this: `http://localhost:3000/Me/MyProject/media/branch/master/doc/markdown-images/install.png` Which gives a 404. As you can see, the problem is that it is ignoring subfolders `doc/markdown-images/`

GiteaMirror commented

@worthy7 commented on GitHub (Apr 25, 2019):

Ok, the problem it is needed to be like this:

remove the ./ from the beginning
use CAPS file extensions

![vs-install](doc/markdown-images/install.PNG)

@worthy7 commented on GitHub (Apr 25, 2019): Ok, the problem it is needed to be like this: 1. remove the ./ from the beginning 2. use CAPS file extensions `![vs-install](doc/markdown-images/install.PNG)`

GiteaMirror commented

@eapetitfils commented on GitHub (Apr 25, 2019):

@Worthy7 Yes, that's what I thought. This bug is about images that are embedded in the HTML since images do not exist as a separate file. For markdown, this was an issue with path only.

For this particular bug, the solution is trivial but imply some security questions. I could not find any credible exploit possible, but I am no security expert, are we happy if I modify it and do a pull request so that this can be discussed there instead of pushing the milestone here?

@eapetitfils commented on GitHub (Apr 25, 2019): @Worthy7 Yes, that's what I thought. This bug is about images that are embedded in the HTML since images do not exist as a separate file. For markdown, this was an issue with path only. For this particular bug, the solution is trivial but imply some security questions. I could not find any credible exploit possible, but I am no security expert, are we happy if I modify it and do a pull request so that this can be discussed there instead of pushing the milestone here?

GiteaMirror commented

@worthy7 commented on GitHub (Apr 25, 2019):

@eapetitfils Ah sorry, didn't mean to issue hijack.
I'm not sure what bug you are referring to in your second paragraph there, mine, or this issue3025

@worthy7 commented on GitHub (Apr 25, 2019): @eapetitfils Ah sorry, didn't mean to issue hijack. I'm not sure what bug you are referring to in your second paragraph there, mine, or this issue3025

GiteaMirror commented

@eapetitfils commented on GitHub (Apr 25, 2019):

@Worthy7 no problem, at least the next person wondering why the images are not shown will see your answer.

The bug (or undesired feature as a matter of fact) I am referring to is this issue3025, not the markdown one.

@eapetitfils commented on GitHub (Apr 25, 2019): @Worthy7 no problem, at least the next person wondering why the images are not shown will see your answer. The bug (or undesired feature as a matter of fact) I am referring to is this issue3025, not the markdown one.

GiteaMirror commented

@limenleap commented on GitHub (Jun 10, 2019):

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

@limenleap commented on GitHub (Jun 10, 2019): 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

GiteaMirror commented

@stale[bot] commented on GitHub (Aug 9, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Aug 9, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented