Version: 0.0.0-dev

[thanhdc-97]

Why does the version on my page show Version: 0.0.0-dev

[dosubot[bot]]

The version on your page shows "Version: 0.0.0-dev" because the version field in your package.json file is set to "0.0.0-dev".

{
  "name": "superset",
  "version": "0.0.0-dev",
  "description": "Superset is a data exploration platform designed to be visual, intuitive, and interactive.",
  ...
}

Additionally, if you are using a development image of Superset, it will display the version as 0.0.0-dev within the Superset UI. This is because the actual "in-development" versions of Superset are not tagged with version numbers on Docker Hub and are identified as 0.0.0-dev ^[1][2][3].

To continue talking to Dosu, mention @dosu.

[dosubot[bot]]

You can use either an Authorization token or a cookie when querying using localhost because the mode is set to 'same-origin' by default in the SupersetClientClass constructor. This allows the browser to include cookies in requests to the same origin (localhost).

However, when querying the remote Superset API, the mode might need to be set to 'cors' to allow cross-origin requests. Cross-origin requests have stricter security policies, and the browser may not include cookies unless the server explicitly allows it through CORS headers.

Here is the relevant part of the constructor:

constructor({
    baseUrl = DEFAULT_BASE_URL,
    host,
    protocol,
    headers = {},
    fetchRetryOptions = {},
    mode = 'same-origin', // default mode
    timeout,
    credentials = undefined,
    csrfToken = undefined,
    guestToken = undefined,
    guestTokenHeaderName = 'X-GuestToken',
    unauthorizedHandler = defaultUnauthorizedHandler,
  }: ClientConfig = {}) {
    // ...
    this.mode = mode;
    // ...
}

To query the remote Superset API, you may need to adjust the mode to 'cors' and ensure that the server's CORS policy allows the necessary headers and credentials ^[1].

To continue talking to Dosu, mention @dosu.

[thanhdc-97]

@dosu. I use the API

[dosubot[bot]]

When using the Superset API, the behavior of authentication can differ between localhost and a remote server due to CORS (Cross-Origin Resource Sharing) policies. On localhost, the mode is set to 'same-origin', which allows the use of cookies and Authorization tokens seamlessly. However, for remote servers, you need to set the mode to 'cors' to enable cross-origin requests.

Here's how you can configure the SupersetClientClass for remote server usage:

const client = new SupersetClientClass({
  mode: 'cors',
  // other configurations
});

Additionally, ensure that the backend CORS settings are properly configured in superset_config.py:

ENABLE_CORS = True
CORS_OPTIONS = {
    # Add your Flask-CORS options here
}

This setup allows the API to handle cross-origin requests and should enable the use of Authorization tokens or cookies on a remote server ^[1][2].

To continue talking to Dosu, mention @dosu.

[thanhdc-97]

@dosu.
When I query the api https://xxxxx/api/v1/dashboard/ if I use Token it comes up empty but I use Cookie again and the result is
and there is another case when I don't pass cookie mix token then authorization query error is not reported but no result is returned

[dosubot[bot]]

The reason querying the API at https://xxxxx/api/v1/dashboard/ returns no results when using a token but works with a cookie, and does not report an authorization error when neither a cookie nor a token is passed, can be inferred from the @protect() decorator used in the API methods.

The @protect() decorator is likely responsible for handling authentication and authorization. If the decorator is not correctly configured to handle token-based authentication, it might not validate the token properly, leading to no results being returned. On the other hand, if the cookie-based authentication is correctly configured, it works as expected.

Additionally, if neither a cookie nor a token is passed, the decorator might be defaulting to allowing access without proper authentication, which is why it does not report an authorization error.

Here is a relevant snippet from the provided code:

@expose("/<id_or_slug>", methods=("GET",))
@protect()
@safe
@statsd_metrics
@with_dashboard
@event_logger.log_this_with_extra_payload
def get(
    self,
    dash: Dashboard,
    add_extra_log_payload: Callable[..., None] = lambda **kwargs: None,
) -> Response:
    """Get a dashboard.
    ---
    get:
      summary: Get a dashboard
      parameters:
      - in: path
        schema:
          type: string
        name: id_or_slug
        description: Either the id of the dashboard, or its slug
      responses:
        200:
          description: Dashboard
          content:
            application/json:
              schema:
                type: object
                properties:
                  result:
                    $ref: '#/components/schemas/DashboardGetResponseSchema'
        400:
          $ref: '#/components/responses/400'
        401:
          $ref: '#/components/responses/401'
        403:
          $ref: '#/components/responses/403'
        404:
          $ref: '#/components/responses/404'
    """
    result = self.dashboard_get_response_schema.dump(dash)
    add_extra_log_payload(
        dashboard_id=dash.id, action=f"{self.__class__.__name__}.get"
    )
    return self.response(200, result=result)

The @protect() decorator is used here, which suggests it is responsible for handling the authentication logic.

Additionally, the test cases from the tests/integration_tests/async_events/api_tests.py file provide further insight into the behavior of the API when no token or cookie is provided. Specifically, the test_events_no_login and test_events_no_token methods show that the API should return a 401 status code when no valid authentication is provided:

def test_events_no_login(self):
    app._got_first_request = False
    async_query_manager.init_app(app)
    rv = self.fetch_events()
    assert rv.status_code == 401

def test_events_no_token(self):
    self.login(ADMIN_USERNAME)
    self.client.set_cookie(app.config["GLOBAL_ASYNC_QUERIES_JWT_COOKIE_NAME"], "")
    rv = self.fetch_events()
    assert rv.status_code == 401

These tests indicate that the API should indeed return an authorization error (401 status code) when neither a cookie nor a token is passed, suggesting that there might be an issue with the @protect() decorator or the overall authentication configuration in your specific setup ^[1][2].

To continue talking to Dosu, mention @dosu.