https://superset... API only working with cookie, not working with Authorization

[thanhdc-97]

• When I query the list dashboard with Authorization: 'Bearer token', the result is not as expected; it returns an empty array.

• However, when I use a cookie (taken from Superset's main page), it works.

• superset_config.py
  

• I am not sure if I have configured it correctly. There have been discussions about this issue, but it has not been resolved yet.

• Is there any solution to this problem? Thank you.

[dosubot[bot]]

I found some similar issues and discussions that might help you:

1. Open Issue: Response to GET /chart/ with guest token is empty. This issue is still open and was last updated on April 08, 2024. It suggests looking into a related issue here ^[1].

2. Closed Issues:

   • Empty result dashboard from superset APIs /api/v1/dashboard when the Public role has can read on Dashboard and can read on Chart. This issue was closed and last updated on April 09, 2024. It also suggests looking into the related issue here ^[2].
   • API only working with cookie. This issue was closed and last updated on March 20, 2024. The suggested solution is to set FAB_API_MAX_PAGE_SIZE = 1000 or FAB_API_MAX_PAGE_SIZE = -1 in your configuration ^[3].
   • Fetch dashboard not happening properly with different type of login. This issue was closed and last updated on January 18, 2023. It mentions that switching from db to ldap authentication caused issues with the auth token, and they had to use puppeteer to get the session logged cookie for API requests ^[4].

The reason querying the list dashboard with an Authorization Bearer token returns an empty array, while using a cookie works correctly, is due to the way Superset handles authentication. Superset uses session cookies for authentication, which are set during the login process. When using a cookie, the session is properly authenticated because the cookie contains the necessary session information. However, when using an Authorization Bearer token, the session information is not included in the same way, leading to an empty array being returned ^[5][6].

To resolve this issue, you might need to ensure that the necessary roles and permissions are correctly set for the user associated with the Bearer token. The specific roles and permissions required to access the /api/v1/dashboard/ endpoint using an Authorization Bearer token include:

1. Admin Role: Users with the Admin role can access the endpoint.
2. Owner Role: Users who are owners of the dashboard can access the endpoint.
3. Users with Specific Dashboard Permissions: Users who have been granted access to the specific dashboard can access the endpoint.
4. Public Role with Dashboard Permission: Public users who have been granted access to the specific dashboard can access the endpoint ^[7].

Ensure that your superset_config.py is correctly configured to support Bearer token authentication. Although I couldn't find specific configurations in superset_config.py for Bearer token authentication, you might want to review your settings and ensure that all necessary configurations are in place.

If the issue persists, you might want to explore the related issues and solutions mentioned above for further insights.

To continue talking to Dosu, mention @dosu.

[dosubot[bot]]

Yes, you can set the token expiration time in the configuration. The expiration time for guest access tokens is determined by the GUEST_TOKEN_JWT_EXP_SECONDS configuration setting.

Here is the relevant code snippet:

exp_seconds = current_app.config["GUEST_TOKEN_JWT_EXP_SECONDS"]

This configuration value (GUEST_TOKEN_JWT_EXP_SECONDS) specifies the number of seconds after which the token will expire ^[1].

The GUEST_TOKEN_JWT_EXP_SECONDS setting is defined in the superset/config.py file as follows:

GUEST_TOKEN_JWT_EXP_SECONDS = 300  # 5 minutes

This setting specifies the expiration time for guest tokens in seconds, with a default value of 300 seconds (5 minutes) ^[2].

Additionally, this setting is used in the superset/security/manager.py file in the create_guest_access_token method to set the expiration time for the token ^[1].

If you need to set a different expiration time, you can update the GUEST_TOKEN_JWT_EXP_SECONDS value in your superset_config.py file.

To continue talking to Dosu, mention @dosu.

[thanhdc-97]

@dosu. The access_token expiration setting is returned from the login api, I want to fix the expiration time for it, it seems to be only 15 minutes now

[dosubot[bot]]

To fix the access token expiration time returned from the login API in Apache Superset, you need to modify the JWT_EXPIRATION value in the superset/utils/oauth2.py file. Currently, it is set to 15 minutes (timedelta(minutes=15)). You can change this to your desired expiration time.

Here is the relevant part of the code with the modification:

JWT_EXPIRATION = timedelta(minutes=15)  # Change this to your desired expiration time

For example, if you want to set the expiration time to 1 hour, you would change it to:

JWT_EXPIRATION = timedelta(hours=1)

Make sure to save the file and restart your Apache Superset instance for the changes to take effect ^[1].

To continue talking to Dosu, mention @dosu.

[thanhdc-97]

@dosu.
When I query api /api/v1/security/guest_token/ if I add rls as below, any chart without ACB column will get error Error: (1054, "Unknown column 'ABC' in 'where clause'")
rls: [{ clause: ABC = 'def', type: 'dataset', id: 70 }],

how to fix it

[dosubot[bot]]

To fix the error "Unknown column 'ABC' in 'where clause'" when querying the API /api/v1/security/guest_token/ with a row-level security (RLS) clause that references a non-existent column in some charts, you need to ensure that the RLS clause only references columns that exist in the dataset being queried.

Here are the steps to resolve this issue:

1. Verify Column Existence:
   Ensure that the column ABC exists in the dataset associated with the charts. If the column does not exist, you need to update the RLS clause to reference only existing columns.

2. Update the RLS Clause:
   Modify the RLS clause to use a valid column name that exists in the dataset. For example, if the column ABC does not exist, replace it with a valid column name.

Here is an example of how to update the RLS clause:

self.rls_entry2.clause = "valid_column_name = 'def'"

Make sure to replace valid_column_name with an actual column name that exists in the dataset.

3. Update Existing RLS Filter:
   If you need to update an existing RLS filter, you can use the following code:

rls_entry = db.session.query(RowLevelSecurityFilter).filter_by(name="rls_entry2").one_or_none()
if rls_entry:
    rls_entry.clause = "valid_column_name = 'def'"
    db.session.commit()

This will ensure that the RLS clause references only existing columns, thereby preventing the "Unknown column" error.

Additionally, the RLSRestApi class in the superset/row_level_security/api.py file provides methods to create, update, and delete RLS rules. You can use these methods to manage your RLS rules programmatically:

• To create a new RLS rule, use the post method.
• To update an existing RLS rule, use the put method.
• To delete RLS rules, use the bulk_delete method.

These methods handle validation and ensure that the RLS rules are correctly applied to the specified tables and columns ^[1][2].

To continue talking to Dosu, mention @dosu.