Closed allenckc closed 4 years ago
Hi,
I had preferred some more details of your problem, because it's not easy to help you with just log ;)
If I have understood you have succeeded to authenticate you on the Oauth server form and you have reached the authorization page. When you click authorize button you are not log in but you get an error. Have you a bad token request error in your browser ?
A priori, that seems like you do not configure the date.timezone in your php.ini. To resolve you can add the following line in oauth/server.php, or edit your php.ini file.
date_default_timezone_set ('Asia/Hong_Kong');
If authentication still does not work, remove this line in oauth/server.php
ini_set('display_errors',1);error_reporting(E_ALL);
If nevertheless the error persists, you should check oauth/resource.php succeeds to get data from LDAP. To do this you can use the ldap.php test file.
I hope these will solve your problem, please give me your feedback,
Crivaledaz
I'd already set timezone : Asia/Hong_Kong. There's no ini_set('display_errors',1);error_reporting(E_ALL); inside oauth/server.php
I've tested ldap.php with no problem. Is it because I use AD, there's no uid but sAMAccountName also the email address is not the same as user_id
Ok, thanks for your feedbacks.
I'm sorry, but I never use AD before, i will try to help you but i can guarantee anything. Normally, Mattermost-LDAP should work with AD with a few changes.
If the authorization process works fine, you just need to adapt getting information process. This step implies the getDataForMattermost() method in the LDAP class in the LDAP directory. So you must edit this method to comply with AD.
I think you need to change ldap_get_value() call to set data labels compatible with AD. For more information, see : http://php.net/manual/en/function.ldap-get-values.php
If you want to know which are data send to Mattermost by Oauth server in the last step, you can connect to the Oauth database and get the last Access Token generate for your user (table : oauth_access_tokens) and use curl to get the data in your terminal :
curl --header "Authorization: Bearer ACCESS_TOKEN" http://OAUTH_SERVER/oauth/resource.php
Change ACCESS_TOKEN by the token retrieve in database, and OAUTH_SERVER by oauth server hostname. You should get an output like this :
{"name":"CLAVIER Denis","username":"crivaledaz","id":1,"state":"active","email":"clavierd@gmail.com"}
If there is some field not filled or other text outside of curly brackets, Mattermost could not parse auth data.
Good luck for your test, does not hesitate if you have any question about my code. Please give me your feedback,
Crivaledaz
Finally after I added ldap_bind inside getDataForMattermost() before ldap_search, I got data from curl !
But now when I click authorize page, I got error : [2017/08/18 10:51:41 HKT] [DEBG] GET - /api/v4/config/client [2017/08/18 10:51:41 HKT] [DEBG] GET - /api/v4/license/client [2017/08/18 10:51:42 HKT] [DEBG] GET - /oauth/gitlab/login [2017/08/18 10:51:48 HKT] [DEBG] GET - /signup/gitlab/complete [2017/08/18 10:51:48 HKT] [EROR] Please check the std error output for the stack trace [2017/08/18 10:51:48 HKT] [EROR] [runtime error: invalid memory address or nil pointer dereference]
but the page was shown with error : This page isn’t working , Error HTTP 500
It seems it won't added a new user to Mattermost database . Also I found that no data was added into table oauth_authorization_codes
What's next ?!
If you get data from curl, it's a good news, I think the end is near :)
Also I found that no data was added into table oauth_authorization_codes
Don't worry about that ! Actually, data were added and after deleted. When you click the authorize button Oauth creates an Authorization Token, stores it in the oauth_authorization_codes table, and sends it to Mattermost. Mattermost retrieves the token and uses it to ask a token to access data on the Oauth server, but when an Authorization Token is used, it is automatically deleted to avoid reuse.
If you want to verify that authorization token is created, you can change Mattermost settings (Admin panel / gitlab) and modify the "Token Endpoint" address to point to a page that does not exist.
[2017/08/18 10:51:48 HKT] [EROR] [runtime error: invalid memory address or nil pointer dereference]
This error is typical of a problem to access oauth/resource.php. So be sure you have filled "User API Endpoint:" with http://OAUTH_SERVER/oauth/resource.php
.
If it still does not work, try to remove oauth/.htaccess and oauth/Oauth2/.htaccess and oauth/LDAP/.htaccess
If, despite these corrections you still have an error 500, try to change Mattermost settings (Admin panel > gitlab) and modify the "User API Endpoint" address to point to a page that does not exist, and check if you have the same error. You can also try to curl resource.php from the server where Mattermost is running.
Finally, a possible reason of the error is that your firewall is blocking the connection. To test, you can try to flush every firewall rules with iptables -F
and try again to connect to Mattemost with gitlab button (do not forget to change Mattermost config with valid values)
I hope this will help you, good luck, I'm waiting for your feedback
Crivaledaz
"If you want to verify that authorization token is created, you can change Mattermost settings (Admin panel / gitlab) and modify the "Token Endpoint" address to point to a page that does not exist." - Yes, it created !
"This error is typical of a problem to access oauth/resource.php. So be sure you have filled "User API Endpoint:" with http://OAUTH_SERVER/oauth/resource.php. Yes, already there
"If it still does not work, try to remove oauth/.htaccess and oauth/Oauth2/.htaccess and oauth/LDAP/.htaccess" Deleted, but the same error
I've no firewall set.
One thing I haven't mentioned , the mattermost server (port 8065) and oauth server (port 80) are in the same server .
I've tried using different server for oauth , and now I got the following error :
AuthorizeOAuthUser: Token request failed, Post http://MYOAUTHOSERVER/oauth/token.php: dial tcp: i/o timeout
One thing I haven't mentioned , the mattermost server (port 8065) and oauth server (port 80) are in the same server .
Is not a problem, I have tried both configuration, and the both work. However, when Oauth and Mattermost are on the same server, it's often easier to configure, because there is no firewall problem or typo error in hostname (because localhost works everywhere).
AuthorizeOAuthUser: Token request failed, Post http://MYOAUTHOSERVER/oauth/token.php: dial tcp: i/o timeout
Did you sign in the oauth server and have you reached the authorization page (with the 2 buttons) ? The error occurs before identification or after press the authorize button ? The error could be due to a proxy server between your Oauth Server and your Mattermost. If the error occurs after authorization process, you can retrieve the authorize token (on the url is the token after "code=", or directly on the database in table oauth_authorization_code) and try a new curl :
curl -u CLIENT_ID:CLIENT_SECRET http://OAUTH_SERVER/oauth/token.php -d 'code=AUTHORIZE_TOKEN&grant_type=authorization_code&redirect_uri=http://MATTERMOST_SERVER:8065/signup/gitlab/complete'
CLIENT_ID and CLIENT_SECRET (separated by a colon) are the ID and the secret share between Mattermost and Oauth (Application ID and Application Secret key in Mattermost Admin Panel). This curl will return something like that :
{"access_token":"bc3c0d80449c0e7ab043a3837d9f58c6221b5af5","token_type":"Bearer","refresh_token":"560900deec323fefb44b52dc8692c62de0248330","scope":"api","created_at":1503304569}
If you want to continue the process by hand, you can use the access token given to get the user data, with the same curl as the last time.
With these two curl you can do many tests by hand to reproduce exchanges between Oauth server and Mattermost. The aim is to get JSON data with user data like that (and only that line, else mattermost will fail to parse) :
{"name":"CLAVIER Denis","username":"crivaledaz","id":1,"state":"active","email":"clavierd@gmail.com"}
Please do some tests and give me results, we will success to configure LDAP/AD support for your Mattermost ;)
Regards,
Crivaledaz
When I used 2 different server, I can only get token and result successfully by manually curl ! But when I used the website login, it failed :
"Did you sign in the oauth server and have you reached the authorization page (with the 2 buttons) ? " YES The error occurs before identification or after press the authorize button ? After
Error: Token request failed and no record were written to table oauth_access_tokens
When I use same server, same http 500 error as before ....
p.s. I'm using Mattermost team version 4.1 and mysql
It's very strange that you achieve a complete process manually, but not with the application. Using curl should not change nothing, this only permits to have a window on the process to understand what is going on the black box of the app.
So, I think we are going to focus on the case with Oauth and Mattermost on the same server. Just to be sure, have you disabled SELinux ? SELinux seems to be unfriendly with Mattermost-LDAP.
Unfortunately, I have no more idea, so we need to inspect carefully log. The error 500 you get occurs on the Mattermost web server side or Apache (httpd) side. Do you use a reverse proxy for your Mattermost ?
Obviously, we need more log, so add the following line in oauth/server.php, at the beginning, and try again the manual process to see if errors, notices or warnings are raised : ini_set('display_errors',1);error_reporting(E_ALL);
Similarly, active debug logs on Mattermost and try to connect with Mattermost-LDAP (using Gitlab button). To do that, edit your Mattermost config.json as described here : https://docs.mattermost.com/administration/config-settings.html#logging
Post here your logs for one authentication process, we will study them to debug the error. I am sorry for not having better idea :/
Good luck,
Crivaledaz
SELinux disabled.
"The error 500 you get occurs on the Mattermost web server side or Apache (httpd) side. Do you use a reverse proxy for your Mattermost ?" Mattermost side . No reverse proxy
The DEBUG log from mattermost : [2017/08/22 12:10:14 HKT] [DEBG] GET - /api/v4/config/client [2017/08/22 12:10:14 HKT] [DEBG] GET - /api/v4/license/client [2017/08/22 12:10:15 HKT] [DEBG] GET - /oauth/gitlab/login [2017/08/22 12:10:21 HKT] [DEBG] GET - /signup/gitlab/complete [2017/08/22 12:10:21 HKT] [EROR] Please check the std error output for the stack trace [2017/08/22 12:10:21 HKT] [EROR] [runtime error: invalid memory address or nil pointer dereference]
Both manually and from web login get all token json into tables. But still error above
So, I don't know why, but Mattermost do a segmentation fault when it try to get data from resource.php.
The problem could come when Mattermost try to query the Oauth server to get user data, or when Mattermost got the data and try to work with. However, since you achieve to retrieve data with curl, it is more likely a problem with the HTTP request made by Mattermost .
Could you try to re-install from scratch Mattermost and Mattermost-LDAP (on a new VM will be the best). Just to be sure this is not an isolated error from Mattermost. I have no more idea for this moment, I'm sorry.
In the same vein, you should try with another Mattermost version, I have tried versions 3.9.0 and 4.1.0 and it works perfectly on the both.
For a quick deployment, I suggest you to use the Puppet module I have implemented. Note that I have added the service account support for LDAP as you suggest.
If you really have time, you can try to install and configure Gitlab with Mattermost to check if Mattermost also fails with Gitlab. If Yes is a Mattermost issue, if no is a Mattermost-LDAP issue.
I will continue to search an answer to your problem, and I will keep you posted. Please send me your feedbacks if you have news.
Regards,
Crivaledaz
Finally I got successfully by using Gitlab ...
Well since yesterday Wochenende have problems Authenticating with Gitlab SSO
AuthorizeOAuthUser: Token request failed, Post https:///oauth/token: dial tcp xxxx: i/o timeout
So I thought I give your work a shot, but I'm getting same Error like "invalid Memory...."
After reading through I may hunted it down to our Reverseproxy configuration. Tried everything I could imagine and find through the net, but I couldn't find a solution.
In short im currently using this Config: https://gist.github.com/misje/52551fc43754d2e27f32
If I'm using our internal domains and avoid our proxy, login works like a charm
Any ideas?
I actually encountered this error on IE Edge. It's working on Chrome but not on IE Edge.
Hi I established the integration of Mattermost-LDAP with Microsoft AD Several changes were made to the code:
LDAP.php: After calling ldap_connect:
ldap_set_option($ldap, LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($ldap, LDAP_OPT_REFERRALS, 0);
Without this ldap_bind produces an error
connexion.php: After calling $ldap->checkLogin
try
{
$data = $ldap->getDataForMattermost($base,$filter,$bind_dn,$bind_pass,$search_attribute,$user,$attributes);
$username = explode('@', $data['username']);
$resp = array("name" => $data['name'],"username" => $username[0],"id" => (int)$assoc_id,"state" => "active","email" => $data['mail'],"login" => $username[0]);
}
catch (Exception $e)
{
echo "Successful authorization! <br />";
echo "But AD does not have some fields: <br />". $e->getMessage();
echo '
</main>
</body';
die;
}
This can significantly speedup debugging.
AuthorizationCode.php:
In the function validateRequest:
if ($authCode["expires"] < time()-3600) {
Changes to date_default_timezone_set did not lead to the correct execution of this condition. We had to add an offset of 3600.
Thanks for your work
Same error here. Mattermost 5.9, Nginx 1.16 as Proxy, PHP 7.2, LDAP server is not Microsoft AD, don't know exactly - outsourced.
What I've tried so far:
OK, I have fixed it for me. The problem was the "cn" field. Maybe it doesn't exist?
File oauth/LDAP/LDAP.php. This line throw an "Decoding error":
$cn = ldap_get_values($this->ldap_server, $data, "cn");
Instead I used "givenName" and "sn" and concatenated them:
return array("mail" => $mail[0], "cn" => $givenName[0].' '.$sn[0]);
No I can login using Gitlab!
I encountered a similar error after authorization
Could not parse auth data out of gitlab user object
This issue for me was that my LDAP server does not have a mail
attribute. I modified https://github.com/Crivaledaz/Mattermost-LDAP/blob/0c1eaf3a311c0ba1eb2edeabf9667ce81580ce44/oauth/LDAP/LDAP.php#L228 to use the correct attribute and everything worked.
Perhaps the name of the mail
attrribute can be made configurable to be a little more flexible?
It would also be nice to be able to configure the LDAP attribute used for the user's full name. Sometimes the cn
attribute is not a user friendly name. For example, on my LDAP server there is a displayName
attribute that provides a more user friendly full name.
A configuable attribute mapping is needed. Some thing like
$mapping = [
'username' => 'uid',
'email' => 'mail',
'firstname' => 'givenName',
'lastname' => 'sn',
];
In OTRS it works this way (using Perl of cause). And there seems to be no reliable fullname field. It should be concatenated from firstname and lastname.
I get "Token request failed" error too, after hitting "Authorize" LDAP button. Mattermost LDAP is installed in docker, centos 7. I'm using latest Mattermost 5.21 in docker too. After figuring out how to correctly run a code in docker, changing settings and code for LDAP to work, I'm stuck with token error. I'm able to successfully authenticate to AD with my credentials if using LDAP website only:
http://OAUTH_SERVER:8066/oauth
I also get positive results from both CURL-s:
curl -u CLIENT_ID:CLIENT_SECRET http://OAUTH_SERVER:8066/oauth/token.php -d 'code=AUTHORIZE_TOKEN&grant_type=authorization_code&redirect_uri=http://MATTERMOST_SERVER:8065/signup/gitlab/complete'
and
curl -i -H 'authorization: Bearer ACCESS_TOKEN' http://OAUTH_SERVER:8066/oauth/resource.php
However, after hitting "Authorize" button when I try to authenticate over Git Lab button in Mattermost, I get Token request error.
@Crivaledaz, any thoughts?
Hi,
What is the result of the curl on token.php
. Do you get a JSON output or an empty answer ?
What is your host OS running Mattermost-LDAP container ? Are you using the container provided in this repository ?
This kind of bug typically appears when Mattermost does not reach Oauth server. Can you check Mattermost logs and find the error log about the "Token error request failed" error.
The problem could be caused by firewall filtering or SELinux enforcement, particularly if your host system is CentOS 7. Try to disable SELinux and stop FirewallD to verify their are not blocking some requests.
Otherwise, I also got this error when I use auto-signed certificate for Oauth server which is not recognized by Mattermost. If you are in this case, try to downgrade Mattermost and Mattermost-LDAP in HTTP.
Else, it can be a network issue between Mattermost and Oauth. Is container port 80 bind to 8066 host port ?
Please, try these suggestions and give me some details, we will find the problem :)
Regards,
Hi.
I get a JSON output out of curl.
Host OS is SLES 12 SP3, container provided is from your repository (with modified configuration to work in may host). Mattermost containers are from GitHub.
Error log:
{"level":"error","ts":1586122232.3910975,"caller":"web/oauth.go:259","msg":"AuthorizeOAuthUser: Token request failed, Post http://server.company.com:8066/oauth/token.php: dial tcp: i/o timeout"}
I'm not using SSL (yet).
Mattermost is in one container, Oauth in another on another Docker network (both on the same host). I can do a curl from Mattermost docker to Oauth with successful JSON result.
Oauth container has port 80 (as your default) and bind to 8066.
SELinux is not enforced. AppArmor is enabled. SuSEfirewal2 is already disabled.
I tried MM 5.9 and 4.9 too. However, issue stayed the same. Funny thing is also this, that I tried to authenticate MM 4.x or 5.x to GitLab v8 (a couple of years old instance, that we use to authenticate older version MM 3.7). MM 4.x and 5.x reports same "Token error request failed" error. However, MM 3.7 works fine with GitLab 8!?
@Crivaledaz, I discovered the main reason for "i/o timeout". First of the two DNS IP addresses in network settings of the host, where Mattermost docker was installed, was incorrect. And obviously, Mattermost-LDAP name resolving was slow. Too slow for Mattermost. Does Mattermost really have just a couple of seconds waiting time for LDAP authentication?
Tank you for your response, anyway. Regards
Hi,
Happy to know you find a solution for your issue. I'm sorry for my late answer, I was busy last week.
Concerning Mattermost timeout, I never reach this issue, but according to Mattermost forum, the timeout for token POST request is hardcoded : 3 seconds to connect and 30 seconds to finish. (https://forum.mattermost.org/t/configure-stand-alone-mattermost-with-gitlab-sign-on/7782/13)
I hope you enjoy Mattermost-LDAP, I close this issue since is solved, feel free to re-open it if necessary.
Regards,
[2017/08/17 12:30:04 HKT] [DEBG] GET - /api/v4/config/client [2017/08/17 12:30:04 HKT] [DEBG] GET - /api/v4/license/client [2017/08/17 12:30:05 HKT] [DEBG] GET - /oauth/gitlab/login [2017/08/17 12:30:15 HKT] [DEBG] GET - /signup/gitlab/complete [2017/08/17 12:30:15 HKT] [EROR] LoginByOAuth: Could not parse auth data out of gitlab user object,