Yeah I read the wrong specifications. I was going through oauth2 documentation. Xenforo's implementation is simpler.
I managed to get it to work with just the client id and secret, but had to made a sort of 'bridge/middleware'.
First time I got it to work too, I absolutely love it :D
Hello
I'm trying to get a single sign on to work for Bookstack (wiki). I set up my endpoints in the .env of Bookstack
# XenForo 2.3
# This tells BookStack exactly where to find the username in the XenForo response
OIDC_DISPLAY_NAME_CLAIMS=username
# XenForo Connection...
Yeah I can setup an environment for debugging, there is a backup of the exact moment where the upgrade process got stuck. I'll set that up later this weekend and update the support ticket.
A very radical fix for me was:
Drop xf_purchase_request table
Run the cmd.php xf:repair-db command which recreate the table
This will continue the install process, but all the data in that table is lost, what does this have as consequences?
Despite running the query and having the latest version manually uploaded and deployed, I still get the error?
I already have data in the provider_metadata columns, not sure if that's an issue?
I had this issue today as well when upgrading from Ubuntu 20 LTS to 22.
PHP updated to 8.1 and Mariadb updated to 10.6.7.
For some weird reason, the collation of all the tables went to utf8mb3 and running the cmd.php xf:convert-utf8mb4 had no effect and returned that no convertable tables were...
It seems the issue is related to the automatic bounce handler.
I was using an email address set as default for board notifications, and I set up an email address dedicated to just bounced mails (as indicated in the instructions).
When I disabled the automatic bounce handler, the errors stopped...
Not sure how to do that on Safari, but in Firefox/Chrome you can enable a 'Developer Mode' to see the network requests or javascript errors when loading the page. This could help you get a better idea of what the problem is. 'Protocol error' is pretty vague. (http2? ssl? udp/tcp?)
Interestingly enough, once the table was recreated and I checked a few hours later, the mail queue had already thousands of mails waiting in the queue. All the mails in the queue were destined to the same user (using a @gmail.com account). There seems to be a logic loop somewhere that keeps...
For posterity, I was able to view and copy the blank table from a previous backup. In order to recreate the xf_mail_queue table, the following sql query has to be run:
SET NAMES utf8;
SET time_zone = '+00:00';
SET foreign_key_checks = 0;
SET sql_mode = 'NO_AUTO_VALUE_ON_ZERO';
DROP TABLE IF...