I think we need a pretty full-on rewrite of how the authorization flow works anyway (like everything else related to the webhook handling), but let's be sure to note that the current implementation appears to be broken.
I executed .gh-hook sopel-irc/sopel-github enable in a new channel for us on Libera and clicked the authorization link, but nothing happened. No new webhook appeared in either the repository or organization settings, and Sopel never confirmed that it had received a test payload.
Checking the console log output didn't show anything useful, though. The only things related to this plugin were URL shortening errors (because of #102) and a GET request generated when my browser was redirected after authorizing the request. I didn't see anything about the backend process related to adding the webhook itself.
The reason
Turns out there were multiple issues. First, the OAuth app configuration was wrong (using /webhook instead of /auth as the authorization callback). But more importantly, GitHub has deprecated passing auth tokens via URL, as I found out by modifying the plugin to dump its JSON payload:
Reading the linked developer blog post gives the full background, but it's clear that the webhook creation process here needs to be rewritten to use an Authorization header.
Should probably add brief documentation on manually adding the webhook in the 0.4.x series. I doubt this rewrite is going to happen unless it's part of that big rewrite-all-the-webhook-stuff refactor we've wanted to do for a while.
I think we need a pretty full-on rewrite of how the authorization flow works anyway (like everything else related to the webhook handling), but let's be sure to note that the current implementation appears to be broken.
I executed
.gh-hook sopel-irc/sopel-github enablein a new channel for us on Libera and clicked the authorization link, but nothing happened. No new webhook appeared in either the repository or organization settings, and Sopel never confirmed that it had received a test payload.Checking the console log output didn't show anything useful, though. The only things related to this plugin were URL shortening errors (because of #102) and a GET request generated when my browser was redirected after authorizing the request. I didn't see anything about the backend process related to adding the webhook itself.
The reason
Turns out there were multiple issues. First, the OAuth app configuration was wrong (using
/webhookinstead of/authas the authorization callback). But more importantly, GitHub has deprecated passing auth tokens via URL, as I found out by modifying the plugin to dump its JSON payload:Reading the linked developer blog post gives the full background, but it's clear that the webhook creation process here needs to be rewritten to use an
Authorizationheader.Should probably add brief documentation on manually adding the webhook in the 0.4.x series. I doubt this rewrite is going to happen unless it's part of that big rewrite-all-the-webhook-stuff refactor we've wanted to do for a while.