Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Illuminate\Validation\Validator::getCustomMessageFromTranslator() is inefficient #11512

Closed
halaei opened this issue Dec 24, 2015 · 3 comments
Closed

Comments

@halaei
Copy link
Contributor

halaei commented Dec 24, 2015

It sounds like that the time complexity of this function is linearly proportional to the size of validation.custom array. I think this is not OK. Suppose you have a 100 custom rules, which I consider normal, and a user sends you 100 invalid data. In this case there can be 10000 comparison against keys in validation.custom. I guess that even can be regarded as a security issue, because the CPU usage of Laravel app will be 100x the CPU usage of the attacker.

@GrahamCampbell
Copy link
Member

Thanks for bringing this up. We're open to PRs if you want to have a go at improving this.

@halaei
Copy link
Contributor Author

halaei commented Dec 25, 2015

One way to do this is to use to parse trans files into a trie data structure once, and then query it every for multiple times, if required.

I think we should have a benchmark before any try to fix. Maybe there is no problem at all, or maybe a try to optimize do the opposite.

Another thing in my mind is that, maybe, the following style does not worth the extra effort for writing custom validation messages/attribute trans:

'custom' => [
    'person.*.email' => [
        'unique' => 'Each person must have a unique e-mail address',
    ]
],

instead, why not doing this:

'custom' => [
    'person' => [
        '*' => [
            'email' => [
                'unique' => 'Each person must have a unique e-mail address',
            ]
        ]
    ]
],

@halaei
Copy link
Contributor Author

halaei commented Feb 13, 2016

@GrahamCampbell sounds like you closed this issue mistakingly.
That pull request has nothing to do with this issue. Am I right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants