<@U011D3UQKNY>, <@U03HLFCQ3CN>, <@U01MTU9E4CF>, <@...
# talk-kratos
m
@magnificent-energy-493, @fast-lunch-54279, @proud-plumber-24205, @high-optician-2097 We have successfully completed our MVP and will be going live to production with our new ORY Auth service soon. Thank you for assistance thus-far šŸ™ We have one more scenario we'd like your input on:
1. We are going to launch our custom app to x.ourdomain.com, and we currently have the ORY Kratos Hosted instance running on y.ourdomain.com
2. This means that when we go live y.ourdomain.com/ui/* will have the built-in ORY Kratos UI visible to the public
3. Since y.ourdomain.com is just a CNAME record on our side to make the Custom Domain work, we don't have a server block or any files system to add things like
robots.txt
or deny access to certain routes (that I know of)
It is essential for SEO purposes that we are able to:
1. Disallow all indexing and bot traffic on y.ourdomain.com (The ORY hosted instance using the custom domain CNAME)
2. Disallow all public access to, and / or completely disable y.ourdomain.com/ui/*, without affecting the REST API endpoints at all
So my question is: 1. Is there an easy way to *disable the
/ui/*
path entirely* on the hosted Kratos instance? 2. If not, is there any way to block access to that route that you can think of, via ORY config or otherwise? We are running the CNAME using AWS Route53, via Terraform, if that helps Tagging my colleagues @important-area-42405 & @calm-agent-17042 for reference šŸ™šŸ––
PS: If we can: • get y.ourdomain.com/ui/* to redirect to x.ourdomain.com • or, get the hosted Kratos instance running on x.ourdomain.com/kratos, then that would work too, because then we can use the infrastructure on x.ourdomain.com to control public access to the routes
f
Great news, and thanks for raising this. I've created https://github.com/ory/network/issues/306 for this. I don't think there's a solution available right now, but the request makes sense and we'll discuss how to address it in the team
Please feel free to add comments to the issue
i
@fast-lunch-54279 Can we please elevate the priority for this ? Any eta to fix this issue. We certainly don't want to see a default auth experience which is not compatible with custom implementation and has SEO impact. Please treat this as high priority.
m
Thanks @fast-lunch-54279, I do appreciate the creation of the ticket, I have subscribed to notifications on the issue on Github šŸ™