fix(superset-auth): Retrieve CSRF token with jwt auth for Superset

[Vitor-Avila]

By default, Superset requires an X-CSRFToken header for some API requests. This was already handled when using the superset-cli command with basic auth (-u $username -p $password) but it wasn't handled when using jwt auth (--jwt-token $jwt).

This PR adds logic to include the CSRF token in the get_headers function.

Fixes #183.

[zephyring]

baseurl is better suffix without /. Then you can prefix api/v1/security/csrf_token/ with /

[Vitor-Avila]

thanks, @zephyring! The baseurl wasn't included in the constructor before, so I just copied what was sent to the runner.invoke here:

runner.invoke(
  superset_cli,
  ["--jwt-token=SECRET", "http://localhost:8088/", "export"],
  catch_exceptions=False,
)

The last trailing slash is included in other tests (like here and here), do you think this should be updated in other places as well?

I performed a local test using both http://localhost:8088/ and http://localhost:8088 in the CLI command and printed the endpoint -- both scenarios produced the same URL (http://localhost:8088/api/v1/security/csrf_token/) and the command worked properly.

Let me know your thoughts. Thank you!

[zephyring]

It's a convention to have base_url ending without /. Not sure the other examples syntax for string / string is a good pattern to follow. maybe @betodealmeida ?

[betodealmeida]

It should work either way here, we're using yarl for URL composition and it should do the right thing.

[betodealmeida]

It's better to create a new Auth class, maybe SupersetJWTAuth, since the path api/v1/security/csrf_token/ is very specific to Superset. Otherwise this generic class becomes tightly coupled with Superset and it becomes hard to reuse it for other APIs.

[Vitor-Avila]

ohhhhh that makes sense! Just noticed this class is also used by dbt. Going to make these changes. Thank you!