And here’s where the workaround comes into play.
The complete URL for a unique deploy will have the deploy ID prepended to the default subdomain — behavior that’s not completely unknown — thereby breaking the deploy URL’s RFC compliance. Navigating to such a URL will simply not resolve.
For the deploy URL be valid, the default subdomain needs to be at most
37 characters long, and the total deploy URL will be
63 characters in length; RFC compliant and therefore viewable:
This can therefore be exploited in the following way:
_redirectssyntax covers the
default subdomain ⟶ primary domainredirect
63 charactersin length
Resulting deploy URLs will be inaccessible, and navigating to the default subdomain itself will result in a redirect to the primary domain.
It’s important to note that this is ONLY applicable to edge-cases where access via the primary domain requires authorization, and access to the default subdomain and deploy URLs is undesirable.
One last thing: this kind of workaround breaks the preview and collaboration aspects of Netlify, and so local previewing and building (with the Netlify CLI used for deploying the build directory) would be the assumed workflow — in such aforementioned cases as private message boards, intranet sites, personal knowledge bases, etc.
Generalist. Edgerunner. Riding the wave of consciousness in this treacherous mortal sea.Technology Design Strategy Literature Personal Blogs
Results are from Blog, Link Dumps, and #99Problems