Zotero://select one-click local reference database access

[jangenoe]

It is convenient (when preparing research papers) to have quick access (i.e. one-click access) to all references and sources (and the links between them) in my publication database.
I use Zotero as publication database. A typical local one-click link to a paper uses "zotero://select".

This one-click reference access to Zotero works perfect from:

• html files in Firefox
• Markdown files rendered in Firefox using Keith Robertsons Firefox extension
• Zotero select links all microsoft office apps (Word, PowerPoint, ...)
• Links in code rendered by Notepad++
• ...

However, in jupyter lab, the corresponding markdown links do not work in Markdown cells or Markdown files using:

• [PriorArt2007](zotero://select/library/items/MLW6CEM6)
• <a href="zotero://select/library/items/MLW6CEM6">PriorArt2007</a>

It does work however when I embed the zotero-select URI in a HTML code-cell in jupyter lab

%%HTML
<a href="zotero://select/library/items/MLW6CEM6">PriorArt2007</a>

The root cause seems to be the blocking done during the sanatizing of the html, I guess for security reasons in outdated browsers, but can security be the argument, when there is a bypass using %%HTML?

Would it be possible to allow users to add additional allowed uri schemes to their local jupyter lab preferences?

Related issues:

• Others have reported similar problems with papers2 (the papers2 software now integrated in the ReadCube reference management software)
• Once the document goes public, it is easy to replace the link with the corresponding reference using cite2c @takluyver

[jasongrout]

What does it get translated to when it doesn't work?

We use sanitize-html, which apparently has an option to allow more schemes: https://github.com/apostrophecms/sanitize-html/blob/master/README.md#allowed-url-schemes

[jasongrout]

Indeed, it looks like we already set some relevant options:

jupyterlab/packages/apputils/src/sanitizer.ts

Lines 956 to 965 in 1d03a36

	allowedSchemesByTag: {
	// Allow 'attachment:' img src (used for markdown cell attachments).
	img: sanitize.defaults.allowedSchemes.concat(['attachment'])
	},
	// Override of the default option, so we can skip 'src' attribute validation.
	// 'src' Attributes are validated to be URIs, which does not allow for embedded (image) data.
	// Since embedded data is no longer deemed to be a threat, validation can be skipped.
	// See https://github.com/jupyterlab/jupyterlab/issues/5183
	allowedSchemesAppliedToAttributes: ['href', 'cite']
	};

I wouldn't be opposed to a user setting listing additional schemes that would be allowed.

[jangenoe]

Hi Jason,
Thanks for supporting this.

The following line inserted in front of the line does the job for me:

allowedSchemes: ['http', 'https', 'ftp', 'mailto','zotero'],

However, this does not yet make it a a user setting listing additional schemes. I guess to make it user specific we should introduce in the preferences somewhere a user_defined_URI_List and subsequently concatenate

sanitize.defaults.allowedSchemes
user_defined_URI_List=['zotero']

Where in the user interface would you prefer to introduce the variable user_defined_URI_List ?

[takluyver]

can security be the argument, when there is a bypass using %%HTML?

Just to clarify on this: when you open an untrusted notebook, HTML output is not displayed. HTML in Markdown cells is displayed, but sanitised. Different compromises were chosen for HTML output and for Markdown cells.

I don't know what security implications there are in allowing other URL schemes, but if there are any, that's why you can bypass them with %%HTML - you can only do that by running the code yourself, or explicitly trusting the notebook.

[jasongrout]

Thanks for the clarification, @takluyver.

@jangenoe - the advanced settings editor would be the normal place for such settings to go in JupyterLab. Looking at the code a bit more, it looks like the sanitizer is not provided as a plugin that can be configured and overridden, but instead is used directly as a library by the rendermime plugin. In the current architecture, it seems the easiest way forward is to thread that option up through the ISanitizer interface, and then introduce a rendermime setting in the rendermime-extension plugin, which uses that setting to customize the sanitizer constructed for the rendermime registry.

[jasongrout]

A more "correct" way may be to expose the sanitizer to the system as a plugin, with its own default settings, and make the rendermime registry depend on that system object.

The problem there is if you want different default settings in different situations, like @takluyver points out.

[jasongrout]

A more "correct" way may be to expose the sanitizer to the system as a plugin, with its own default settings, and make the rendermime registry depend on that system object.

#9873 exposes the sanitizer as a plugin (thanks @ohrely!). To finish off this issue, making the allowed schemes user-configurable, we'd need to also introduce this as a setting for the sanitizer.

[falbarelli]

@jasongrout I think I am a bit slow... is there an user-friendly to fix the original issue currently? I also want to link local Zotero database entries while coding in Jupyter notebooks.

[jasongrout]

is there an user-friendly to fix the original issue currently? I also want to link local Zotero database entries while coding in Jupyter notebooks.

No, which is why the issue is still open. I think the easiest way to finish off this issue is for someone to submit a PR exposing the allowed schemes in a setting for the sanitizer plugin. Then a user would be able to easily configure their settings to allow a new scheme.

[falbarelli]

I think the easiest way to finish off this issue is for someone to submit a PR exposing the allowed schemes in a setting for the sanitizer plugin. Then a user would be able to easily configure their settings to allow a new scheme.

OK thanks for the clarification. I don't have the technical expertise to do this myself, but I would very interested in this functionality.

[kostyafarber]

Keen to work on this. Any resources on how to add user config to this plugin?

[jasongrout]

Thanks!

Here is a tutorial on adding settings to a plugin: https://github.com/jupyterlab/extension-examples/tree/master/settings

Here is the documentation talking about plugin settings: https://jupyterlab.readthedocs.io/en/stable/extension/extension_dev.html#schemadir

You can also generate a plugin from the cookiecutter with settings to see how settings work in a very simple situation.

[kostyafarber]

Awesome will have a look and try put something together. Thanks for the links to the resources.

[kostyafarber]

Would we want to put this as a setting in the settings editor?

Something along the lines of:

• Sanitizer --> then I guess an area where the user can add or delete schemes?

[jasongrout]

If you follow the tutorials above about adding settings to the plugin, the setting will show up automatically in the settings editor.