Hi there,
I´m working for a big company and I´m using an internal oauth2 provider in conjunction with this plugin. In a different business unit there is already another discourse instance running, where the same setup works. I analyzed their instance, and found almost nothing except a version difference of the plugin and of discourse itself.
But first of all I´ll tell you what happens.
I set up the plugin and configured everything according to documentation (the same as the other instance plus some settings, which aren´t available in the old version (0.2) of the plugin which they are using.
No I see the extra button in login screen and get forwarded to a login page (company) where I can type in my SSO account & pw…
After pressing enter this screen appears:
(oauth2_basic) Authentication failure! invalid_credentials: OAuth2::Error, invalid_client: Invalid authentication method for accessing this endpoint.
{"error_description":"Invalid authentication method for accessing this endpoint.","error":"invalid_client"}
I double checked the credentials and talked with the guys of web-eam support, and they said the authorization phase was succcessful (I got valid return parameters (code, iss, state) with the callback call)
(oauth2_basic) Setup endpoint detected, running now.
(oauth2_basic) Callback phase initiated.
(oauth2_basic) Authentication failure! invalid_credentials: OAuth2::Error, invalid_client: Invalid authentication method for accessing this endpoint.
{"error_description":"Invalid authentication method for accessing this endpoint.","error":"invalid_client"}
Started GET "/auth/failure?message=invalid_credentials&origin=https%3A%2F%2F[community-address]%2F&strategy=oauth2_basic" for 127.0.0.1 at 2019-03-21 10:50:43 +0000
Processing by Users::OmniauthCallbacksController#failure as HTML
Parameters: {"message"=>"invalid_credentials", "origin"=>"https://[community-address]/", "strategy"=>"oauth2_basic"}
The support guys told me, that the invalid client message doesn´t come from their end…
I don’t know if it’s related, but the ip address is localhost, which suggests that you need to modify your setup to get the correct remote ip number reported to discourse.
is it possible to roll back to previous version ?
A neighbouring instance is using 0.2, and I 0.3 … mine doesn´t work, theirs do …
Just want to make sure it hass nothing to do with the new version.
Unless neither of you is on tests-passed then more than a plugin version will differ.
What’s the specific issue which leads you to think you need to downgrade? Different version numbers aren’t necessarily the problem.
If it’s the issue described here then please don’t create duplicates. Work through the problem as it is until you’ve been able to identify a root cause. You were asked certain questions in that topic which you haven’t responded to.
It’s possible that there is an issue with the plugin, only by working through the problem to identify the cause can we raise bugs with plugin developers and resolve it for everyone.
Remember, correlation and causation aren’t the same thing.
Hi,
thanks @Stephen. That´s exactly the problem i have, but the question for roll-back was a general one. The problem is, that I tried everything here
but wasn´t able to solve it…
One of the most obvious differences between mine and the other instance (which is working) I see is the version of the plugin.
But I´ll continue the search in the other thread.
No, you can’t roll back. Since I think it’s a new site, you could back up the settings and pin the plugin and Discourse to a particular commit by editing the yml file. There is a commented out version line that you can replace by a version or a commit. You can similarly modify things to get a particular version of a plugin, but you’ll have to search about for how to do that.
I implemented the template which was suggested in your link, but it wasn´t successful. Logs still are
Started GET "/auth/oauth2_basic" for 127.0.0.1 at 2019-03-22 10:03:16 +0000
(oauth2_basic) Setup endpoint detected, running now.
(oauth2_basic) Request phase initiated.
Started GET "/auth/oauth2_basic/callback?code=TUurdGXN4BgO_KZunK3Zb3SBYsU&iss=https%3A%2F%2Fauth-i.xxx.net%3A443%2Fauth%2Foauth2%2Frealms%2Froot%2Frealms%2Fintranetb2x&state=d1fd00e28e0aaf44921d7351b61fdd1d7ee09de8fb02f68d&client_id=fsg8gd5v1i12ncyvkj1f28pzi68prkijks8r" for 127.0.0.1 at 2019-03-22 10:03:26 +0000
(oauth2_basic) Setup endpoint detected, running now.
(oauth2_basic) Callback phase initiated.
(oauth2_basic) Authentication failure! invalid_credentials: OAuth2::Error, invalid_client: Invalid authentication method for accessing this endpoint.
{"error_description":"Invalid authentication method for accessing this endpoint.","error":"invalid_client"}
Started GET "/auth/failure?message=invalid_credentials&origin=https%3A%2F%2Fcommunity-int.x.net%2F&strategy=oauth2_basic" for 127.0.0.1 at 2019-03-22 10:03:27 +0000
Processing by Users::OmniauthCallbacksController#failure as HTML
Parameters: {"message"=>"invalid_credentials", "origin"=>"https://community-int.xx.net/", "strategy"=>"oauth2_basic"}
Rendering users/omniauth_callbacks/failure.html.erb within layouts/no_ember
Rendered users/omniauth_callbacks/failure.html.erb within layouts/no_ember (0.9ms)
Rendered layouts/_head.html.erb (17.8ms)
Rendered common/_discourse_stylesheet.html.erb (5.5ms)
Rendered application/_header.html.erb (1.8ms)
Completed 200 OK in 50ms (Views: 25.5ms | ActiveRecord: 15.7ms)
I have to mention, that I´m hosting discourse in the official docker image. Maybe there is some issue with docker network ?
just wanted to tell you, that I wasn´t able to solve this, yet
I couldn´t dedicate to much time during the last week, but now I´ll try to pick up the thread again.
Now. I implemented the template which was suggested here
but without success. It still shows me the 127.0.0.1 local address here
… x.net%2F&strategy=oauth2_basic" for 127.0.0.1 at 2019-03-22 10:03:27
but honestly I don´t believe, that this is related to the original problem I have.
To understand this. The remote oauth web-ui was called after clicking the button in the “SignUp” Dialog…I logged in there and the service generated a code (not a token, because the request type is set to “code” in the plugin) and called the call back URL with extra stuff appended (like the code).
In my understanding the endpoint, which is being called give me this error now … invalid client. Right ?
The call which would now be made to get the user info never happens…
Or do I understand it wrongly ?
Many thanks guys for your time and for your help …
Guess that just means, that the call back request coming from the auth service got answered by nginx and forwarded locally from nginx over 127.0.0.1 to port 3000 (oauth plugin) …
But never mind, we found the bug at the auth provider. They configured a wrong auth method for us …
, but I found nothing in that link you mentioned which is related to this
