User extensions need to be by "commotion user" not OS user

[seamustuohy]

Currently "User" are the different log-in's on an OS. Users should be the commotion log-ins under each log-in. This will allow for shared computers to have different user settings.

The example below shows four "users" (1,2,3,4). Each user can have custom settings and extensions. User's 1 & 2 can only access their account when logged in to the computer as "Operating System User A." Also, users 1 & 2

EG:

• Operating System User A
  • Commotion Login 1
  • Commotion Login 2
• Operating System User B
  • Commotion Login 3
  • Commotion Login 4

The "settings" values in utile/extension_manager.py will be impacted by this.

Possible Solution:

1. Save all user specific settings with a proper User Scope to ensure proper "OS User Scope" and then create a settings section that uses the currently logged in user as a key to check for "Commotion user" specific settings.

2. Use the "User Scope" from 1, but also have all settings saved using python-gpg and the users key. As such, each login is connected to a gpg-encrypted .ini file. Upon creation of a new user a gpg key is created using the users password. Upon login, when the user enters their login and password the gpg-key file associated with that login is loaded using that password by the commotion_client. If the key is loaded, and the .ini file is decrypted then the login succeeds. If it does not, then the login fails. Upon closing the .ini file is re-encrypted using the key. This would have to be built in as a fail-safe to ensure that even upon a crash the users data is only decrypted when using the application. This way all authentication is done through the python-gpg library and not re-implemented through commotion. We would need to ensure that the gpg code we write is audited.