FusionAuth / fusionauth-issues

FusionAuth issue submission project
https://fusionauth.io
91 stars 12 forks source link

Provide more detailed feedback during kickstart #574

Open atrauzzi opened 4 years ago

atrauzzi commented 4 years ago

Provide more detailed feedback during kickstart

Problem

While going through a kickstart, I ended up creating a lot of errors as I was manually authoring out the JSON.

Solution

Most of the errors I encountered would have been prevented by using JSON schema, it's well suited to helping with JSON based configuration experiences.

I think it would be amazing if a JSON schema was created for the kickstart format, and then that schema was used to power the error feedback during a kickstart. Also, that schema could be put somewhere well known for people to reference or use on their own :smile:

Alternatives/workarounds

Right now, it's trial and error and sometimes the reporting will just say that something is wrong, but not specifically where. As kickstarts grow, there's a tendency for everything to run together. Especially if one is unfamiliar with the schema and conventions.

How to vote

Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.

:heart:

robotdan commented 4 years ago

Thanks for the suggestion @atrauzzi . We do not currently have plans to add this feature to kickstart. Currently we do validate that we can parse the JSON, ensure that each API request contains the correct fields, and then provided API validation errors as output.

I do agree that adding more validation would be a nice feature. The design of Kickstart is to just delegate to each of the APIs, in other words we just call the APIs in order as they are defined in the kickstart file. If we were to provide additional JSON validation it may make the most sense to add it to the APIs and not to kickstart directly.

While not perfect, kickstart is essentially a language parser, it parses the kickstart file and builds an AST. We then use that to initiate the kickstart procedure. Syntax is critical in all programming languages, and it is difficult to fix all typos or errors. The same is true for each of our APIs, if you send in invalid JSON or missing properties, the API will fail with a validation error, the same is true in Kickstart.

The primary error that was the most difficult to identify in your case was the ${foo} variable in your URL segment which should have been #{foo}. Kickstart cannot validate this because ${foo} is a valid string and it does not know if that is a valid parameter for a particular API. The API has to validate this portion of the request.

Then because the API in question requires the URL segment value to be a UUID - the MVC tries to parse ${foo} (literal string) as a UUID and it explodes. This means we don't get to the API validation step because the MVC cannot properly form the request to map it to the correct handler.

This last piece is sort of a side effect of how we handle URL segments and UUID parsing, and it is current limitation of all of our APIs, unrelated to kickstart. In a more ideal scenario, the UUID parse would fail, and we would continue to the API validation step to provide additional information in the API response. At some point though we just take invalid input as invalid input and fail the request. However, this may be an enhancement we could make in the future to our MVC / API workflow.