Hi @Harej , this was likely related to a wider incident we were experiencing in the last 2 weeks. Are you still experiencing problems here?

Still getting the 500 error

@Harej Hello!
Sorry for the long delay, we are going through the tickets now checking what's still current.
We tried this, and it works for us currently.
Could you please check if it works for you? If it doesn't, could you tell us exactly what you put in the form?

I now get this error:

[6aab8836cf02dc6764ce8a29] 2024-11-14 19:19:54: Fatal exception of type "Lcobucci\JWT\Signer\Key\FileCouldNotBeRead"

Hi @Harej !
Could you please share the input you provide on the form?
Thanks!

My input and the resulting error

Thanks, @Harej !
I was able to reproduce on my instance.

This does not reproduce with default settings, so the problem must be somewhere in the additional checkboxes

This came up again in the Cloud Telegram chat - I took a look and it's the "This consumer is for use only by X" option. This gives the stated error with the selected permissions, and a 500 error if you use either of the default permission radio buttons instead. This may be the same or a similar error, and if so this may be a solution.

We need to think about how we are going to manage all these keys for all of the different wikis. @dang correctly identified that we can't check these into git. I think we have a few options and we probably want to have a separate key per site to prevent across site attacks:

• we could have the API generate and send a key to Mediawiki
  • this is probably the neatest way and we can set the whole key in $wgOAuth2PrivateKey and $wgOAuth2PublicKey as per https://www.mediawiki.org/wiki/Extension:OAuth#Configuration
  • this means we need to add these as two new settings to the API (see https://github.com/wbstack/api/blob/main/app/WikiSetting.php)
  • then generate content for them at wiki creation time (c.f. https://github.com/wbstack/api/blob/7b1f1dec2481d2503d88966cbbc25de43df2dda2/app/Http/Controllers/WikiController.php#L102)
  • to generate this content we'd need to do some research about how to create these keypairs in PHP. Shelling out and creating them using ssh-keygen/openssl see https://oauth2.thephpleague.com/installation/#generating-public-and-private-keys) is possible but would probably require extra logic to write these to some temporary place and then read them in.
• We could generate and store a key in a k8s secret; mount them all into the MW pods and then have the API pass the correct path to the right key
  • this probably will result in a crazy amount of secrets that need to be mounted into a single worker container

@dang will research how to generate a suitable public/private keypair purely in our platform api

If you set a different private/public keypair for every wiki, that will also mean access tokens only work on the wiki where they were obtained.

Generate keys dynamically within PHP: https://github.com/wbstack/api/pull/914
Obtain keys from WikiSetting: https://github.com/wbstack/mediawiki/pull/477

In T336937#10727845, @dang wrote:

Generate keys dynamically within PHP: https://github.com/wbstack/api/pull/914
Obtain keys from WikiSetting: https://github.com/wbstack/mediawiki/pull/477

I successfully tested these in my local dev setup by issuing an oauth2 token with the "admin only" setting - worked both for new wikis and (after I ran the job) for existing ones

In T336937#10556409, @Tgr wrote:

If you set a different private/public keypair for every wiki, that will also mean access tokens only work on the wiki where they were obtained.

I realise I didn't reply to this here but I wanted to thank you for the comment :)

Yes, that's desirable for us; we do not have user accounts shared across these wikis so that's good to know. If we had used the same keypairs (but are not using CentralAuth or similar) would it have still meant access tokens worked across wikis?

I think we have to run the GenerateOAuth2KeysJob at least one more time since it seemed to have timed out: https://groups.google.com/a/wikimedia.de/g/wb-cloud-monitoring/c/BSHV0qVwxoM

> WikiSetting::where('name', 'wgOAuth2PrivateKey')->count()
= 679

> WikiSetting::where('name', 'wgOAuth2PublicKey')->count()
= 679

> Wiki::count()
= 1442

@dena will do. I didn't check the job

I tested this with a new and pre-existing instance based on the ticket description and it seems to work (unfortunately, I don't have a deep knowledge of the topic to do any kind of testing around it).

@Harej Could you please check whether it works on your side?

To ensure all wikis got valid keys I ran a simple script to check them with openssl which resulted in no errors found https://phabricator.wikimedia.org/P75105

you're awesome @dena!

In T336937#10746541, @Tarrow wrote:

If we had used the same keypairs (but are not using CentralAuth or similar) would it have still meant access tokens worked across wikis?

Only if they share the OAuth database (and you'd have to also use some shared CentralIdLookup provider, be that CentralAuth or something else).