Hello! I’m using development setup with self-generated root certificate and lots of domain certificates generated on top of it. So I almost never use port in favour of domain names which is not so far from producition environment.
On top of all docker services I have traefik which is set up to forward:
https ://api.kratos.local -> http ://kratos:4433
https ://admin.kratos.local -> http ://kratos:4434
https ://ui.kratos.local -> http ://secured-app # self service ui node
With next config ui-node works like a charm:
environment:
KRATOS_PUBLIC_URL: http ://kratos:4433/
KRATOS_ADMIN_URL: http ://kratos:4434/
PORT: 80
SECURITY_MODE: cookie
labels:
traefik.enable: true
traefik.frontend.rule: “Host: ui.kratos.local”
traefik.port: ‘80’
traefik.protocol: ‘http’
traefik.frontend.headers.SSLRedirect: true
Notice that they are on different domains! ui-node is https://ui.kratos.local and kratos-api is just http://kratos:4433. And it does work nicely. I’ve read “common cookie and csrf pitfails” and actually do not understand how that info affects my configuration - as for me there is no difference in domains because anyway ui-node should just re-assemble all requests and send them to kratos.
When I set ui-node to interact with kratos by it’s own domain with https:
environment:
KRATOS_PUBLIC_URL: https://api.kratos.local/
KRATOS_ADMIN_URL: https://admin.kratos.local/
PORT: 80
SECURITY_MODE: cookie
NODE_EXTRA_CA_CERTS: /usr/local/share/ca-certificates/internalone.ca.crt
volumes:
- '../../certificates/ca.crt:/usr/local/share/ca-certificates/internalone.ca.crt:ro'
networks:
- traefik
external_links:
- traefik:api.kratos.local
- traefik:admin.kratos.local
I encounter redirect loop. I can’t understand what causes it. Both configurations have kratos and app on different domain. And only one of them is working as expected.
Here is diff of docker (stdout) logs:
I can’t attach a diff of HAR request fragments from a browser debugger due to limitations for ne users. It contains strange data but it does not seem to be fery useful.
The latest response is just a redirect to ‘/auth/login’ while for the working config it is 200 with HTML response body. The preceding request diff is much more interesting - they are both identical redirects but the failing one has zero content size. The content itself is not visible for both cases in HAR exported from Firefox so it’s not very useful or I don’t understand it.
So inspecting requests does not seem to give any useful results. Looping redirects are just happening in one case and do not happen in the other one.
Maybe I can’t get some kind of a simple reason why it can’t work at all?