Skip to content

Conversation

stramel
Copy link
Contributor

@stramel stramel commented Jun 17, 2020

Fixes #56

Based on https://gist.github.com/dperini/729294

Stripped the following checks from the above gist regex:

  • protocol (http, ftp)
  • short syntax (//)
  • basic auth (user:pass)
  • requirement for TLD (. made optional)
  • port number (:port)
  • resource path (/path, #resource-path)

Should now work for IPs, localhost, and valid domains

UPDATE: Since the generated certificates don't support IP addresses, I reverted the change and just simply modified the Regex to handle localhost and make it case-insensitive.

/cc @Js-Brecht

Based on https://gist.github.com/dperini/729294

Stripped the following checks:

- protocol (http, ftp)
- short syntax (//)
- basic auth (user:pass)
- requirement for TLD (\. made optional)
- port number (:port)
- resource path (/path, #resource-path)
@Js-Brecht
Copy link
Contributor

It doesn't seem to match any IP addresses. Of course, the generated certificates also don't support IP addresses, so maybe it's a good thing for it to fail early when an IP address is provided as hostname

/cc @zetlen

@stramel
Copy link
Contributor Author

stramel commented Jun 17, 2020

@Js-Brecht If we don't want to match IP addresses, we can probably just add the localhost support to the existing regex? You had mentioned IP addresses in #56

@stramel
Copy link
Contributor Author

stramel commented Jun 17, 2020

Could probably switch the regex to /(?:[a-z0-9](?:[a-z0-9-]{0,61}[a-z0-9])?\.?)+[a-z0-9][a-z0-9-]{0,61}[a-z0-9]/i and would probably work.

@Js-Brecht
Copy link
Contributor

I guess I did 😆. I think it will need to be done eventually, so maybe it will be good to have something on standby. Currently, though, the certificates generated do not use IP SANs. Didn't really think about that when I said it.

Could probably switch the regex to /(?:[a-z0-9](?:[a-z0-9-]{0,61}[a-z0-9])?\.?)+[a-z0-9][a-z0-9-]{0,61}[a-z0-9]/i and would probably work. Also, not sure if 0-9 should be in that first group?

Since, technically, domain names can have numbers in them, it makes sense to keep the 0-9.

That regexp works, but it also matches on just the first octet of an IP address like 127.0.0.1, since the final test, [a-z0-9][a-z0-9-]{0,61}[a-z0-9], requires a minimum of two characters in the last position. So IP addresses will pass the domain name check, but they won't actually be validated.

Maybe there should be a separate regex to match IP addresses, so that they can be matched prior to domain name validation? Then a friendly error could be generated to indicate that IP addresses aren't supported at the moment? Later, when they are supported, the condition could be changed to accept the IP, and a monolithic regular expression wouldn't have to be picked apart to ensure compatibility.

@stramel
Copy link
Contributor Author

stramel commented Jun 17, 2020

@Js-Brecht The regex no longer matches the octets of any IP. I also added a quick IPv4 regex and check that throws an error if an IP is provided.

Copy link
Contributor

@Js-Brecht Js-Brecht left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just something minor

Co-authored-by: Jeremy Albright <1935258+Js-Brecht@users.noreply.github.com>
@stramel
Copy link
Contributor Author

stramel commented Jun 18, 2020

Doh! Thanks, just did it quickly with the inline editor.

Copy link
Contributor

@Js-Brecht Js-Brecht left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it looks good, but it will have to wait for @zetlen to review before it can get merged.

Thanks @stramel

@stramel
Copy link
Contributor Author

stramel commented Jun 24, 2020

Ping @zetlen @davewasmer

@JustFly1984
Copy link

Is there any movement on the issue?

@stramel
Copy link
Contributor Author

stramel commented Jul 7, 2020

@Js-Brecht Is there any way to move this along? This is rather inconvenient to deal with at the moment.

@Js-Brecht
Copy link
Contributor

@stramel unfortunately, I don't have write access.

@zetlen I hate to bother you; I'm sure you're busy. This issue really is causing a lot of grief for Gatsby users, though. Would you mind taking a look at this PR so we can resolve these problems?

@zetlen
Copy link
Collaborator

zetlen commented Jul 7, 2020

I'm so sorry, folks! @Js-Brecht I have been on vacation for a week, but I'll look at this right now.

@zetlen
Copy link
Collaborator

zetlen commented Jul 7, 2020

Confirmed locally, this fixes the issue.

@zetlen zetlen merged commit 0386f33 into davewasmer:master Jul 7, 2020
@Js-Brecht
Copy link
Contributor

Welcome back @zetlen! Thanks for the merge 🚀; I'm sure everybody will be glad.

@zetlen
Copy link
Collaborator

zetlen commented Jul 7, 2020

@stramel @Js-Brecht Published v1.1.2 to NPM.

@stramel
Copy link
Contributor Author

stramel commented Jul 7, 2020

Thank you @zetlen! Sorry for bugging you on vacation!

@stramel stramel deleted the patch-1 branch July 7, 2020 23:35
@JustFly1984
Copy link

Ping @zetlen @davewasmer

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

Successfully merging this pull request may close these issues.

localhost is not a valid domain name
4 participants