You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
QGIS has an inbuilt secure store for user secrets, known as the "Authentication" system. The authentication framework is designed where secrets are stored in an encrypted sqlite database within the user's QGIS profile.
This database must be decrypted via a "master password" before secrets can either be read or stored in it by QGIS core or plugins. On some systems (linux, Windows) there is support for storing this master password within the user's operating system keychain/wallet, so that the user does not need to re-enter it when starting a new QGIS session. (Wallet storage is NOT currently available on Macos without user configuration tweaks, due to lack of notarization on the QGIS install. See qgis/QGIS#46175).
Summary
This proposal is a companion to #278 -- in that proposal I described several incremental enhancements to the QGIS authentication framework, but the consensus from that proposal was that further research is required prior to making any changes.
Accordingly, this grant application involves a deeper research effort into the changes proposed in #278, and, ONLY if suitable, implementation of those proposals.
Please see further details and in depth discussion in #278
This proposal is a joint proposal with @elpaso to leverage a wider set of expertise.
Note that I am deliberately not linking #278 directly with the grant request, as we are NOT proposing #278 as the final outcome of the grant. Rather, the changes in #278 will only be implemented during the grant if they are deemed to be suitable and safe. If not, then the changes proposed in #278 will not be implemented (or may be only partly implemented).
The text was updated successfully, but these errors were encountered:
@troopa81 I am going to submit a grant proposal for #248 which was originally designed with the server in mind but from an implementation perspective could be extended to desktop by using the same core API.
I am talking to @nyalldawson in order to consider if the two proposals could be joined into a single one. They are somewhat independent but it could be wise to consider them together when refactoring the auth system.
Thank you for submitting your proposal to the 2024 QGIS Grant Programme. The 2 week discussion period starts today. At the end of the discussion, the proposal author has to provide a 3-line pitch of their proposal for the voter information material. (For an example from last year check qgis/PSC#58 (comment))
QGIS Enhancement: Authentication system revision (v1.1)
Date 2024/03/14
Author Nyall Dawson (@nyalldawson)
Contact [email protected]
Version QGIS 3.X
Current situation
QGIS has an inbuilt secure store for user secrets, known as the "Authentication" system. The authentication framework is designed where secrets are stored in an encrypted sqlite database within the user's QGIS profile.
This database must be decrypted via a "master password" before secrets can either be read or stored in it by QGIS core or plugins. On some systems (linux, Windows) there is support for storing this master password within the user's operating system keychain/wallet, so that the user does not need to re-enter it when starting a new QGIS session. (Wallet storage is NOT currently available on Macos without user configuration tweaks, due to lack of notarization on the QGIS install. See qgis/QGIS#46175).
Summary
This proposal is a companion to #278 -- in that proposal I described several incremental enhancements to the QGIS authentication framework, but the consensus from that proposal was that further research is required prior to making any changes.
Accordingly, this grant application involves a deeper research effort into the changes proposed in #278, and, ONLY if suitable, implementation of those proposals.
Please see further details and in depth discussion in #278
This proposal is a joint proposal with @elpaso to leverage a wider set of expertise.
Note that I am deliberately not linking #278 directly with the grant request, as we are NOT proposing #278 as the final outcome of the grant. Rather, the changes in #278 will only be implemented during the grant if they are deemed to be suitable and safe. If not, then the changes proposed in #278 will not be implemented (or may be only partly implemented).
The text was updated successfully, but these errors were encountered: