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.
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:
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.