https://www.ory.sh/ logo
Join Slack
Powered by
Hi, A week ago we've updated our custom domain `<h...
# ory-network
r
Hi, A week ago we've updated our custom domain 
<http://auth.staging.lhl.ca|auth.staging.lhl.ca>
to 
<http://auth-api.staging.lhl.ca|auth-api.staging.lhl.ca>
. Occasionally, the verification emails still generate magic links with the 
{{ .VerificationURL }}
set to the old domain name
https://auth.staging.lhl.ca/self-service/verification?code=....
What can we do to fix this?
s
Hm, what do you mean by occasionally? Do you have any reliable way to reproduce that?
r
Tried to find a way to reproduce it, but could find no pattern. It seems arbitrary, ~1/25 emails come with the old domain name for verification šŸ˜…
This is only on staging, we can live with it, perhaps it gets solved by itself with time, but thought I should let you know.
Still happening very consistently, without any replicable pattern šŸ¤· Some registration flows end up triggering a verification email with the old custom domain in the 
{{ VerificationURL }}.
s
@high-optician-2097 could that be related to some stale local cache somewhere?
h
Hm, I donā€™t think we have any type of caching here that would stay active for so long. I think that @narrow-van-43826 was working on making these links dependent on the hostname.
@rhythmic-musician-58953 I assume youā€™re using verification links and not verification codes?
r
Yes šŸ™‚
h
I have to be honest, Iā€™m really baffled by the behavior. Investigating it will probably take a bit of time
If you use codes this wonā€™t happen because they donā€™t have links
but we still need to fix the bug
r
Thanks for looking into it! Weā€™re about to launch Kratos auth for >1000 active students (+ a lot more alumni) in our LMS and this bug, alongside a few other ones, is not giving us good confidence in the product.
h
I totally understand, just trying to set expectations that this isnā€™t something we will be able to fix over the weekend! I tried to explain that thereā€™s a fix/workaround - the code strategy is the default one for new projects and generally encouraged by us to use because it has far fewer issues than magic links (works in outlook for example). So itā€™s a good idea to change to code strategy in any case! Regarding the specific bug, itā€™s hard to trace because itā€™s hard to reproduce. Since we donā€™t use caching in our configuration for that specific reason, it is very strange that his happens. Given two unknowns (a) not easily reproducible and (b) no clear concept of where the issue could be, itā€™s difficult to find.
Where should I go to test this myself? I tried 
<https://auth.lhl.ca/ui/login>
but that does not resolve for me
https://auth.staging.lhl.ca/ui/login also does not work for me
r
h
Ok so if I to verification using https://auth-api.staging.lighthouselabs.ca/ then it sends a link for auth-staging?
Is it the same project, or are they separate projects - if it is the same project, do you use the multiple cname feature?
r
It's one project, with the auth-api.staging.lighthouselabs.ca custom domain name, updated one week ago from auth.staging.lighthouselabs.ca The UI is self-hosted on our network
Sorry, the names are a bit confusing, let me know if it makes sense. 
auth-staging
is the front-endUI 
auth.staging
is the old custom domain that we updated to 
auth-api.staging
h
Ok I see
and in your app you always use 
auth-staging
when you redirect e.g. to login right?
ok, i can see that your project configuration has an invalid value
ā€œ<https://auth.staging.lighthouselabs.ca/>ā€,
is still configured as your base url for magic links
can you please try to do this:
Copy code
ory patch identity-config <your-project-id> \
  --remove '/selfservice/methods/link/config/base_url'
r
Yes, let me check this right away
h
ok i know what the problem is, it seems that there is a bug where if you update the custom domain, this particular value is not being set to the new custom domain correctly
which is why you end up with links that point to the old url
r
that makes a lot of sense
but I wonder why would only some of the magic links come with the old value?
h
that is still something we need to investigate
I think it has to do with a feature that we recently built. It improves this logic that you control with the value above and allows it to handle multiple custom domain (which is a business plan feature)
and i suspect that it correctly detects your custom domain and sets the link correctly, but itā€™s possible that this doesnā€™t work in a specific case. the question now is, what is triggering that specific case?
so this base_url is basically like the ā€œfallback valueā€ that is being used if our system can not make the decision itself (e.g. too many unknowns)
r
Copy code
ory patch identity-config <your-project-id> \
  --remove '/selfservice/methods/link/config/base_url'
after running this the base_url updated to the new custom domain
šŸ‘ 1
h
but i donā€™t know what could cause this on your end
are you maybe using the projects.oryapis.com domain somwhere? e.g. server side?
because for oryapis.com our super smart cname auto link detector doesnā€™t work, and just uses the project default
so that could be the issue here ā€¦
@wonderful-lamp-2357 this should probably go into the trouble shooting section until we have a fix?
r
we're not using oryapis.com anywhere, not sure what could it be. In any case, thanks so much for solving this so fast, it really makes a difference!
h
Glad we were able to resolve it šŸ™‚
w
@high-optician-2097 this case looks kinda similar to this one we have covered already: https://www.ory.sh/docs/troubleshooting/oidc-redirect-url-cname-OTA-092022-01
Iā€™ll add a doc thatā€™s more geared towards this case šŸ‘
h
šŸ‘
ty
r
@high-optician-2097 Should the 
selfservice/serve/admin/base_url
and 
selfservice/serve/public/base_url
in the identity config have the custom domain set as well? I'm seeing the 
<http://oryapis.com|oryapis.com>
URL
h
No, thatā€™s fine :)
6 Views
Open in Slack
PreviousNext
Powered by