Open JasonWeill opened 1 month ago
IIRC, the way we addressed this basic issue in the menu system, where we wanted some generic command that could have alternative implementations depending on the context (like the current document), was to make a top-level command that would delegate the work out to other extensions. So the base command essentially was making itself extensible. What do you think about making the save command extensible, rather than making an override mechanism?
Making the save command extensible would allow us to implement https://github.com/jupyterlab/jupyter-collaboration/issues/364 without creating a new command for use with RTC. There is still the risk that an extension, including a safe-looking extension, might modify the save command to do something harmful with user data. Should we warn users, at least once after extension install, that the save functionality has been modified by an extension? I want to provide safety without causing alarm here.
Problem
While investigating possible solutions for https://github.com/jupyterlab/jupyter-collaboration/issues/364, I was considering disabling the
docmanager:save
command in JupyterLab when a user has installed and activated thejupyter-collaboration
extension. However, it doesn't seem like this is supported. I found a Discourse thread from 2020–2021 in which@lodka
(not necessarily the same user on Discourse as on GitHub) shared an idea that technically worked, but, as @jasongrout confirmed, was not recommended and not expected to be durable.Proposed Solution
Allow extensions to override or disable commands in other extensions, such as by replacing a command with a no-op.
Additional context
This introduces a risk that a malicious actor could override an innocuous command to do something harmful, such as by injecting code that leaks data to an untrusted third party. Extensions that override built-in commands might require additional confirmation upon installation.