Default user

[eliocamp]

I was thinking that for the common use-case of people with only one user for each service, it would be great not to need to pass it as an argument; especially for CDS, in which the username is a hard-to-remember random number.

Searching the keyring to see if there's only one user for the selected service is easy to implement. But from what I've seen in the code since the service is actually selected based on the user supplied, I've ran into a bit of a chicken-and-egg situation and I'm not sure how to proceed.

Any ideas?

[khufkens]

On a user missing you could cycle over all users + requests using wf_check_request(). I see that the current combo actually has a bug (non critical). Lacking an error trap on the wrong service in the request function, and only returning NULL not an error.

In any case, you can use the function to figure out what service belongs to which account. Or that's the goal, might not be totally solid yet for the above purpose.

https://github.com/khufkens/ecmwfr/blob/a6c5070bc60c6dfbe5295ec42aa1c27a772dd020/R/wf_request.R#L71

[eliocamp]

I though of that, but is it kosher to make requests with every user in the case of multi user setup? Although I guess that if the user doesn't supply a specific username then it's fair. In a few days I'll work on it!

[khufkens]

I don't think many users will share the same encryption key (multiple cds / webapi accounts on the same keyring). When a different user on the same system with ecmwfr uses their system login it will query their personal keyring to retrieve login info. This is part of the point if the keyring setup, discrete separation (and encryption) of these credentials.

So at most users would have (currently) two logins to validate (or one to exclude). I'm rather confident that over time we will have to add another for the atmospheric products in addition to CDS if these aren't consolidated, but these are worries for later (but the reason to keep services separated).