Logging out from Web UI raises Airflow 405 error

[Al2a2d2m]

Apache Airflow version

2.9.2

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

No response

What happened?

On airflow web UI, connected as admin, when I try to logout, airflow raises invalid request exception and the session keep going.
capture :

What you think should happen instead?

logout process needs to complete correctly

How to reproduce

connected as admin and try to logout

Operating System

NAME="Red Hat Enterprise Linux" VERSION="8.9 (Ootpa)"

Versions of Apache Airflow Providers

apache-airflow-providers-common-io==1.3.2
apache-airflow-providers-common-sql==1.14.1
apache-airflow-providers-fab==1.2.0
apache-airflow-providers-ftp==3.10.0
apache-airflow-providers-http==4.12.0
apache-airflow-providers-imap==3.6.1
apache-airflow-providers-jdbc==4.3.1
apache-airflow-providers-postgres==5.11.2
apache-airflow-providers-sftp==4.10.2
apache-airflow-providers-smtp==1.7.1
apache-airflow-providers-sqlite==3.8.1
apache-airflow-providers-ssh==3.11.2

Deployment

Virtualenv installation

Deployment details

No response

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.

[potiuk]

This is a bug/incompatibility in the new FAB provider 1.2.0 after implementing #40145 - seems that Airflow 2.9.2 (and before) is not compatible with the new POST-only requirement of FAB provider.

This is a problem only if you do not use constraints (that's what highly recommended in https://airflow.apache.org/docs/apache-airflow/stable/installation/installing-from-pypi.html ) - if you do not want to use constraints, you should downgrade/pin apache-airflow-providers-fab to 1.1.1 and it should fix your problem. That's a quick workaround for now until we fix it.

CC: @shahar1 : we need to find a good solution for back-compatibility - and I am not sure if we can do it for earlier Airflow versions - because Airlfow 2.9.2 and below will call the "/logout" method via GET and without CSRF. I think what we should do is to add a back-compatibilty code in logout - and allow "GET" method if airflow version <= 2.9.2

[Al2a2d2m]

@potiuk, I'm aware about the the use of constraints, but I have to comply with other constraints too. I followed your recommendation & downgraded fab provider using pip install apache-airflow-providers-fab==1.1.1
and it worked !! thank you ;)

[potiuk]

Glad it worked, but I will re-open it - this one is really a bug in FAB provider that we need to fix :). You SHOULD be able to use 1.2.0 providers with earlier versions of Airlfow - so likely 1.2.1 version of FAB provider will have a compatibility code to handle it.

[eladkal]

CC: @shahar1 : we need to find a good solution for back-compatibility - and I am not sure if we can do it for earlier Airflow versions - because Airlfow 2.9.2 and below will call the "/logout" method via GET and without CSRF. I think what we should do is to add a back-compatibilty code in logout - and allow "GET" method if airflow version <= 2.9.2

since fab provider has min version of Airflow 2.9.0 I think the simplest solution is to bump the min version to 2.9.2
I think that is reasonable enough

[shahar1]

CC: @shahar1 : we need to find a good solution for back-compatibility - and I am not sure if we can do it for earlier Airflow versions - because Airlfow 2.9.2 and below will call the "/logout" method via GET and without CSRF. I think what we should do is to add a back-compatibilty code in logout - and allow "GET" method if airflow version <= 2.9.2

since fab provider has min version of Airflow 2.9.0 I think the simplest solution is to bump the min version to 2.9.2 I think that is reasonable enough

I just thought about it while implementing the solution 😅
It is ready, though, so it's up to you how to proceed.

[eladkal]

Since you already implemented the solution and it's seems simple enough then we can just merge it :)

[potiuk]

since fab provider has min version of Airflow 2.9.0 I think the simplest solution is to bump the min version to 2.9.2
I think that is reasonable enough

There is a good reason why we should not limit it. The idea behind FAB provider is that each version is linked to a specific FAB version - because we partially vendored in security manager - and this allowed people to upgrade to newer version of fab (and security fixes it brings) without bringing Airlfow version up. So yeah - in this case it's just 2.9.1 and 2.9.2 that are affected, so once we release 2.9.3 everyone should upgrade anyway, but in general cases I think it's good to keep min Airflow version as low as we can, to allow everyone to upgrade FAB independently.

So I treat that also as a "learning" exercice on how we can do it - this way in the future we might remember to look at those compatibilities and fix them in similar way.

[seub]

@potiuk Am I understanding your previous message correctly in that it should be fixed in 2.9.3? We are still seeing the error in 2.9.3.

EDIT: I see now from the linked PR that it sounds like the bug will be fixed in 2.10.0

[potiuk]

@potiuk Am I understanding your previous message correctly in that it should be fixed in 2.9.3? We are still seeing the error in 2.9.3.

EDIT: I see now from the linked PR that it sounds like the bug will be fixed in 2.10.0

Sort of. It will also be fixed by the next FAB provider release. You will be able to install the new FAB provider for 2.9.3 (and we might even adapt constraints to make sure 2.9.3 will come pre-installed with the right providers. That will be way faster than 2.10.0 and with no migration - just upgrading the provider.

[seub]

@potiuk Thank you. Strangely, we just checked that the version of the fab provider we're using is 1.2.1 (in our current deployment with airflow 2.9.3), and we still have the error, even though the bug was supposed to be fixed with 1.2.1.

[potiuk]

@potiuk Thank you. Strangely, we just checked that the version of the fab provider we're using is 1.2.1 (in our current deployment with airflow 2.9.3), and we still have the error, even though the bug was supposed to be fixed with 1.2.1.

Yes it fixed it for 2.9.2 but there was wrong version check in the provider assuming that workaround will not be needed in 2.9.3 which was wrong assumption. The next version of FAB provider will fix it for all 2.9* (if we have 2.9.4 for example)