accountId returned from b2_authorize_account shouldn't overwrite the one provided on init
Hornobster opened this issue · 9 comments
Line 54 in a13380b
When authorising the account, this lines overwrites the accountId that was provided as argument on init with the accountId returned from the authorize_account api.
This doesn't work when using other application keys, because the API returns the accountId of the master key and not the one provided.
This means that you cannot renew the authorizationToken when using keys other than the master key.
I'm now using a workaround (patched the authorize action function with my own).
Why is saving the accountId from the API actually needed if we need to provide it on init?
Good catch, submitted a PR to remove that line: #65. We shouldn't be overwriting any user-provided options, only adding the ones required to use the API.
The problem, if I can recall, is that when using B2 v2 API, you may not use the master key, but the API returns the account ID to use for subsequent API calls. I can provide more detail, but I would stress testing it in both scenarios (using the master key and using other authorized keys, with less privileges)
Don't you have to provide the accountId anyways? Why would you need to use the one returned from b2_authorize_account?
If I recall correctly, the one initially provided, which you call the accountID, per the docs, is the applicationKeyId, which can be a non-master key value. The API then returns a different accountId value to use with the subsequent calls.
Which doesn't work. You need to provide the applicationKeyId otherwise b2_authorize_account returns 401.
Have you used both a non-master key and a master key value and gotten the same doesn't work behavior?
No, I only use non-master keys. Renewing the authorizationToken wouldn't work because accountId was overwritten in the first call to authorize.
I'll point to my previous post:
#64 (comment)