App registration for the existing user fails due to non-nillable RegistrationRequest.User field

[vkorn]

When trying to create a new registration it's not possible set user to nil, resulting in default user's data being sent to /api/user/registration causing Fusion to treat this request as Create user+Register

{
	"generateAuthenticationToken": false,
	"registration": {
		"applicationId": "f252fdca-5cc6-42b9-b3d2-660008c08887",
		"roles": ["owner"],
		"verified": true
	},
	"sendSetPasswordEmail": false,
	"skipRegistrationVerification": false,
	"skipVerification": false,
	"user": {
		"passwordChangeRequired": false,
		"twoFactorEnabled": false,
		"verified": false,
		"active": false
	}
}

Since it's possible to access all rc client methods from outside the package, workaround is simple: just redefine structure with User *fusionauth.User json:"user,omitempty"`` and copy-paste Register call. But it would be nice to have this fixed in the package.

Thanks for the awesome product, btw.

[mooreds]

Hmmm. Based on my limited understanding of golang, it looks like we'd want to set the type of the User field in the RegistrationRequest to *User so it could be nillable and thus omitted when optionall. I think that would happen here: https://github.com/FusionAuth/fusionauth-client-builder/blob/master/src/main/client/_macros.ftl#L36 but would need to test it more (because I think we'd need to dereference the pointer elsewhere).

I would imagine this would be an issue for other request structs which have optional objects nested, such as ApplicationRequest.

[Tintwo]

I have exactly the same problem as vkorn. Method "Register" has 2 modes : user+registration or registration-only. But impossible to use the 2nd one, the client try to create an user (which is nil because we don't want to create an user but use an existing user id)

When I look here : https://github.com/FusionAuth/go-client/blob/91635102e9d79715c6867102f030edae4074dc3d/pkg/fusionauth/Domain.go#L2691 we can see this field shouldn't appear in the generated JSON body if not provided when we create the RegistrationObject (but apparently it does).

[mooreds]

Does the workaround mentioned above work for you @Tintwo ?

[Tintwo]

For now I dupplicate the Register method and change the RegistrationRequest by a custom one (without the user). It's a pretty similar workaround (dupplicate code :/)

[benkloester]

@mooreds we have run into this issue as well. We are pursuing the workaround for now but would be really keen to see the root cause addressed.

Also keen to understand whether we will run into the issue raised in #1576 or if the workaround avoids that problem.

Should we lodge a support ticket re this issue?

[robotdan]

@mooreds or @benkloester is this a simple change to how we are building the domain objects in go so that the User reference in RegistrationRequest is *User ?

https://github.com/FusionAuth/go-client/blob/028dacca67f0723ff390f0eaf53ef6b163a4373a/pkg/fusionauth/Domain.go#L4434

[benkloester]

That go-client is generated code, produced by fusionauth-client-builder, so the fix would really need to be in the builder or it will get clobbered.

From the answer he gave above it seems like @mooreds had an idea of where one of the necessary changes would be, but there was a bit more to be figured out and there was also a need to test any such change.