Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pools have disappeared from the Admin menu #39204

Closed
1 of 2 tasks
csp33 opened this issue Apr 23, 2024 · 9 comments · Fixed by #39229
Closed
1 of 2 tasks

Pools have disappeared from the Admin menu #39204

csp33 opened this issue Apr 23, 2024 · 9 comments · Fixed by #39229
Labels
affected_version:2.9 area:UI Related to UI/UX. For Frontend Developers. kind:bug This is a clearly a bug

Comments

@csp33
Copy link
Contributor

csp33 commented Apr 23, 2024

Apache Airflow version

2.9.0

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

No response

What happened?

Pools item is not shown in admin menu.
image

However, I can still access the interface entering the URL <webserver>/pool/list
image

My user has the Admin role
image
which can do everything related to Pools
image

What you think should happen instead?

Pools should be displayed in the Admin menu, just like before

How to reproduce

  1. Install Airflow 2.9.0
  2. Try to find Pools in the Admin menu.

Operating System

Airflow in Kubernetes

Versions of Apache Airflow Providers

No response

Deployment

Official Apache Airflow Helm Chart

Deployment details

Anything else?

We're using GitHub login.
In local (user/password login) the Pools option still appears in the Admin menu.

Are you willing to submit PR?

  • Yes I am willing to submit a PR!

Code of Conduct

@csp33 csp33 added area:core kind:bug This is a clearly a bug needs-triage label for new issues that we didn't triage yet labels Apr 23, 2024
@RNHTTR
Copy link
Contributor

RNHTTR commented Apr 23, 2024

Is there anything unique about your environment? I'm able to see Admin -> Pools on 2.9.0

image

@RNHTTR RNHTTR added pending-response area:UI Related to UI/UX. For Frontend Developers. and removed area:core labels Apr 23, 2024
@csp33
Copy link
Contributor Author

csp33 commented Apr 23, 2024

In production we're using the GitHub login.
In local (where we have the user/pwd login) I can still see the Pools menu 🤔

Added to the issue description, thanks!

@vargacypher
Copy link
Contributor

vargacypher commented Apr 23, 2024

We're facing the same problem reported by @csp33 , but not only with pools.
Sometimes we just see 'configuration' in admin tab, and sometimes it appers again all tabs (pools,variables etc...).
image

After navigating again for some tabs and come back to pool using directly URL, it apper again.
image

Obs: Webserver and Scheduller logs doesn't show any error that appers to be related with that.
We're using Airflow Locally on a dedicated server.

@RNHTTR RNHTTR removed pending-response needs-triage label for new issues that we didn't triage yet labels Apr 23, 2024
@potiuk
Copy link
Member

potiuk commented Apr 24, 2024

Duplicate of #39135 - seems that it is some kind of race conndition when OAUTH/LDAP authentication is used - and likely related to the optimisation implemented in #36871 but could not find the reason yet. cc: @vincbeck

@potiuk
Copy link
Member

potiuk commented Apr 24, 2024

In production we're using the GitHub login. In local (where we have the user/pwd login) I can still see the Pools menu 🤔

Added to the issue description, thanks!

What's your Github integration configuration @csp33 (Without secrets?) ?

@csp33
Copy link
Contributor Author

csp33 commented Apr 24, 2024

In production we're using the GitHub login. In local (where we have the user/pwd login) I can still see the Pools menu 🤔
Added to the issue description, thanks!

What's your Github integration configuration @csp33 (Without secrets?) ?

This is my webserver_config.py :

        import os
        from typing import Dict, Any, List, Union

        from airflow.www.security import AirflowSecurityManager
        from flask_appbuilder import expose
        from flask_appbuilder.security.manager import AUTH_OAUTH
        from flask_appbuilder.security.views import AuthOAuthView

        AUTH_TYPE = AUTH_OAUTH
        AUTH_USER_REGISTRATION = True
        AUTH_USER_REGISTRATION_ROLE = "Viewer"
        PERMANENT_SESSION_LIFETIME = 1800


        OAUTH_PROVIDERS = [
            {
                "name": "github",
                "icon": "fa-github",
                "token_key": "access_token",
                "remote_app": {
                    "client_id": os.getenv("GITHUB_OAUTH_APP_ID"),
                    "client_secret": os.getenv("GITHUB_OAUTH_APP_SECRET"),
                    "api_base_url": "https://api.github.com",
                    "client_kwargs": {"scope": "read:user, read:org"},
                    "access_token_url": "https://github.com/login/oauth/access_token",
                    "authorize_url": "https://github.com/login/oauth/authorize",
                    "request_token_url": None,
                },
            },
        ]

        class CustomAuthRemoteUserView(AuthOAuthView):
            @expose("/logout/")
            def logout(self):
                """Delete access token before logging out."""
                return super().logout()


        class GithubAuthorizer(AirflowSecurityManager):
            authoauthview = CustomAuthRemoteUserView

            def get_oauth_user_info(
                    self, provider: str, resp: Any
            ) -> Dict[str, Union[str, List[str]]]:
                remote_app = self.appbuilder.sm.oauth_remotes[provider]
                me = remote_app.get("user")
                user_data = me.json()
                username = user_data["login"]

                try:
                    name_surname_list = user_data['name'].split(" ", 1)
                    first_name = name_surname_list[0]
                    last_name = name_surname_list[1]
                except Exception:
                    first_name = last_name = "unknown"

                return {
                    "username": username,
                    "email": user_data["email"],
                    "first_name": first_name,
                    "last_name": last_name,
                }

        SECURITY_MANAGER_CLASS = GithubAuthorizer

