I think at least in my tools, session handling is also generally broken on the new domain. For example, if you go to https://speedpatrolling.toolforge.org/settings/ and try to save settings, you get a CSRF error. (Which is not a nice error page because I was lazy.)

I assume this is because my tool specifies APPLICATION_ROOT: /speedpatrolling/ in the ~/www/python/src/config.yaml, which means that the session cookie is exposed under /speedpatrolling/ rather than / (which is the right thing to do on tools.wmflabs.org, but not on toolforge.org), so the settings page has no session cookie and the submitted CSRF token doesn’t match what the server expects from the nonexistent session.

I’m not sure how many tools correctly set the cookie path, though, so this probably doesn’t affect everyone :)

(That this APPLICATION_ROOT is needed at all is a bit odd – after all, Flask seems to know that it’s mounted under /speedpatrolling/ when forming URLs in url_for() – but I couldn’t find a better solution at the time.)

For the record, yes, we are aware of the change in the document root for webservices changing the URL scheme. This is a change that tool developers should change in their apps.

But the OAuth thing is something I wasn't accounting for.

I chatted with @Tgr on irc a bit about OAuth grants and changing hostnames and paths. There are unfortunately no good and easy answers.

• A magic technical solution would be to somehow patch MediaWiki to understand the conversion and allow grants for tools.wmflabs.org/* to work when invoked from *.toolforge.org. We discarded that as too technically challenging for a quick fix.
• Another option would be creation of a maintenance script that could be used to update existing grants in-place in the database to use the new URLs. This is possible, but would require close coordination between migrating each tool and running the script to update it's existing grant.
• The technically easiest option would be for each tool maintainer to request a new grant and manage switching credentials and OAuth callback URLs in their tool themselves. This puts a lot of potential burden on OAuth reviewers (which honestly these days is mostly @Tgr with some help from me) to keep tool maintainers from being blocked from migration. It avoids any "magic" step in the process however that might go wrong in a bulk migration.

Instead of a maintenance script it could be a button for the consumer's owner. That way they can self-service (assuming the domain migration also works in a self-service manner).

For the record, the blocker for a magic solution is that for tools which use a non-dynamic callback URL (ie. don't send a callbackURL field in their authorization request), the server cannot guess the correct callback URL. Maybe we could force everyone to always send the URL, and add some magic to handle that, but I'm not sure to what extent that would be feasible on the tool author side.

In T244473#5866634, @bd808 wrote:

This puts a lot of potential burden on OAuth reviewers (which honestly these days is mostly @Tgr with some help from me) to keep tool maintainers from being blocked from migration.

So we'd need to appoint a few more OAuth admins on meta?

I'm trying to write some hints for Toolforge users here: https://wikitech.wikimedia.org/wiki/News/Toolforge.org#Oauth_considerations

However, from the comments above, I don't think we ended up with a single good solution for this problem. Any other ideas?

Well, from the current version of that page it sounds like tools won’t run under both domains at once anymore? With --canonical, tools.wmflabs.org redirects to toolforge.org; without --canonical… hm, I guess the page doesn’t actually specify, I just assumed it would redirect the other way around?

Anyways, my feeling is that running the tool only under one domain (either old or new) should simplify things, but I haven’t thought this through yet.

In T244473#6023131, @aborrero wrote:

However, from the comments above, I don't think we ended up with a single good solution for this problem. Any other ideas?

I think the "best" answer we came up with was:

The technically easiest option would be for each tool maintainer to request a new grant and manage switching credentials and OAuth callback URLs in their tool themselves. This puts a lot of potential burden on OAuth reviewers (which honestly these days is mostly @Tgr with some help from me) to keep tool maintainers from being blocked from migration. It avoids any "magic" step in the process however that might go wrong in a bulk migration.

TL;DR Webservices using OAuth will need to request a new grant using the $TOOL.toolforge.org hostname and any path changes that are needed for the callback URL.

I checked the database to get a rough idea of how many grants this could affect:

$ ssh mwmaint1002.eqiad.wmnet
$ sql metawiki
wikiadmin@10.64.0.91(metawiki)> SELECT COUNT(*) FROM oauth_registered_consumer WHERE oarc_stage=1 AND oarc_callback_url LIKE '%tools.wmflabs.org%';
+----------+
| count(*) |
+----------+
|      233 |
+----------+
1 row in set (0.00 sec)

wikiadmin@10.64.0.91(metawiki)> SELECT COUNT(DISTINCT oarc_user_id) FROM oauth_registered_consumer WHERE oarc_stage=1 AND oarc_callback_url LIKE '%tools.wmflabs.org%';
+------------------------------+
| count(distinct oarc_user_id) |
+------------------------------+
|                          102 |
+------------------------------+
1 row in set (0.01 sec)

Not a tiny number, but hopefully manageable.