Support wildcards in origins

[leonardmq]

This PR adds support for wildcards in allowed origins, for example: https://*.example.com.

The specific use case for having wildcards is our PR previews, which run on random subdomains. I thought adding wildcards might be useful to others as well.

The implementation involves turning the origins into regular expressions:

• https://*.example.com -> ^https://[^ ]*\.example\.com$
• https://example.com -> ^https://example\.com$
• * -> ^[^ ]*$

The * special case is also turned into a regex, resulting in ^[^ ]*$, which matches everything so the special !allowedOrigins.includes('*') condition is no longer needed.

That being said, the added complexity of turning everything into a regex is a bit risky as edge cases can easily be overlooked - e.g. I almost forgot to escape the dots before generating the regexes, which would have caused https://evilexample.com to match for https://*.example.com.

[evert]

Hi @leonardmq, been a while, hope you are well!

Change looks great. I also had a look to see if anything else besides . had to be escaped. These are kind of edge cases, but in the case of ipv6 addresses there's also square brackets, for example... this will fail:

http://[::1]

That's probably another case that needs to be handled. Also an alternative would be to not use regexes and just expose a callback to allow users validate arbitrary hostnames. Either way works for me!

[leonardmq]

Hi @leonardmq, been a while, hope you are well!

Change looks great. I also had a look to see if anything else besides . had to be escaped. These are kind of edge cases, but in the case of ipv6 addresses there's also square brackets, for example... this will fail:

http://[::1]

That's probably another case that needs to be handled. Also an alternative would be to not use regexes and just expose a callback to allow users validate arbitrary hostnames. Either way works for me!

Apologies for the turtle-speed response here. Hope you are doing well too, been about a year and Curveball still delivering so far!

I agree the callback seems like a much better idea. The regexes are a bit too dodgy - a callback would be both more flexible and less risky. I'll push in the change to do the callback thing as soon as I have some time 🤓

[leonardmq]

@evert - I reverted my changes that used the regex and I implemented the callback way instead. Since the type checking was getting a bit scattered with the newly introduced possibility of allowOrigin being a function, I have also extracted some parts out into their own functions - I kept that refactoring to a single commit to keep the diffs clear.

Please let me know your thoughts. If you prefer this be a new PR instead of a continuation of the regex one, or if you want me to change the description and title of the PR to reflect what it is now, I can do that as well.