Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [che-dev] Persist Theia plugin data in a Che workspace
As Sun noted a user will expect his plugin configuration to be the same across workspaces. But this has some technical challenges:
- as noted by Mykola using Che user preference doesn't scale
- a persisted volume (shared across all the workspaces of the same user) won't work with PVs of type RWO
- using config map is tricky (access to the k8s API, how to sync the config map and the plugin config)

That said the lesser of two evils, in this case, looks like using a persistent volume per workspace (as we do for projects).

Regarding encryption of a plugin data I agree with Gorkem that it should be the responsibility of the plugin itself.
 

On Mon, Dec 17, 2018 at 11:09 AM Mykola Morhun <mmorhun@xxxxxxxxxx> wrote:
@Gorkem thanks, you are right, I am working on globalState and `workspaceState.

This brings the questions how are the settings for user and workspace are handled at the moment?

For user scope we have user preferences.
As about workspace, as far as I know, there is not special storage and a volume is used for such kind of needs.

About globalState and `workspaceState.

globalState
If we want to store globalState between workspaces we have to use Che user preferences (or write another service that shouldn't be Theia specific, but satisfy our requirements)
This has its own pros and cons.
Pros:
  1. We will share some global plugin data between workspaces (it might share a token or settings, see Cons 3).
Cons:
  1. A plugin can save any kind and any amount of data there (no limits by specification at all). So, there is a chance we'll have quite big amount of data there, which may slow down some services. Not so good solution imo.
  2. Memento object is synchronous by specification. It means that we cannot request data by key when needed, but have to download all the data each time when plugin starts. Again, we do not know data size.
  3. We support different sets of plugins per workspace. But when a user has the same plugin in different workspaces and wants to have different settings for each, this approach will make it impossible (for example, in one workspace it is adopted to maven + java + spring boot, in another - it is set up to work best with nodejs). Also a problem if a user wants to use different tokens(not necessarily github) from different workspaces for the same plugin.

workspaceState
If we need to encrypt workspace state we may store encrypted data inside volume, and store the key in user preferences.
But here we face the same problem with synchronous memento: we need to return requested data immediately, so must decrypt whole database and send the data to each plugin on start (database might be big because it stores workspace data of all the used Theia workspaces) or we may use database that supports decryption and encryption on fly. If I am not mistaken, postgresql should be able to do that, but I think it is overkill to bring postgresql for storing workspace state.
On this step, I am not sure that we need encryption (workspaces (projects) itself are not encrypted).

On Sat, Dec 15, 2018 at 7:06 PM Gorkem Ercan <gorkem.ercan@xxxxxxxxx> wrote:

Looked at this a bit more.

@Mykola which APIs are you implementing exactly?
I guess you are on ExtensionContext.

ExtensionContext::globalState should return a Memento implementation that stores the data centrally.
ExtensionContext::workspaceState should return a Memento that can store the data on the workspace but we should
handle transparent encryption/decryption this data. I am not sure what was Sergii Leshchenko's suggestion that
Sergii referred to down to the thread but we need a way to encrypt/decrypt that data user specific way.

ExtensionContext::logPath and ExtensionContext:storagePath are locations on the Che workspace which were the ones
Thomas was referring to mostly.

IMHO if an extension is accessing those locations directly it is their responsibility to do the encryption.

This brings the questions how are the settings for user and workspace are handled at the moment?

Thanks,
Gorkem

On 15 Dec 2018, at 0:40, Oleksandr Garagatyi wrote:

I agree with Thomas. Compatibility with VS Code is quite critical. 
Every time I say someone that we are working on ability to grab VS code extension directly from the marketplace they are blown away. 
And secure workspace sharing comes with a price: you can’t store anything in files, you can’t store anything in environment variables. And now we do store a workspace token in environment variable, so invited user can find it. Apart from that, if user is in terminal of a workspace it is possible to catch memory of the IDE and find tokens even if they would be used per-action and not persisted anywhere. 
This leads us to the situation we have on OSIO - sharing is not secure. 
If we want to share workspaces we need to think through how it can be achieved and what are the drawbacks if any. 

пт, 14 дек. 2018 г. в 08:29, Sun Tan <sutan@xxxxxxxxxx>:
That's the point, we are reaching a point where usage from vscode/desktop is very different to how we could use it in Che/cloud

On Fri, Dec 14, 2018 at 4:28 PM <tmader@xxxxxxxxxx> wrote:
That's the point...it's not just the github token, it's arbitrary files that may or may not contain information that is considered confidential. VSCode has the storage path at $HOME/.config/Code[ - Variant]/User/workspaceStorage/

A vscode extension can put any type of file it wants there.

/Thomas

On Fri, 2018-12-14 at 16:04 +0100, Sun Tan wrote:
also if we still just talk about the github token, it should be stored through all the workspaces. I cannot see a user having to reimport a token each time he create a new workspace ...

On Fri, Dec 14, 2018 at 3:58 PM Sun Tan <sutan@xxxxxxxxxx> wrote:
To me, if you take the Github token are personal and
should NOT be per workspace
SHOULD be per user
I cannot see how we could allow another user that has access to my workpace to use my github token

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev
--

Sun TAN
Senior Java Software Engineer
Eclipse Che - Openshift.io @ Red Hat
Paris JUG team member

Mobile : +33 6 21 02 41 73
Email : sutan@xxxxxxxxxx 
Email Paris JUG : sunix@xxxxxxxxxxxx
Blog: http://blog.sunix.org
twitter: @sunsengdavidtan 

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev
--
Oleksandr Garagatyi

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev


--

Mykola Morhun

SOFTWARE ENGINEER

Red Hat

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev

Back to the top