Unable to pass {username} with slashes to Airflow REST API

[wilsonhooi86]

Apache Airflow version

Other Airflow 2 version (please specify below)

If "Other Airflow 2 version" selected, which one?

2.8.1

What happened?

MWAA has announced that we can now use Airflow REST API. The goal is to use REST API Patch User to add/remove users' roles programmatically.

MWAA create username with a prefix of assumed-role/ for each user login. Example {username}: assumed-role/user1 .

API Template URL: https://airflow.apache.org/auth/fab/v1/users/assumed_role/{username}
Actual URL: https://airflow.apache.org/auth/fab/v1/users/assumed_role/assumed-role/user1

As we call the Airflow REST API https://airflow.apache.org/auth/fab/v1/users/assumed_role/assumed-role/user1 , it will show below error:

{
"detail": "The requested URL was not found on the server. If you entered the URL manually please check your spelling and try again.",
"status": 404,
"title": "Not Found",
"type": "about:blank"
}

We believe the REST API render the slash as an URL path.

Question is, can we enhance the Airflow REST API to accept slashes in URL parameter?

What you think should happen instead?

Airflow REST API able to accept slashes in URL parameter. Example:
username: assumed-role/user1
https://airflow.apache.org/auth/fab/v1/users/assumed-role/user1

How to reproduce

Please refer to What Happened? section

Operating System

MWAA

Versions of Apache Airflow Providers

No response

Deployment

Amazon (AWS) MWAA

Deployment details

I am not sure that this issue is specific to the service provider.

Anything else?

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[boring-cyborg]

Thanks for opening your first issue here! Be sure to follow the issue template! If you are willing to raise PR to address this issue please do so, no need to wait for approval.

[Taragolis]

Airflow REST API able to accept slashes in URL parameter. Example:

It shouldn't. / have a special meaning for separate paths in URI.
Instead of that it should work with url-encoded values, did you try to provide assumed-role%2Fuser1 instead?

[github-actions]

This issue has been automatically marked as stale because it has been open for 14 days with no response from the author. It will be closed in next 7 days if no further activity occurs from the issue author.

[wilsonhooi86]

Airflow REST API able to accept slashes in URL parameter. Example:

It shouldn't. / have a special meaning for separate paths in URI. Instead of that it should work with url-encoded values, did you try to provide assumed-role%2Fuser1 instead?

Hi @Taragolis , yes, I tried to pass in as assumed-role%2Fuser1 but it still parse as "/" in the url and produce the same error as below:

{
"detail": "The requested URL was not found on the server. If you entered the URL manually please check your spelling and try again.",
"status": 404,
"title": "Not Found",
"type": "about:blank"
}

[jaklan]

@Taragolis any hints how to resolve that issue? Also encounter that problem on MWAA because of assumed-role/ prefix

[uranusjr]

IIRC this is a restriction in WSGI and shared by many Python web frameworks, including Flask (backing Airflow) pallets/flask#900

There’s probably no good way to resolve this from the webserver level.

[jaklan]

@uranusjr if usernames wish slashes are not supported by API (and won't be), they should be simply not supported at all then

[uranusjr]

I just checked and it seems like even ASGI frameworks have this issue too. ASGI has since added raw_path to support this, but FastAPI is not using it when routing requests. (More accurately, Starlette is the layer that actually handles routing.) So I think we’ll have to consider this as impossible at least for the foreseeable future.

I’ll close this and propose a PR to add a note in the documentation.

refs
fastapi/fastapi#7858
encode/uvicorn#261

[jaklan]

@uranusjr what about a proposal to disallow usernames with slashes instead of "note in the documentation"? If it's not compatible with Airflow REST API - I don't really see why it should be supported.

[uranusjr]

The problem is the username can be supplied from anywhere (the auth manager is pluggable), so we can’t block them at creation, only when they are used in Airflow. The username is also only unusable from the REST API. I anticipate many people are already using those usernames “just fine” from the Airflow UI, and disallowing them would break all their setups.

[jaklan]

@uranusjr sure, I'm aware of backward-compatibility issues, but maybe it would be rationale to deprecate it in Airflow 3.x?

The username is also only unusable from the REST API

I would say it's a 🚨, not "only" 😉