Extended MFA api

[apamildner]

Proposed Changes

We can now update MFA policy and some settings regarding what provider and message type we use.

Fixes #199

Acceptance Test Output

$ go test ./management -v -run "TestGuardian/MultiFactor/Phone"
...
$ go test ./management -v -run "TestGuardian/MultiFactor/Policy"

Community Note

• Please vote on this pull request by adding a 👍 reaction to the original pull request comment to help the community and maintainers prioritize this request
• Please do not leave "+1" comments, they generate extra noise for pull request followers and do not help prioritize the request

[alexkappa]

Thank you for putting this together @apamildner! It looks pretty good apart from some minor things. Let me know when you'd like another review and I can merge this in.

[alexkappa]

I'm not sure if we should alias []string. Do you see some advantage to this, or did you take this as an example from a different method in this package?

[apamildner]

Good point. I just felt it looked more neat since almost all other methods use a struct type, so the method pattern looks similar for most of the api calls in the file. But we can go without it if you think it's better.

[alexkappa]

This is okay, but I'm wondering if we should apply the simplification we did in user blocks (see below). Do we expect any other fields to be present in the future for MultiFactorMessageTypes? If no we could return a []string from MessageType() and its siblings. WDYT?

auth0/management/user.go

Lines 225 to 232 in 40ec893

	type userBlock struct {
	BlockedFor []*UserBlock `json:"blocked_for,omitempty"`
	}
	type UserBlock struct {
	Identifier *string `json:"identifier,omitempty"`
	IP *string `json:"ip,omitempty"`
	}

auth0/management/user.go

Lines 399 to 403 in 40ec893

	func (m *UserManager) Blocks(id string, opts ...RequestOption) ([]*UserBlock, error) {
	b := new(userBlock)
	err := m.Request("GET", m.URI("user-blocks", id), &b, opts...)
	return b.BlockedFor, err
	}

[apamildner]

Hi! I'm sorry but I don't understand how this becomes a simplification. But to answer your question MultiFactorMessageTypes would not be expected to contain any other fields. I don't think it has any siblings, maybe the confusion lies in the name of the struct. I changed this in the latest commit.

[apamildner]

Hi! Any chance you can review this again? @alexkappa

[yvovandoorn]

Thanks for your contribution @apamildner. It looks like you addressed @alexkappa's concerns.

I've double-checked that tests run w/o issue locally. Merging!