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.

Sign up for GitHub

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

fix: Prevent cached bootstrap data from leaking between users w/ same first/last name #26023

Merged
merged 3 commits into from
Nov 21, 2023
Merged

fix: Prevent cached bootstrap data from leaking between users w/ same first/last name #26023

Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
ebc24ec
Pass user id to
jfrag1 Nov 20, 2023
4c9ac95
Appease pylint
jfrag1 Nov 20, 2023
6ee1eb8
Refactor
jfrag1 Nov 21, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 5 additions & 2 deletions superset/views/base.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -380,7 +380,9 @@ def menu_data(user: User) -> dict[str, Any]:


@cache_manager.cache.memoize(timeout=60)
def cached_common_bootstrap_data(user: User, locale: str) -> dict[str, Any]:
def cached_common_bootstrap_data( # pylint: disable=unused-argument
user: User, user_id: int | None, locale: str
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need both User and user_id? Surely the former contains the ID which should then be used for the cache key given it's globally unique.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While yes, User "contains" the ID, it's __repr__ method that flask-caching uses to generate the cache key does not (see PR description).

The 2 alternatives to this fix as-is would be to:

  1. change the __repr__ upstream on FAB to include the id. (cc @dpgaspar if this is a welcome change)
  2. Subclass FAB's user class and add our own repr then update to use that user class everywhere, which seems like a pretty large change for this small fix

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jfrag1 sorry I missed that detail when initially glancing over the PR description. Is a third alternative to just pass in user_id instead of both user and user_id?

) -> dict[str, Any]:
"""Common data always sent to the client

The function is memoized as the return value only changes when user permissions
Expand Down Expand Up @@ -424,8 +426,9 @@ def cached_common_bootstrap_data(user: User, locale: str) -> dict[str, Any]:


def common_bootstrap_payload(user: User) -> dict[str, Any]:
user_id = user.id if hasattr(user, "id") else None
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like the FAB User class will always have the id attribute defined and thus simply passing in user.id on line 431 should be safe.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Grokking through the code it seems like this is always g.user, thus rather than passing around the global, it seems clearer to remove the user variable from said method and thus said logic simply becomes,

 from superset.utils.core import get_user_id 

def common_bootstrap_payload() -> dict[str, Any]:
    return {
        **cached_common_bootstrap_data(get_user_id(), get_locale()),
        "flash_messages": get_flashed_messages(with_categories=True),
    }

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh great point it is always g.user, I'll make that change.

It seems like the FAB User class will always have the id attribute defined and thus simply passing in user.id on line 431 should be safe.

The type hint was a bit of a lie since g.user could also be AnonymousUserMixin. I'd update it but it's getting removed instead

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jfrag1 I think my comment is somewhat of a moot point given that it seems like we're going down the get_user_id() route.

return {
**cached_common_bootstrap_data(user, get_locale()),
**cached_common_bootstrap_data(user, user_id, get_locale()),
"flash_messages": get_flashed_messages(with_categories=True),
}

Expand Down
Loading