@potiuk
Copy link
Member

potiuk commented Apr 24, 2024

Absolutely cannot reproduce - even with your settings:

Questions:

  • How did you make your user "Admin" after it's been registered as user?
  • Do you have more than one webserver instances running? Are you sure they are all restarted/upgraded to 2.9.0?
  • Can you see (at least few times while you are seeing missing Admin menus) what are the users and their roles using airflow users list command (see below) - does it change?
  • Is it possible that you have AUTH_SYNC_ROLES_AT_LOGIN = True set in all or some of your webservers ?
  • Is it possible that you have two users created with different usernames like this ?

airflow users list

id | username      | email                        | first_name | last_name | roles       
===+===============+==============================+============+===========+=============
1  | github_potiuk | github_potiuk@email.notfound |            |           | Admin       
2  | potiuk        | jarek@potiuk.com             | Jarek      | Potiuk    | Viewer                                                                                      
```

@csp33
Copy link
Contributor Author

csp33 commented Apr 24, 2024

Now the Pools option always appear, but the Variables, connections, etc. are the ones that randomly show when I refresh the page 😮
image
image

I have 2 webservers and in both I'm recognised as an Admin. The output is the same when I can see the options and when I can't.

image
image

In the profile page I can confirm that I'm logged in as admin
image
image

How did you make your user "Admin" after it's been registered as user?

I can't remember right now. Maybe I used the CLI to perform airflow users add-role. After that, all the roles have been granted from the List Users page.

Do you have more than one webserver instances running? Are you sure they are all restarted/upgraded to 2.9.0?

All of them are fresh pods using 2.9.0 image.

Can you see (at least few times while you are seeing missing Admin menus) what are the users and their roles using airflow users list command (see below) - does it change?

Command output is the same (see above)

Is it possible that you have AUTH_SYNC_ROLES_AT_LOGIN = True set in all or some of your webservers ?

No, that is not set anywhere

Is it possible that you have two users created with different usernames like this ?

Checked it and that doesn't happen

Thanks for the help!

@potiuk
Copy link
Member

potiuk commented Apr 24, 2024

I think I found the reason (cc: @vincbeck). It required multiple users with different permissions using the same server gunicorn worker, that's why likely it was difficult to reproduce on dev server.

Fix here: #39229

potiuk added a commit to potiuk/airflow that referenced this issue Apr 24, 2024
The default implementation of filter_permitted_menu_items had a
subtle side-effect. The filtering on child items was done in-place
and modified the menu itself, so it was enough to get the same
worker serve requests for multiple users for the same menu to get
the items removed for subsequent user - even if they had permission
to see it.

Deepcopying the menu items before filtering them should fix the problem

Fixes: apache#39204
Fixes: apache#39135
potiuk added a commit that referenced this issue Apr 24, 2024
The default implementation of filter_permitted_menu_items had a
subtle side-effect. The filtering on child items was done in-place
and modified the menu itself, so it was enough to get the same
worker serve requests for multiple users for the same menu to get
the items removed for subsequent user - even if they had permission
to see it.

Deepcopying the menu items before filtering them should fix the problem

Fixes: #39204
Fixes: #39135
jedcunningham pushed a commit that referenced this issue Apr 26, 2024
The default implementation of filter_permitted_menu_items had a
subtle side-effect. The filtering on child items was done in-place
and modified the menu itself, so it was enough to get the same
worker serve requests for multiple users for the same menu to get
the items removed for subsequent user - even if they had permission
to see it.

Deepcopying the menu items before filtering them should fix the problem

Fixes: #39204
Fixes: #39135
(cherry picked from commit 0d2c0c5)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
affected_version:2.9 area:UI Related to UI/UX. For Frontend Developers. kind:bug This is a clearly a bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants