Conversation
|
|
|
Hold up, got some new test failures. |
...plus it fixes the tests
|
The chainsaw tests don't like it, likely because of what @zachsmith1 was telling me privately: a lot depends right now on the hostname matching the gateway UID. He's going to pick this up after he refactors the gateway. |
|
the built in security mechanism so that users can't create arbitrary hostnames using the shared domain is tightly coupled to the uid of the gateway. if we want to introduce something like this, we'd need to make sure that a gateway reserves a custom hostname (takes ownership over it) and that users can't directly attach any combination of hostnames using the shared domain. |
|
How do we guarantee that (users not being able to directly attach hostnames) with the gateway UID? |
|
if the hostname prefix doesn't match the gateway uid then its treated like a custom domain and would need to go through the domain verification flow. so in theory users can try to do this today, but we wont program that route downstream for them because they wont have ownership over our shared domain in their project |
|
OK, makes sense. I think we should consider a schema change that adds a hostname field where we take the UID and send it through the |
|
true, if we make the default https loop use that to confirm its an allowed hostname that could work |
This replaces the URLs that look like:
With ones that look like:
Note the comment that addresses the uniqueness of the strings:
https://github.com/datum-cloud/network-services-operator/pull/121/changes#diff-18034b184128f2f8ff3eb91d682aa4752f56f5bb5b010762c1239f2980c36440R17-R23