https://www.ory.sh/ logo
Join Slack
Powered by
For self hosted Kratos, is it possible to set the ...
# talk-kratos
m
For self hosted Kratos, is it possible to set the UI base UI url in one place to allow for relative configuration of other URLs? The redirects seem to work based on the 
default_browser_return_url
, but if I have 
selfservice.flows.verification.ui_url=/verification
, my verification email redirects to 
KRATOS_PUBLIC_URL/verification
instead of 
UI/verification
. Any ideas?
I can of course set them in the individual options, but would be great to have it done with one option.
w
are you using oathkeeper? or are you using kratos standalone?
m
Currently using Kratos standalone - started evaluating first with it. Should I start with Oathkeeper as well?
I'm currently trying it with a Docker Compose based local setup, but if I get to deploying it, there will be Traefik involved as well, if it makes any difference with Oathkeeper.
w
i love ory. (just wanted to get that out first). things get complicated once you step outside of quickstarts. i get it though. their primary priority is to hosted/managed (read: paying) customers. that said, they still have pretty dang good documentation. i've not run into the issue you're seeing but that doesn't mean it's not an issue. ahh yes. now you're doing exactly what i have set up on my local (read: local network) while i plan for what i'm going to implement for the folks i'm working for.
I run traefik as my reverse proxy into my internal network (which routes ory/this related stuff either to oathkeeper, my custom (read: kratos-selfservice-ui-react-nextjs fork) or keto or hydra.
my keto is not exposed (directly) - i've just finished implementing some kind of api-key implementation that involves keto.
m
Maybe I need to add them as well. My main question was prompted mostly as I'm trying to find an easy way to reuse as much of the configuration between the local Docker Compose setup and deployment with K8s
w
that way, i can "guard" access to my checks since... well... listing the entire relation-tuple kinda gives away the api keys at least how naively i'm doing them.
ah. i avoid k8s whenver i can. =/
m
That's not a bad thing to do 😎
w
it's one of those things everyone absolutely loves or hates.
i'm indifferent - i just know the folks i work with and... um.. i had to go into detail why ROPC (resource owner password credential) grant was not going to seamlessly morph into authorization code grant just cuz you put some fancy lines on a sequence diagram and named the next stage of development phase 2.
and if that stuff is a foreign language to them. i don't really feel like going into overlay networks and proper security inside k8s.
but anyway
lemme look at what you're seeing and i'll get back to ya
it may be tomorrow. (sorry 😉 )
m
Thanks a lot!
w
so, what is 
UI/verification
?
OH also, default_browser_return_url does not correlate to the verification url in the verification email.
the return to url has to do with where you get redirected after a / any flow completes
and the generation of the links from within kratos will always use the KRATOS_PUBLIC_URL as the base.
cuz logically, that's the "public face of kratos"
m
Ah, UI=localhost:3000 and KRATOS_PUBLIC_BASE=localhost:4433
w
if using default i believe so yes
m
Yeah, that seems to work, but I'd prefer to be able to do 
/verification
instead of repeating 
localhost:3000/verification
for the verification UI
w
4433== kratos API. 4434 == kratos ADMIN api.
unfortunately, i don't think the relative thingie will work by design. (don't quote me on it) personally - i have each url in full for each ui_url
so it gets more complicated with "custom ui"
cuz the custom ui does some nice f*ckery with it's "proxy".
ie 
/api/.ory
anyway i'll check back in a few hours. stepping out for a bit
m
Thanks! I guess I'll go with the full url in each ui_url as well. It works fine, but just requires more repeating configuration variables for each environment, so not a fan.
12 Views
Open in Slack
PreviousNext
Powered by