Auth refactor for landing pages receiving absolute URL
Description
Today, our login page correctly does not support redirections to absolute URLs after a successful login.
However, we do have a few exceptions that require this kind of behavior (docs, assistant). Currently, we construct landing routes for those scenarios so that the consuming application can provide a relative path and be redirected to their corresponding absolute URL destinations. For example:
/landing/docs/ → https://docs.carol.ai
/landing/assistant → https://assistant.carol.ai
The idea is to remove the implementation from the consuming services (assistant or docs). They should provide the absolute URLs as the value for the redirect parameter, and during the login flow, we should validate if we have a landing page for that absolute URL and handle it appropriately from there.
01 - PERSON OF CONTACT (PERSON THAT CAN ANSWER QUESTIONS ABOUT THE PROBLEM):
02 - PROBLEM (WHAT'S THE ISSUE?):
03 - STEPS TO REPRODUCE (STEP (1...N), VIDEO, SCREENSHOTS, LOGS FOLDER, HEARTBEAT, ETC. – IF IS NOT POSSIBLE TO REPRODUCE EXPLAIN THE REASON):
04 - LINKS (ADD A LINK TO THE BUG OR TO THE TENANT):
05 - EXPECTED BEHAVIOR (LIST THE EXPECTED BEHAVIORS TO CONSIDER THIS BUG AS DONE):
- refactor auth landing pages to have a generic approach for redirects, receiving the absolute URL
- only support absolute URLs for known sites (for now, assistant and docs subdomains on carol.ai)