Response:
Content-Type: text/html; charset=utf-8
Body begins with
MATOMO_SESSID cookie is set.
I´ve already had set up different ChatGPT Apps, but the error remains.
Therefore I would like to ask the following:
Does the Matomo MCP Server Plugin On-Premise currently support the MCP/OAuth Discovery Metadata Endpoints expected by ChatGPT apps?
If so: How do these .well-known endpoints need to be enabled or routed?
Hi @RonanChardonneau
many thanks for your reply!
Yes, I have used the ‘How To’ guide mentioned several times and have followed all the steps exactly, and double checked them several times. However, as soon as I create the custom app and enter the MCP endpoint URL, the following error message appears:
Error retrieving the OAuth configuration
MCP server “xx/index.php?module=API&method=McpServer.mcp&format=mcp” does not implement OAuth
Even when ignoring the first error message and continue to set up the ChatGPT App with the existing ClientID and Client Secret mentioned in the guidelie, the error message persists, but will then state: ‘An error occurred whilst connecting to Matomo Connect. Please try again later.’
“As far as I remember from last setting that up getting that error message once is expected. But following the guide and screenshots should make it work
What COULD be an issue, if that is on-prem, is a server configuration problem
Apache2 + mod_php are known “broken” for the Header parameter that is sent by the OAuth2 connection. The initial issue text already has the solution and that needs to be placed either in a matomo-root .htaccess, or somewhere in the VirtualHost configuration”
Hi @RonanChardonneau,
a very big thanks for your reply and also the GitHub link.
However, I had already come across this during my previous research on the issue.
In this regard, I had also submitted a support ticket to the hosting provider I use.
The reply was, that the authorisation should work ‘in theory’ and it was recommended to insert the following into Matomo’s index.php file:
if (isset($_SERVER[‘REDIRECT_HTTP_AUTHORIZATION’]) && !isset($_SERVER[‘HTTP_AUTHORIZATION’])) {
$_SERVER[‘HTTP_AUTHORIZATION’] = $_SERVER[‘REDIRECT_HTTP_AUTHORIZATION’];
}
In addition, I had also added the line mentioned above to the .htaccess file:
But unfortunately, however, the error persists, and as soon as you enter the MCP endpoint URL in the ChatGPT app, the following message appears:
“Error retrieving the OAuth configuration
MCP server /index.php?module=API&method=McpServer.mcp&format=mcp does not implement OAuth”
However, I would like to add that the server is a rented web hosting space and there are only very few options available for customising the server’s configuration.
Replace example.com and <TOKEN_AUTH> with the appropriate values. The first call is a simple “does header authorization work”, could be a false positive if header passing is broken and anonymous access is allowed, because then a missing token would be acceptable for anonymous access.
The second one should return an MCP Session ID JSON thingy.
Both calls should succeed with a valid auth token and McpServer enabled. If any two of those respond with unable to authenticate, and the token is definitely valid, then it is likely a server configuration thing.
Hello Ronan,
First of all: I’d also like to apologise for the late reply!
And once again, a huge thank you for the help from you and your colleague!
I started all over again from scratch along with the newest Matomo Update and all the necessary and furthermore a new ChatGPT app but also a new OAuth2 client. I’ve also double-checked the ‘workarounds’ in the .htaccess and index.php files, mentioned by my server provider and your colleage. Afterwards, the curl commands you provided didn’t return errors such as ‘unable to authenticate’,. Also setting up a new ChatGPT App as provided in your guideline worked perfectly,. I was able to use the ChatGPT App for some analytical questions.
To cut a long story short: I would suspect that (as it is sometimes the case) the problem was sitting in front of the computer. Fundamentally, however, it seems to have been down to the rented server environment. As without the workaround in the index.php file, which was suggested to me by support, no connection was possible.
So, once again, thank you for your help with this issue.