Validation in Rocket

[somehowchris]

Hey :)

So, I've been using custom wrapping types like struct UpperCase(pub String) alongside some custom implementations of serdes Serialize and Deserialize which helped out a lot and following rusts Type correctness felt like a good approach. Sadly I have been struggling to validate the input as well as returning a reasonable error message.

I have come across rocket-validator which sadly doesn't seem to be maintained anymore and uses a kinda shady fork of the Json guard from rocket 0.3. It uses validator which seems nice and reminds me of the declarative way of class-validator in TypeScript (if that's good or bad is up to your opinion). So I had a go and tried to implement it as a crate in addition to rocket (keeping things out of rocket which aren't rockets main functionality) rocket-validation.

So what's the problem? Json in rocket implements the FromDataguard but not Validate (derived to generate the validate function on the structs). Offering FromData and Json implementations fails due to rusts compiler checking for implementations and hands out an error indicating that there is a duplicate implementation.
conflicting implementations of trait rocket::data::FromData<'>for typeValidated<rocket::serde::json::Json<>>``

TLDR; Validated<Json<T>> and Validated<T> are colliding as Json implements FromData, is there any solution to that? rather than baking this into rocket or at least the Validate derive behind a feature flag.

Things I have considered but failed:

• Fork or patch the implementation of Json => leaves another forked repository of rocket open in the wild
• Implement Validate for T on Json<T> => not allowed due to rusts crate system, would be needed in either rocket or validator crate

One thing I haven't tried due to my lack of knowledge: Use syn and quote to switch between T and Json<T> at compile time as rust would expand the generics into their own types. This rather seems complicated from what I have seen so I would favor a more state forward solution

I'm grateful for any hints and thank you for your help

[IniterWorker]

Hi @somehowchris,

I reimplemented the Json<T> in a new JsonDataValidator<T> and I don't have an issue with FromData.

I am struggling too with the same issue. How to deal with a custom error message? rocket documentation says ValidationErrors can't be carried by the Request<'r> and transformed into the registered handler.

Unlike route request handlers, catchers take exactly zero or one parameter. If the catcher takes a parameter, it must be of type &Request. The error catcher example on GitHub illustrates their use in full.

I am guessing we need some changes from rocket core.

Because we can't transform from the error handling, I am wondering if rocket_validation is an option for a project with the current rocket's state of the art.

Do you have any progress on your side?

B. r

[somehowchris]

Before anything else, it might not be the best point in time to have a project using it but its a good starting point to develop such a thing to see how rockets inner workings (though still on a relatively high level) work. I personally use it in some projects, but just with the Json type and for queries. Not optimal but at least requests are being validated, everything else can be documented :)

No I had no progress on that as I literally had no clue what to do, I removed the general FromData + Validate implmentation as if you would wirte some parser yourself you would also implemente Validated quickly with no real overhead.

I also came across ranking issues. If I have 2 routes with one ranked lower, it's error messages will be ignored as there is already something in local_cache. But I think both of the problems (responses from guards as well as this local_cache thing) are known to @SergioBenitez

[ondrowan]

Maybe a bit offtopic here, but there's also a problem with JSON syntax/data validation. The goals I have in the backend I'm currently developing are:

• If user passes malformed JSON, 400 should be returned.
• If user passes JSON with mismatched data types (or validation errors), I'd like to return something friendlier than string "invalid type: integer 1, expected a string at line 5 column 28". Preferably a JSON object with paths and better error descriptions - something like {"form_errors": [...], "field_errors": {"path.to.field": "Something errorneous happened"}}.

There are multiple problems that don't seem like they currently have a solution:

• While there's serde_json::Error::classify() that returns whether an error was caused by syntax, data or something different, it reports some false positives. E.g. if your handler expects an object and user omits the opening brace (e.g. "foo": 1, "bar": 2 }), serde_json fails immediately with "invalid type: string "foo", expected struct Foo". This happens because serde tries to fail fast and doesn't even look what follows after the initial string. While this is probably correct behaviour from performance standpoint, it's not very user friendly. There's a solution to deserialize into serde_json::Value which checks if the JSON is malformed and then deserializing this value to the real struct, which validates the data types. Of course, this will be slower than the default deserialization.
• Since serde doesn't track which property the error is coming from (again, for performance reasons), we end up with errors like "invalid type: integer 1, expected a string at line 5 column 28". There's a handy crate called path-to-error that helps with this, but also has some problems. E.g. the error reporting isn't as friendly as it could be. If an error happens, it returns it as a string "path.to.property: invalid type: integer 1, expected a string" which I have to parse since it's friendlier to present it in JSON. Again, this brings performance penalty since the paths are tracked even if there are no validation errors.

I wouldn't say that this issue is critical and I understand that serde's architecture values speed over user friendliness, but this feels like a problem that should be solved at some point since user friendly errors are something that's basically a standard in web APIs. This isn't also something that's going to be fundamentally solved on Rocket's level, but the solutions I've described could be at least considered (although I know that these requirements/problems might not apply to everyone and the best solution would be to write a JSON guard of my own). And maybe there's someone that found a better solutions than I have.

[IniterWorker]

I've described could be at least considered (although I know that these requirements/problems might not apply to everyone and the best solution would be to write a JSON guard of my own). And maybe there's someone that found a better solutions than I have.

Be aware, that there is no valid way from the request guard to act on the response. You could use an inner call in your route endpoint to compute validation and format the error output. It is not sexy... But I think it will be my way to go.

[the10thWiz]

I would recommend trying Result<Json<T>, Error>. I don't know off the top of my head what the error type should be, but you should be able to check the documentation for it. Then you can return a Json object with values from the error if an error occurred. Obviously this isn't ideal (I think the ideal solution would be catcher that can take the error type, but that's not currently supported). It's also possible you might be able to write a JsonError<T> guard that just calls the existing guard and reformats the error to produce the output you want.

[ondrowan]

Result<Json<T>, rocket::serde::json::Error<'_>> is what I'm currently using, but as you said, I'll have to either parse the errors and convert them to a more human-readable format or rewrite Json guard to use path-to-error. The latter seems to be more elegant solution, although it comes with a performance penalty.

[IniterWorker]

@the10thWiz, exactly the inner call will fail and use Result to generate the Response<>. For now, it is the only elegant way to do it.
@ondrowan, if you need rocket OpenAPI third-party library integration, I will advise you to create your own ApiResult<ApiSuccess, ApiErr> to help the implementation.

[vlio20]

Any updates on this topic?