front - admin menu - drop-down non deterministic #39135
Comments
raphaelauv
added
area:core
kind:bug
|
Also have seen this a couple of times since 2.9.0 in our environment. Still have no clue about the root cause and how to fix. Ideas welcome. |
jscheffl
added
area:auth
area:UI
|
We also are encountering the same issue, will try to look around if I can find a fix for this. |
|
After some digging, it seems like this could have been introduced by #36871, but not entirely sure, as for some reason cannot reproduce it in dev environment. |
|
Duplicate issue in #39204 -> @jscheffl -> are you also using OAUTH authentication ? @raphaelauv -> can you post your configuration as well and possibly answer the same questions I possted in #39204 (comment) Particularly - what is your default user -> role mapping and what makes user an admin? |
|
cc: @vincbeck as well. Maybe you will get more luck |
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
|
cc: @jscheffl @raphaelauv -> maybe you could try to apply the fix in your env to double check if my guess was right? |
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
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
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
|
@potiuk Will try a regression the next days, might need a moment. But we are also using OAUTH and it smells very probable that the correction fixes it... THANKS! |
BTW. there was no need for that - it was enough that there were Viewer/Admin users hitting the same worker actually. |
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)
…e#39229) 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
Apache Airflow version
2.9.0
What happened?
My user is Admin in airflow
but most of the time I can't see all the admin menu drop-down but only Plugins
after multiple F5 I can see all the admin menu
and if I F5 again it go back to only Plugins
What you think should happen instead?
No response
How to reproduce
I can't reproduce it with the simple docker compose of the airflow project
it's maybe related to the fact that the problematic airflow deployment is setup with an LDAP
Are you willing to submit PR?
Code of Conduct
The text was updated successfully, but these errors were encountered: