https://www.ory.sh/ logo
Join Slack
Powered by
This message was deleted.
# general
m
This message was deleted.
s
the 
return_to
is the address to return after a successful login this request redirects you to the login UI url
b
Yes, but having the parameter here is needed to return to the url when going login > register. If you now do access a protected page, you get; • Redicted to /login, with propert return_to • If you now click register, you go to the register page, without a proper return_to, because the login page doesn't know about it. If you would visit 
/registration?flow=XXX&return_to=YYY
all works as expected
s
no, the 
return_to
is preserved on the backend did you try it?
b
Yes, if I do this; 1. access oauthkeeper protected page 
/abc
2. get redirected to login 3. I don't have an account yet, so click register 4. after register get redirected to default redirect url
If I don't click the register button all works as expected (aka directly log in)
But, if I now visit 
/login?flow=XXX&return_to=/abc
, the register button inherits the redirect param
s
in that case what happens is: 1. user is redirect to create a new login flow with the 
return_to
param 2. user is redirected to login UI with the flow ID 3. the login UI fetches the flow (FE or BE) and renders the page 4. user clicks on register and is redirected to create a new registration flow but without the 
return_to
param 5. user is redirected to the registration UI 6. ... now all you have to do is append the 
return_to
from the login flow to the registration button in the front end, it is included in the GET login flow response https://www.ory.sh/docs/reference/api#tag/frontend/operation/getLoginFlow
b
So this would then be a bug in the self service UI, as it doesn't call the 
getLoginFlow
?
s
it does, otherwise you could not login
I guess it depends on the use-case, as in some cases it might not be desirable to do that redirect
but yeah, it has to be implemented in the UI
b
It seems more ergonomic to me to append the 
return_to
next to the flowID and then either ignore or use it in the UI, prevents one extra HTTP request
s
you always have to fetch the flow anyways
there is no extra request
b
Ah I see
I see your point. From an end user perspective just using the self-service UI its slightly convoluted. If I need to login before accessing a page then regardless what login branch I take I would expect to end up on my original page
Since the self service UI inherits the return_to param from the request itself that's what made most sense to me
If at all it would be nice to have an option to reflect the return_to param in the 
/login?flow=xxx
url
Perhaps something like
Copy code
selfservice:
  flows:
    # global option
    append_return_to: true
    error:
      # ...
      append_return_to: true
    settings:
      # ...
      append_return_to: true
    recovery:
      # ...
      append_return_to: true
    verification:
      # ...
      append_return_to: true
    logout:
      # ...
      append_return_to: true
    login:
      # ...
      append_return_to: true
    registration:
      # ...
      append_return_to: true
s
I don't really see what the point is there?
b
It moves the return_to logic from the UI (i.e. to include or not include the return to), to the Kratos api server
s
the kratos server has no way to set the url because that button/link purely exists on the front-end see this example login flow https://determined-zhukovsky-qv355wsncl.projects.oryapis.com/self-service/login/flows?id=a9139283-0393-4839-9820-d2027e6371f7
4 Views
Open in Slack
PreviousNext
Powered by