Seems this is the same as T395664 found during tests.

Yes, it is afaik same. Do you have any idea if it would be possible to get the Oauth/Botpassword working for third part oauth logins?

I was not able to find any easy way to do it and i wrote the ticket mostly for documenting the issue and the practical task would be to add error handling and error messages to superset/WCQS logins so that user will know why it fails.

@Zache: I tested some accounts. First I had to logout the account from wikimedia site, login to wikimedia via superset and grant the access for this message:

The results:

I'll try bot password again later. Maybe I have overseen something.

@Xqt If you have time i would you like to write step-by-step guide how you got the Oauth working? ( I am trying to figure out what i am doing differently )

Bot Password accounts get the following response:

looks like https://meta.wikimedia.org/w/rest.php/oauth2/authorize?response_type=code&client_id=…&redirect_uri=…&scope=mwoauth-authonlyprivate&state=…

And there is another problem with login: If there is a different site from meta superset takes it and access may fail if the other site has a different user registerd. As an example U can take this test:

def test_overriding_site(self):
    """Test overriding schema using site"""
    sql = 'SELECT page_id, page_title FROM page LIMIT 2;'
    superset = SupersetQuery(schema_name='enwiki_p', database_id=2)
    testsite = pywikibot.Site('wikipedia:fi')
    rows = superset.query(sql, site=testsite)
    self.assertLength(rows, 2)

@Zache: I have checked the cookie files. I think BotPassword accounts may not work for web or OAuth logins because they do not receive a central OAuth session (centralauth_Session). Can you (or someone) confirm?

In T408286#11311161, @Xqt wrote:

@Zache: I have checked the cookie files. I think BotPassword accounts may not work for web or OAuth logins because they do not receive a central OAuth session (centralauth_Session). Can you (or someone) confirm?

This how i understood it also, but I do not understand it well enough to know if something can be done about it.

@Zache: I have checked the cookie files. I think BotPassword accounts may not work for web or OAuth logins because they do not receive a central OAuth session (centralauth_Session). Can you (or someone) confirm?

This how i understood it also, but I do not understand it well enough to know if something can be done about it.

I fear we cannot do anything useful on the Pywikibot side. Maybe a clientlogin for a BotPassword account would help, as long as you can enter the email auth code, but this is not practical for automatically running bots or the test suite.

Superset is not intended for non-interactive SQL queries like this, please see https://wikitech.wikimedia.org/wiki/Help:Wiki_Replicas for supported ways to query the wiki replicas. Thus untagging us.

@taavi Adding Superset support to Pywikibot was pretty one of the first use cases for Superset when it published the replica access, and the point of it is that it doesn't require a Toolforge account as because managing the new Toolforge accounts doesn't scale. For example, there are security reasons not to create Toolforge accounts for random workshop participants or, in our current case, for Outreachy contribution period volunteers, if nothing else. Using OAuth login and HTTP API will scale to that usecase.

Another thing is that this affects other tools too, not just superset. For example, Wikimedia Commons Query Service, which is used and it is meant to be used from bots. Also If the general idea is to put tools behind OAuth, then it will become a problem pretty fast for the bots and other server side tools, which you need to address. (i.e., https://meta.wikimedia.org/wiki/Third-party_resources_policy)

In T408286#11318239, @taavi wrote:

Superset is not intended for non-interactive SQL queries like this, please see https://wikitech.wikimedia.org/wiki/Help:Wiki_Replicas for supported ways to query the wiki replicas. Thus untagging us.

In that case, I’m wondering why Superset exposes API endpoints such as https://superset.wmcloud.org/api/v1/me/ if it’s not meant for non-interactive use.