Closed knaoe closed 11 months ago
Hi @knaoe ,
that's for that issue! Yeah, you're right, the current client-to-server connection doesn't really work out. When I was starting it was just the simplest solution the put a cors proxy in front of the admin-ui.
What is your idea to fix that design flaw?
@knaoe i tried something, could you please test following branch?
git checkout ft/reverse-proxy
cd kratos-admin-ui
docker build -t test .
docker run -p 80:80 --network kratos_intranet -e KRATOS_ADMIN_URL="http://kratos:4434" -e KRATOS_PUBLIC_URL="http://kratos:4433" --rm test
Note that kratos_intranet
is the docker compose network from the kratos quickstarter:
-> docker network ls
NETWORK ID NAME DRIVER SCOPE
ab66a132942b kratos_intranet bridge local
@dfoxg Thanks for the PR. I tried it out and it's really good! I hadn't considered a reverse proxy and was more focused on the SSR pattern. Your approach seems to be a smarter choice 👍
With this update, since it's a breaking change requiring users to tweak their environment variables, I'm kind of wondering if you should bump up the major version 🤔
Thanks for testing, I just released version 2.0.0🎉
My first thoughts were also in the direction of SSR, but I didn't want to add the big memory-foodprint of nodejs for this small admin ui. I think nginx just works fine for that use case :)
For security reasons, the admin endpoint should communicate only within the private network, and it will not be bothered by CORS problems. Is there any plan to achieve this instead of current browser to server connection? Or is the current architecture more advantageous?
If you don't mind, I'll contribute to this re-architecture.
version: v1.2.0