V6 client controller should not return success response on no User-Id header

[ppratikcr7]

Version where bug was found:
e.g "6.0"

Describe the bug
V6 client controller should not return success response on no User-Id header

[zackcl]

QA: Passed.

It looks like, currently, we allow passing a user ID for /api/v6/init in either the body or the header of the request, whereas we don't allow passing the user ID in the body for /api/v6/featureflag and /api/v6/assign. Is this expected behavior, or should we not allow passing a user ID in the body for consistency? @ppratikcr7 please create a ticket.

[ppratikcr7]

QA: Passed.

It looks like, currently, we allow passing a user ID for /api/v6/init in either the body or the header of the request, whereas we don't allow passing the user ID in the body for /api/v6/featureflag and /api/v6/assign. Is this expected behavior, or should we not allow passing a user ID in the body for consistency? @ppratikcr7 please create a ticket.

So, the problem is that the validators we are using in our controllers, just verify if the custom validatorType keys are in desired format, but if any other keys we pass through the body will not give validation error. For that we need to look for strict validations. For /api/v6/featureflag and /api/v6/assign we do allow passing id's but the user id is not returned in the response, so you might think that user ids are not allowed in them. In /api/v6/init, it takes id from the body as we do consider the id, group and workinggroup from body or either header. Will update that part.