wf_user_info() can return "bad" info

[eliocamp]

For debugging I added a new user with username “user” and the same API key than “[email protected]”

keyring::key_list()
#>   service                 username
#> 1  ecmwfr [email protected]
#> 2  ecmwfr                     user
keyring::key_get("ecmwfr", "user") == keyring::key_get("ecmwfr", "[email protected]")  
#> [1] TRUE

But even though there's no "user" username, wf_user_info() still thinks is a valid username and returns information, albeit on the "eliocampitelli" username.

ecmwfr::wf_user_info("user")
#>   first_name code                      uid  last_name       full_name
#> 1       Elio  200 [email protected] Campitelli Elio Campitelli
#>                      email
#> 1 [email protected]

^{Created on 2019-03-19 by the reprex package (v0.2.1.9000)}

The ECMFW API seems to ignore the username part of the request and return the user information associated with the API key. In other words in this part of the code

  response <- httr::GET(
    paste0(wf_server(),
          "/who-am-i"),
    httr::add_headers(
      "Accept" = "application/json",
      "Content-Type" = "application/json",
      "From" = user,
      "X-ECMWF-KEY" = key),
    encode = "json"
  )

The "From" = user part is ignored (it works the same if commented out). One solution could be to validate the combination (even if ECMWF wont) by checking that the username returned by the API is the same as the one in the local keyring.

[khufkens]

Isn't this expected behaviour if the key is a unique identifier and the From part ignored?

The information which is returned is not bad, the only thing that might be helpful is clarify if the username in the keyring does not match the uid returned by the function. Ideally this should happen when setting the key.

if(df$uid != user){
 message("keyring id does not match ECMWF user id")
}

[eliocamp]

Yes, that's what I mean with "bad". From the user POV is unexpected because they mean to get info or use one user and then end up using another.

[khufkens]

You could not allow the key to be set if it doesn't work, using the above code and that for CDS to check before this happens (I would skip using wf_user_info() in this case). If the uid doesn't match the user call an error. Seems rough, but also not too bad.

[eliocamp]

Yeah, I think it's fair to enforce a consistent user/key combo.