jupyterlab_html
jupyterlab_html copied to clipboard
mflevine
Set the base html element for the data so that relative links work.
Next step for #7. This sets the <base> element for the iframe html, which allows it to correctly resolve external css, etc to the server.
Just tried this out and when clicked an internal link I got \__fake__.html is not in root static directory. Also when I tried a relative link with and without ./ in front, it kept adding an extra / to the request after files/ like http://localhost:8888/files//data.json which is a 403 error.
Ouch, you are right. I guess using a fake name for the html file is not going to work as well as I had hoped. We may need to (1) convert this to a non-mimerenderer extension so that we have access to the full file path, or (2) Bring over a bunch of the url-patching-up logic from '@jupyterlab/rendermime`. Specifically, a modified version of this code: https://github.com/jupyterlab/jupyterlab/blob/6e869ad222e701ea02b230a48c6066569d6cbbb9/packages/rendermime/src/renderers.ts#L625-L805
could allow us to both make internal links work correctly, and allow us to dispatch relative links to the contents API. The drawback for option (2) is that it would significantly increase the length of the extension.
What do you think?
Hmm. This was my first experience with TypeScript and I am not familiar with much of how the extensions and core code work so I don't think I am the person to make this decision. Was the goal for the core version to be just a mimerenderer or also have some extra functionality such as opening arbitrary web-pages in tabs?
Also, thanks for all your help.
Hi @mflevine, sorry to go silent there for a while. I have unstuck myself from this problem and opened a PR against JupyterLab (with your work intact).
It is at jupyterlab/jupyterlab#5855, I'd appreciate knowing what you think!
Hi @ian-r-rose, you have done some really great work on this! Will this version of the mimerenderer still allow external stylesheets and scripts such as bootstrap and d3? ex:
<script src="https://cdnjs.cloudflare.com/ajax/libs/d3/3.5.17/d3.min.js"></script>
Ooh, interesting point. There are some security considerations that we have to take seriously, and allowing unrestricted Javascript is definitely one of them. In particular, if we allow both server access and Javascript, malicious HTML files that the user opens could run arbitrary code on the server. (see, e.g., the notes on sandboxing here).
So right now I have disabled javascript in the rendered version intentionally, but maybe we can work out a way to allow users to click-to-enable as a compromise? We have a similar security model for notebooks, for example. What do you think?
I definitely agree about the security issue for a project like this. I think having a open as trusted option would be great since my use case has been single file reports that would need this.
I think we should be able to follow the same model for notebooks, and have a "trust file" option. I'll take a crack at that over at the other PR. Thanks!
just for clarification, will this be able to handle local .css files in a webroot directory? That is, if I clone a static website, could i preview it in Jlab? Right now the CSS doesn't load because the ability to view /files/ is locked down, even if I add c.NotebookApp.allow_remote_access = True
Hmm before I have been able to use /files/ to view local files with the extension. Maybe something has changed. Anyway this in the core and issues should now be made there.