David, AQBanking maintains its own set of settings files in ~/.aqbanking. Finance::Quote at present doesn't keep any user state.
Regards, John Ralls > On Jun 15, 2019, at 5:52 PM, David Carlson <[email protected]> > wrote: > > I believe the AQ Banking feature has already solved the issue of saving > usernames and passwords for multiple financial institutions in a manner that > is easily migrated to new GnuCash releases. Is it possible to do the API Key > thing in a manner that would seem very little different to the user? > > > > On Sat, Jun 15, 2019 at 12:53 PM John Ralls <[email protected]> wrote: > > > > On Jun 15, 2019, at 9:17 AM, Vincent Lucarelli > > <[email protected]> wrote: > > > > Hi, > > > > We are working on the next release of Finance::Quote and will try to add > > https://iexcloud.io/ <https://iexcloud.io/> as a new module. > > > > Like Alphavantage, users will need to register and get an API key. > > > > Since GnuCash is a major user of Finance::Quote, I wanted to get opinions > > on how to handle API keys. I have two initial ideas: > > > > > > 1. Each Finance::Quote module expects a module specific environment > > variable and GnuCash would need to update the Preferences > Online Quotes > > pane for each API key. > > > > 2. We invent a more global environment variable that can hold multiple API > > keys. For example, something like > > > > FQ_API_KEYS=ALPHAVANTAGE_API_KEY:XXXXXXXXXXXXXXXX;IEXCLOUD_API_KEY:sk_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > > > > > > The problem with the first approach is that GnuCash preferences need to > > change with each addition. > > > > The problems wit the second approach are usability and parsing (do we > > assume no service would ever include : or ; in the API key?). The later > > could be solved with json formatting, but that is even worse for users. > > > > > > > > Appreciate any suggestions. > > Vince, > > Excellent news, thanks for stepping up to help Erik out. > > ';' in your FQ_API_KEYS will have to be quoted to keep the shell from > interpreting it, and any quotes in the key would have to be escaped even with > separate environment variables per service. Telling users to escape the > delimiter character and quotes is easier than teaching them to format a JSON > string. e.g FQ_API_KEYS="AlphaVantage:xxxxxxxxx\"xxxx\:xxxxxx...". The real > problem with that is that it breaks backward compatibility with GnuCash, > which sets ALPHAVANTAGE_API_KEY when the preference is set. That could be > worked around by continuing to look for the older environment variable, or > telling users to set the new environment variable themselves, which they'd > need to do anyway to use a new service until we rewrote the preference item. > Note that we're two weeks away from our next release, so that change would be > in the September release at the earliest. > > Environment variables are clumsy. Might you consider an alternative, perhaps > a "set_key(service, key)" function on the Finance::Quote object? > > Regards, > John Ralls > > > _______________________________________________ > gnucash-devel mailing list > [email protected] > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > > -- > David Carlson _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
