Connexion with the Collabora server is lost for all ongoing edit sessions if an extension is uninstalled while the editing is ongoing

[lucaa]

Steps to reproduce:

• install collabora connector extension, with its API installed on farm (as required by the connector)
• install some other jar extension on farm ( for example script component, or the diagram API)
• start an editing session for a file of a page
  • make some changes left unsaved
• in parallel, while the session is open in a tab
• go to the administration section of XWiki, to the extension manager and uninstall the jar extension installed at step 2 on farm
  • this can be done with the same user as the one editing in collabora or with another one, it doesn't matter
• go back to the tab where the collabora editing session is ongoing and click save

Expected result:

• the attachment is saved correctly

Actual result:

• a message saying that the token is invalid is displayed instead, it's not possible to save from the collabora session.

[lucaa]

The cause for this is the same as the one for the providers invalidation for azure sso, the fact that, upon reinstallation, all components loaded through the extension manager are reloaded and whatever state they're storing is lost upon this reload xwikisas/integration-azure-oauth#16 (comment) . In this case, the tokens are stored in the component and thus they are lost upon reload.
The extension manager works like this because it's not possible to 'remove' a class from a java classloader, the only way to do it is to reload the whole classloader again, with one less class (the one to be removed). On uninstall of a jar extension we need to remove the class of that extension from the classloader.

[lucaa]

Note: any other situation in which the classloaders/components are reloaded will result in the same 'broken session' because of lost token.

[lucaa]

Workaround for the lost session to avoid losing the work that was done in the the collabora editor:

• the collabora editor has a menu that allows to export a file
• when the session is lost and the XWiki page attachment cannot be updated, the file that is being edited can be exported using this feature
• and then manually uploaded as an attachment on the original page where it was on the wiki

[lucaa]

Another workaround for this issue is to install the collabora connector in the WEB-INF/lib of the jar instead of as an extension.
This will use a different classloades for the collabora connector component and will prevent it from being reloaded everytime an extension is uninstalled.

[oanalavinia]

The problem comes from the fact that the list of tokens, needed to validate a save, is kept on a component. At a jar uninstall, this component is reinitialized, so the list of tokens is lost. So we need a solution that would either renew this token, or will give the option to reassemble the list of tokens when it's emptied. I propose the following options:

1. Have the list of tokens saved on the file system as well, on the permanent directory.
   This list would be reassembled at component initialization step, and updated at dispose, in order to not do many write/read operations on it, but only to keep it as a cache.
   As a location for this, one of the following could be used: data/cache/extension/collabora, store/collabora, or just collabora
2. Start a renew token process from the UI
   Using the Collabora PostMessage API, the default save would need to be disabled Disable_Default_UIAction. Like this, on the UI_Save, a check can be done first for renewing the token on the server side and only after to start the Action_Save. It might be needed to listen to another event as well, depending on what the auto-save feature is firing. From a quick test I did, it just fires another Doc_ModifiedStatus (with a modified=false). But it might still be enough to do the renew only on the intentional save.
   It's important to note that Collabora is caching the token which was used for starting an editing session, so when we create a new token, a map between the old value and the new object must be kept.
   My only concern about this second option is related to how this implementation will this be influenced by Make collabora save and exit actions more intuitive #12 . On a quick analysis, that would mean that depending on different user actions, we will fire the Action_Save event, which is the same event we fire to finish the save action after renewing the token. So a loophole might be created with listening and firing the same event.
   Another idea would be to just have a renew token button somewhere, so the user can do this manually when the invalid token modal appears (this modal is the only feedback we have that the token is invalid, there is no event fired). This is simpler, but it's not a very great UX.

I would choose the first option, the second could have some problems.