Would be nice if there where some validators to usual command line input. The most basic ones would be to check if a file or directory exist or a glob pattern matches anything. Maybe also some validators to do something with networking (url's). Don't know what else would be useful for cli

I'm trying to have just a "greater than" validation (must be > than 0).

#[validate(range(min = "1"))]

Fails with

Validator `range` requires 2 arguments: `min` and `max`

From the readme:

It currently only works on nightly but should work on stable in Rust 1.15.

This is not true right? The proc_macro feature will be stabilized but this library currently relies heavily on attr_literals as well which I have not seen plans to stabilize so far. The tracking issue is rust-lang/rust#34981.

Hi,

I maintain a library for parsing domain names and email addresses called publicsuffix. The library is already stable and has a tonne of tests. Would you be interested in using that as your backend for validating email addresses and domain names? If so, I would be happy to submit a pull request if you don't mind.

Kind regards,
Rushmore

i'd prefer not to pull in the card-validate dependency; i don't need it at all for 99% of the things i use this lib for.

It is often useful to represent a struct's string fields with the Cow<'a, str> type to handle borrowing efficiently. The pattern is well described in the From &str to Cow article by Jow Wilm.

It would be equally useful if the validators in this library that operate on string types also supported fields declared as Cow<'a, str>.

In stable Rust, trying this example:

#[derive(Debug, Validate, Deserialize)]
struct SignupData {
    #[validate(email)]
    email: String,
}

I get this error:

  --> src/main.rs:11:17
   |
11 | #[derive(Debug, Validate, Deserialize)]
   |                 ^^^^^^^^ the trait `std::convert::From<&std::string::String>` is not implemented for `std::borrow::Cow<'_, str>`
   |
   = help: the following implementations were found:
             <std::borrow::Cow<'a, std::path::Path> as std::convert::From<std::path::PathBuf>>
             <std::borrow::Cow<'a, std::path::Path> as std::convert::From<&'a std::path::Path>>
             <std::borrow::Cow<'a, str> as std::convert::From<&'a str>>
             <std::borrow::Cow<'a, [T]> as std::convert::From<&'a [T]>>
           and 4 others
   = note: required because of the requirements on the impl of `std::convert::Into<std::borrow::Cow<'_, str>>` for `&std::string::String`
   = note: required by `validator::validate_email`

Thanks

Hey, I was wondering what the reason for making field_errors() take self was?

I have some code that needs to call it on a borrowed ValidationErrors instance, and have resorted to doing an explicit clone() beforehand. But it seems like it would work just as well if it took &self instead. Am I missing something / would you consider a change to the API?

#[macro_use]
extern crate validator_derive;
extern crate validator;

use validator::Validate;

#[derive(Validate)]
pub struct Foo {
	#[validate(length(min = "1"))]
	pub name: String,
	#[validate(range(min = 0, max = 120))]
	pub age: Option<i32>,
}

yields

Invalid attribute #[validate] on field age: Validator range can only be used on number types but found Option<i32>

Using Validator 0.4.0

I was wondering if it was at all possible to provide a message into the validate macro that could be used when returning a response back to the caller. The caller then could just essentially present the message to the user without needing to "know" the error code. Something like this maybe:

#[derive(Validate)]
pub struct Something {
    #[validate(length(min = "3", error="Must be at least 3 characters long"))]
    pub name: String
}

I don't know enough about macros 1.1 to know if this is even feasible but it would keep a user friendly error bundled with the validate declaration.

Plausible or not?

Not sure if it even make sense to be honest, I had

pub fn validate_must_match<T>(a: T, b: T) -> bool
    where
        I: Eq,
        T: Into<Option<I>>,
        T2: Into<Option<I>>,
{
    let a = a.into();
    let b  = b.into();
    if a.is_none() && b.is_none() {
        return true;
    }
    if !(a.is_some() && b.is_some()) {
        return false;
    }
    a == b
}

before removing it

I haven't used your library yet, but it looks nice—

However, one of the primary validations I would want to perform on my structs would be Option::is_some, basically to check whether a builder-style struct is in a valid state.

It looks like the custom validator won't work here, since that is only run on the inner value in the Option::Some case.

I understand why you've designed it so validators are only run on options if Option::is_some, but it would be nice to have either an is_some validator or a custom validator that runs on the raw value.

From #73

// for length from 5 to 10 (10 is excluded)
#[validate(length(5..10))]   

// for length from 5 to 10 (10 is included)
#[validate(length(5..=10))]

// for length equal to 5
#[validate(length(5))]

To replace min/max/equal.

Thoughts?

I want to have a validator that works like length but uses the byte length of a string (or rather, the length after converting utf8 to cp852).

How can I pass the len arg to that custom validation function?

Seeing https://blog.rust-lang.org/2019/04/11/Rust-1.34.0.html#custom-attributes-accept-arbitrary-token-streams maybe we can?

The next branch is using attr_literals already

Sometimes fields can ok individually but might be invalid when looking at the whole thing, for example 2 fields are optional but at least one of them has to be there

Allowing a custom function on the struct itself is necessary

In the following example, an incorrect postal_cd is provided. I expected validate() to raise a ValidationError but instead returned Ok(()). Is this a bug?

extern crate validator;
extern crate failure;
#[macro_use] extern crate validator_derive;

use validator::{Validate, ValidationError};
use failure::Error;

#[derive(Validate)]
pub struct Address {
    pub street: String,
    #[validate(length(min = "1", max = "5"))]
    pub postal_cd: String
}

#[derive(Validate)]
pub struct PartyInfo {
    #[validate(length(min = "1", max = "5"))]
    pub first_name: Option<String>,
    #[validate(length(min = "1", max = "10"))]
    pub last_name: Option<String>,
    pub address: Option<Address>
}

fn main() -> Result<(), Error>{
    let addr = Address {street: "123 main st".to_string(),
                        postal_cd: "0703000000000000".to_string()};
        let party = PartyInfo {first_name: Some("Darin".to_string()),
                           last_name: Some("Gordon".to_string()),
                           address: Some(addr)};
        let check = party.validate()?;
    println!("check is: {:?}", check);

    Ok(())
}

It might remove the need for serde-json https://github.com/dtolnay/erased-serde

Why does this work? I am using validator = "0.6.3" and validator_derive = "0.6.5", rustc stable 1.25

#[derive(Validate)]
struct Something {
    field_a: String,
    #[validate(length(min = "1", max = "10"))]
    field_b: String
}

fn main() {
    let something = Something {field_a: "hello".to_string(),
                               field_b: "helloooooooooooooooooooooooooooo".to_string()};
}

Can we do something like the failure crate? This would be a bit more ergonomic to use the lib.

Obvious follow-up to #4 I guess.

I know this is more user-friendly: #[validate(range(min = 18, max = 20))]

But would it be possible to support this as well? #[validate(range(min = "18", max = "20"))]

And similar for the other validators. This would allow validators to be used on stable Rust 1.15.

It looks like this may be as simple as just extending the lit_to_int and lit_to_float functions to handle string literals.

So we can represent them consistently with validation error

http://docs.pylonsproject.org/projects/colander/en/latest/extending.html#defining-a-new-validator

They got new versions with breaking changes so it might take some time

Need to figure out how to make it without having to compile the regex everytime.

A few possible choices:

• pass an ident to the regex(ident=X) attribute and expect that to be a Regex object
• use lazy_static inside the generated impl but that requires the end user adding lazy_static manually to their dependencies (afaik)

they would only be ran if the value is Some.
Will be useful for PUT request for example where almost everything is Option<>

Trying out the example in the read me and I get this error.

Hi!

There is no point to allocate memory each time for a String value, much frequently we will need an &'static str value and only in rare cases we will need to allocate String for custom values.

for validate:

Result<(), HashMap<String, Vec<String>>>

=>

Result<(), HashMap<Cow<'static, str>, Vec<Cow<'static, str>>>>

or even

Result<(), HashMap<&'static str, Vec<Cow<'static, str>>>>

for custom validation functions respectively:

Option<Cow<'static, str>

So the temp email providers are considered an error.
There is https://github.com/FGRibreau/mailchecker/tree/master/platform/rust but it might be simpler/better to write a separate crate that only checks the domain and not try to validate the emails themselves.

See https://github.com/martenson/disposable-email-domains for a blacklist

When using a range or length validator I want to display the min and max args in the error but in a different language, how to do that?

instead of on the derive, not sure whether it's doable

For example when checking unique username, it will need a db connection.

No clue how to handle that yet!

#[derive(Deserialize, Validate)]
pub struct Foo {
  #[validate(range(min = "10", max = "100"))]
  bar: u32,
}

fn index(body: Validated<Json<Foo>>) {  ... }

Validated would be a pub struct Validated<T>(T) wrapper struct that implements actix_web::FromRequest and returns a 422 on validation errors with a nice response body describing errors.

If this is something you feel should be included I'd love to contribute a PR here.

It is not an issue, maybe a feature request

But how can I get validation rules, to use them in frontend (js) ?
Any format of validation rules will suit me.

And if there is a custom validation - I just would like to know that field have custom validation also and that'it

Forward thank you for any your reply

Let's say I'm deserializing to a parent struct whose fields are other structs, which implement Validate. I hoped that if I called validate() on the parent, it would automatically call validate() on its nested structs. But this code prints out "validated!", even though Bar is invalid:

#[macro_use]
extern crate serde_derive;
extern crate toml;
#[macro_use]
extern crate validator_derive;
extern crate validator;

use validator::{Validate};

#[derive(Deserialize, Debug, Validate)]
struct Foo {
    bar: Bar,
}

#[derive(Deserialize, Debug, Validate)]
struct Bar {
    #[validate(range(min = "0", max = "9"))]
    y: i32
}

fn main() {
    let foo: Foo = toml::from_str(r#"
    [bar]
    y = -1
    "#).unwrap();

    match foo.validate() {
        Ok(_) => println!("validated!"),
        Err(e) => println!("{:?}", e),
    };
}

I can't figure out a good way to explicitly call validate() on the nested struct, either. I tried adding a #[validate(custom("Bar::validate"))] attribute to the bar field, but that resulted in error: proc-macro derive panicked.

Is there any better way to validate nested structs than to implement my own method for Foo that manually calls validate() on every field?

It would be nice if the Validate trait could provide access to the validations used on a struct. (Ex, a hashmap of Vecs of Validator.)

Give the Validator enum Serialize and now you can serialize it to json and pass it to a front end app to share validations. :D

The range validator requires the raw numerical value in quotes. It should let it be a variable name in scope as well (or instead).

Thanks for the awesome work, love this crate.

With macros 1.1 now becoming stable, do you have any plans to port this over?

That would allow use on stable!

This is basically cross-linking the whole discussion at serde-rs/serde#642.

It would be nice to have this crate and serde team-up to provide some way for performing a validation pass as the last step of deserialization. For simple average-case scenarios, I'd like to avoid explicitely calling validate() on a struct that has just been deserialized by serde.

The usecase for this is to automatically ensure that a struct is guaranteed to be either valid right after deserialization or to fail it, in order to avoid invalid states between deserialization and validation (or worse, missing validation at some call sites).

Hey, I put together a small example of how to use macros to conduct parameterized testing, with an example using the validator crate. Would you like to add this to the validator project? https://github.com/Dowwie/parameterized_testing

If so, it's yours

Compiling card-validate v2.1.2
error[E0554]: #[feature] may not be used on the stable release channel
 --> /Users/greg/.cargo/registry/src/github.com-1ecc6299db9ec823/card-validate-2.1.2/src/lib.rs:4:1
  |
4 | #![feature(inclusive_range, range_contains)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Looks like one of validator's dependencies, card_validate, cannot compile on Stable Rust. What's the best way to fix this?

Which makes it quite inconvenient and unintuitive to use the result of Validate::validate with the ? operator. While a trivial implementation of std::error:Error would probably suffice, I'm not sure about the implementation of std::fmt::Display.

There also seems to be a mistake in README.md:

let errors = signup_data.validate()?;

According to

Though validation works on Option<T>, it would be beneficial if the same logic would work on Option<Option<T>>.
To communicate with the JS world with null, undefined & T, I need to use Option<Option<T>>. And to validate it, currently I am using custom validation.
So, this is a feature request to make it built-in.

Some issues with path resolution for regex and functions

• string: pretty obvious
• hashmap: whether it contains the key given (limit to String key?)
• vec: whether it contains the value given -> seems too much trouble for something NOT very useful (it would need to take a path to a variable, which sucks if you want to check for an integer or something similar)

Does support for attr_literals still require a nightly build? If so, which rust RFC must be addressed before nightly is no longer needed?

Right now it only returns the error code for the validation that failed, which is enough for me as I usually have control of both frontend and backend and just want to know which bit failed on which field.

However, having some more verbose error or user-defined ones (or both) would be welcome.
For example when sending error message to a third party doing an API calls or if you don't control the frontend and need to send all the info (args used for the validator) to it.

A few things to consider:

Serialize validators

Change the error type of validate from Result<(), HashMap<String, Vec<String>>> to Result<(), HashMap<String, Vec<Validator>>> and have Validator manually (so we can add their name) implement Serialize from Serde.

Pros
That's the easy option since this way we will get the name of the validator and all its args easily
Cons
Doesn't really work if we want custom error messages

Custom message

Add an optional error_msg field to every single validator that will be sent with the error code. Sending only the error message makes it less flexible wrt if the frontend wants to change it, so we should it still have both error code and error. Error type will be Result<(), HashMap<String, Vec<(String, Option<String>)>>>

Default error messages

A neat way to do that would be to impl a function on Validator that returns a default error message. I would ignore i18n in default error messages as I don't think it will provide a good end user interface since end users will end up with errors like "Bank account number must match [0-9]{7}" or something like that that I got today with Transferwise.
Proper error messages should be built by using the serialized validators in the frontend or just overwritten in the backend directly. There are also too many format for i18n and afaik not library for it in Rust yet.

The user could iterate on the errors hashmap or we could even impl a function on the hashmap directly so the user can do something like if they just want a hashmap with error messages:

match signup_data.validate() {
   Ok(()) => (),
   Err(e) => return e.get_error_messages()
};

which could be turned into a validate_or_error_messages! macro easily

If that approach works, it could be extended to transform errors into i18n objects potentially

Current thoughts

I like the idea of serializing validators and having default error messages if wanted but I'm not sure where the custom error messages fit in that system. Ideally we'd have String | Validator as type for the value of hashmap but that's not possible in Rust. Another option is (Validator, Option<String>).
The main issue would be what to do with the custom validator since you can have multiple kind of errors and how to work with serialization errors if we decide to let validator handle those (for consistent errors)

Hi,

Is there a validator similar to Go's validator.v9 Required, which validates the value is not the data types' default zero value?

Thanks

Why doesn't Option<String> work? Shouldn't it work in v0.6.3?

#[validate(regex = "RE_TIME")]
automatic_closing_time: Option<String>,