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

Joi.string().uri() accepts "https://" as a valid url #1732

Closed
papandreou opened this issue Feb 25, 2019 · 2 comments
Closed

Joi.string().uri() accepts "https://" as a valid url #1732

papandreou opened this issue Feb 25, 2019 · 2 comments
Assignees
Labels
bug Bug or defect
Milestone

Comments

@papandreou
Copy link

Context

  • node version: 10.11.0
  • joi version: 14.3.1
  • environment (node, browser): node
  • used with (hapi, standalone, ...): standalone

What are you trying to achieve or the steps to reproduce ?

I'd like to sanity check urls that my users enter, but Joi.string().uri() accepts a url without a hostname at all:

const schema = Joi.string().uri()
console.log(Joi.validate('https://', schema));

Which result you had ?

{ error: null, ...}

What did you expect ?

That a host name is required. It's not very helpful to allow "https://" in most scenarios.

None of the options for uri help with this.

It seems like it comes down to a very liberal regName regexp that also allows the empty string:

const regName = '[' + unreserved + pctEncoded + subDelims + ']{0,255}';

I understand that the idea behind rfc3986.js is to do a 1-to-1 translation of the URL RFC, and that reg-name is defined exactly like this in https://tools.ietf.org/html/rfc3986#section-3.2.2

... but I'll argue that it's very rare that you want to be that liberal in a validation scenario.

@WesTyler
Copy link
Contributor

In general Joi has made an attempt to stick to the RFCs as closely as possible. Sure, most cases are more conservative than the RFC "base validity", but as soon as we start arbitrarily putting additional constraints on top of the RFC we inevitably break a valid case for somebody.

That being said, perhaps there is room for some additional options to enforce host name constraints in a manner similar to .email()'s minDomainAtoms option.

@papandreou
Copy link
Author

papandreou commented Feb 27, 2019

Let's not do it arbitrarily, then 😏

Something like minDomainAtoms sounds usable. Even if it's not passed explicitly, it looks like isemail's default is that at least one domain atom is required: https://github.com/hapijs/isemail/blob/7cc347437efd93c7e2276ae59954d18f8f369475/test/index.js#L424-L434

I think that should be the default here, too, so we can avoid the "https://" case that is bound to take others by surprise :)

Edit: Sorry, that link didn't really illustrate my point as minDomainAtoms: 1 is passed. But isemail.validate does return false for localpart@ when no validation options are passed.

@hueniverse hueniverse added bug Bug or defect and removed request labels Jun 1, 2019
@hueniverse hueniverse self-assigned this Jun 1, 2019
@hueniverse hueniverse added this to the 16.0.0 milestone Jun 1, 2019
@Marsup Marsup mentioned this issue Jun 9, 2019
@hueniverse hueniverse added the v16 label Aug 10, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Feb 6, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Bug or defect
Projects
None yet
Development

No branches or pull requests

3 participants