Closed andig closed 3 years ago
I think we should keep these components separate. They do two very different things and the client actually depends on having a token from its creation.
I wanted to be able to: reuse the context (and the contained http client, not yet implemented).
Internally, auth this is a separate component. From user perspective though it shouldn‘t matter if I create the client with token oder with u/p.
Happy to follow any other path though 👍🏻
I'm not opposed to this but I have a few observations:
WithCredentials needing to be the last optional argument seems brittle.
Fixed by moving the initialisation to the client creation.
I'm concerned that the options aren't really optional. It seems you must have both "options" for it to work, and in some circumstances may not be applicable at all. What if there's also a WithToken
thrown in there? What happens?
This mirrors https://pkg.go.dev/google.golang.org/api/option fairly well, aside from the complexity of the MFA login bit. What happens if you give Google APIs WithAPIKey, WithCredentials, and WithServiceAccountFile all in the same call?
// Without MFA
NewClient(ctx, WithCredentials(username, password))
// With MFA
NewClient(ctx, WithCredentials(username, password), WithMFAHandler(promptUI))
NewClient(ctx, WithCredentials(username, password, WithMFAHandler(promptUI)))
Is what is at debate now, correct? I'd rather have two ClientOptions than one ClientOption and one CredentialOption that needs to be passed.
What if there's also a WithToken thrown in there? What happens?
I had made this an error: https://github.com/bogosj/tesla/pull/37/files#diff-4b667feae66c9d46b21b9ecc19e8958cf4472d162ce0a47ac3e8386af8bbd8cfR54
I'm concerned that the options aren't really optional. It seems you must have both "options" for it to work, and in some circumstances may not be applicable at all.
Setting an MFA device handler is optional. If none is set and it turns out user has MFA enabled it will result in an error: https://github.com/bogosj/tesla/pull/37/files#diff-6b347a9043969a3ccadca7c26c658d5630226316770afecb2d6c9ac8355a9fbaR86
I agree it doesn't feel 200% nice but I couldn't find a better approach.
Is what is at debate now, correct?
It's an error currently which makes it very explicit.
Is there additional review needed here? We don't have an established norm for how / when / whom does merging. I added the other three contributors as reviewers but didn't really think through whether all or some or one of the reviewers approving was the appropriate signal for "go ahead and merge" :)
@michaelharo do you have any opinions on the PR?
@uhthomas any additional thoughts?
I‘d be happy with any solution, doesn‘t need to be this one
I'd like coherence check on the potential panic when not providing a device selector for an MFA account.
Perfect, thank you.
Comments fixed. Feel free to squash and merge.
I've merged, given the approvals above. We have not agreed on a process, should we follow that? How many approvals to we need?
Fix #22.
This is still too convoluted but it should give an idea how it could look:
WithMFAHandler
will set the device handler for MFA, if omitted MFA is not supportedWithCredentials
option will trigger the login and must be the last optionI'm using it like this:
Comments welcome.
/cc @uhthomas