sjyangkevin commented on issue #55473: URL: https://github.com/apache/airflow/issues/55473#issuecomment-3288745259
Hi @pierrejeambrun , and @Steexyz, I would like to follow up here to get some feedback to see if I am on the right direction, since I wasn't able to get a failure test by using the given URL below. ``` https://hostname.cs-us-east1-rtep.cloudshell.dev/api/v2/auth/login?next=https%3A%2F%2Fhostname.cs-us-east1-rtep.cloudshell.dev%2Fapi%2Fv2%2Fauth%2Flogin ``` I also want to share the steps of how I attempted to identify the root cause, would appreciate if you could point out anything wrong below. First, if the issue is related to the `is_safe_url` function, I would expect if I properly update the test and use the given URL, the unit test should raise a test failure. So, I first start airflow in breeze environment and use some loggings to understand the parameters including `target_url` and `request`. As shown below. The `target_url` is `http://localhost:28080/` and the base url of the `request` is also `http://localhost:28080/`. The **url** of the request `http://localhost:28080/api/v2/auth/login?next=http%3A%2F%2Flocalhost%3A28080%2F` follows the same pattern as the given erroring url. <img width="839" height="661" alt="Image" src="https://github.com/user-attachments/assets/b6fc4a54-3688-4d07-aa7c-a4a62e69f321"; /> Then, I updated the `test_is_safe_url` to run a test for the localhost case. * set the `url` and `base_url` for the request mock to the value shown while running airflow. * set airflow configuration `section=api` and `option=base_url` to `http://0.0.0.0:8080` (I probably should set it to `None` because this parameter is commented in my airflow configuration. This value is the get from the `host` and `port`). * update the `url` in `pytest.mark.parameterize` to `"http://localhost:28080/"` which is the same as the `target_url` while running airflow. The updated test passed. Even though there is encoding for the url in the `next` param, but the `target_url` is not encoded when being passed into the `is_safe_url` function. <img width="1137" height="733" alt="Image" src="https://github.com/user-attachments/assets/6ff7c828-ee60-4b6e-a622-a5c87e21c7da"; /> After that, I follow the same approach to test for the given URL, and the test also passed. <img width="1137" height="733" alt="Image" src="https://github.com/user-attachments/assets/613dc9d0-040d-4201-88e0-258579643695"; /> Below is my airflow config for the `section=api`. ```cfg [api] # instance_name = enable_swagger_ui = True secret_key = GI9UlscGDGy3B/h2k/2HMg== expose_config = False expose_stacktrace = False # base_url = host = 0.0.0.0 port = 8080 workers = 4 worker_timeout = 120 # log_config = ssl_cert = ssl_key = maximum_page_limit = 100 fallback_page_limit = 50 access_control_allow_headers = access_control_allow_methods = access_control_allow_origins = grid_view_sorting_order = topological log_fetch_timeout_sec = 5 hide_paused_dags_by_default = False page_size = 50 default_wrap = False auto_refresh_interval = 3 require_confirmation_dag_change = False ``` Another thing probably is worth to notice that, when I access the browser debug tool. The URL in the `next` parameter is not encoded. But the one mentioned in https://github.com/apache/airflow/issues/55143#issuecomment-3275754077 is somehow encoded. I am wondering if there is anyway we could replicate the situation. If it is the case, it might be because the `target_url` is encoded but the `request.base_url` is not, and the `base_url` in the airflow configuration is not encoded, so it cannot be mapped to the same host. <img width="936" height="288" alt="Image" src="https://github.com/user-attachments/assets/4e4e936b-ca36-4779-8220-86e03b9ab83e"; /> <img width="1913" height="276" alt="Image" src="https://github.com/user-attachments/assets/e5b43d3a-216b-49cc-88ab-8887059f37ae"; /> Thanks. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
