Bad response from token request

[XSlicer]

Mattermost is returning this error code after logging in. Log: {"level":"error","ts":1559892630.640249,"caller":"api4/oauth.go:493","msg":"AuthorizeOAuthUser: Bad response from token request, response_body="} This seems to be a common error regarding Gitlab, but in that case either gitlab changed its output or it gave back a wrong callback URL on HTTP instead of HTTPS.

My PHP-knowledge is limited, but if I try to call token.php via curl, it gives no output. If I replace the handler line in token.php with the following (removing ->send() ):

file_put_contents('/tmp/response.txt', $server->handleTokenRequest(OAuth2\Request::createFromGlobals()));

I get this in /tmp/response.txt: `HTTP/1.1 200 OK Cache-Control: no-store Content-Type: application/json Pragma: no-cache

{"access_token":"99bb89c88313faf0ad89872160f78c7113573b0d","token_type":"Bearer","refresh_token":"b92ff0ed00f197b783f3c708621a023605cf6b73","scope":"api","created_at":1559890464}`

So it does have data, but with ->send() it looks like it drops the body and outputs nothing?

[Crivaledaz]

Hi,

This is an interesting issue ... I have never encountered this one before. Could you give me more detailed about your configuration (OS, PHP and web server version, Mattermost version ...) to allow me to reproduce the bug.

Thank you for your feedback,

Regards

[XSlicer]

GNU/Debian Linux 9.9 4.9.0-8-amd64 PHP 7.0.33-0 (default debian package) with ldap/pgsql etc PostgreSQL 11.3-1 (default debian package) Nginx 1.10.3 with php-fpm or Apache 2.4.25 with libapache2-mod-php7.0 Its basically a fully updated Debian 9 with default PHP

Normally its running Nginx with PHP-fpm, but I've also tried this with libapache2-mod-php7.0 and apache. Not that I think it matters, but the Apache VirtualHost config was (besides default php config etc):

  DocumentRoot "/var/www/Mattermost-LDAP/"
  DirectoryIndex index.php
  <Directory "/var/www/Mattermost-LDAP/">
    Options FollowSymLinks MultiViews
    AllowOverride None
    Require all granted
  </Directory>

Mattermost version 5.9.0 For the sake of additional information, the LDAP backend is Active Directory, but I don't think it matters here since I can succesfully log into Mattermost-LDAP.

Thanks for looking into it.

[Crivaledaz]

Hi,

I finally find some free time to test today :). So I have installed a fresh new CentOS 7, with a fresh Mattermost Server version 5.12 and Mattermost-LDAP. I do some test, and I never encounter your bug, Mattermost-LDAP still works well for me.

Since I use Centos 7, my PHP and PostgreSQL servers are a little bit old. So maybe my module is not compatible with PHP 7 or Postgres 11.

For your information, I use CentOS 7.6.1810 with PHP 5.4.16 and PostgreSQL 9.2.24 (which are latest version available on Centos 7 repositories).

Let me know if you have new elements,

Regards

[XSlicer]

Hi,

I downgraded PHP to 5.6 (lowest available on Debian 9) and... that works. So it's definitely something in 7.x breaking it. Sadly I cannot keep running php5, but at least it gives a working environment. Thanks.

[Crivaledaz]

Hi,

I have installed Mattermost and Mattermost-LDAP in a virtual machine running Debian 9.9. For me it works well, I can't reproduce your bug.

My configuration is now the following :

• Mattermost : 5.12
• Debian : 9.9 (kernel 4.9.0-9-amd64)
• PostgreSQL : 9.6.13 (default package)
• PHP : 7.0.33-0+deb9u3 (default package)
• Apache 2 : 2.4.25 (default package)

So, it seems PHP 7.x is not the guilty, not the only one at least. Can you try to replace Nginx with Apache2 ?

Regards,

[XSlicer]

So I've tried 5.6 with Nginx and that works.

I'm sure I've tried 7.0 with apache2, and that it didn't work. I've tried again and... now it works with apache2. Not sure why it was broken before? Maybe because I purged my PHP settings this time.

Regardless, I guess it's an issue with PHP-FPM in 7.0 (I know there is some error in 7.0's FPM on Debian, but I forgot the details) breaking it in Nginx. I'll try to use 7.3 (because that bug should have been fixed there) else I'll have to stick with Apache.

Sorry for troubling you with it, and thanks for helping out.

[GayLaurent]

Hello,

I answer in this old issue because I have reproduce same problem and I understand why :

In first line of token.php file, we can find a space before "<?php" text.

In a specific case of PHP configuration, with this space, "headers_sent" (in "OAuth2/Response.php", line 281) function return "true" because an header is already sent.

Thank to remove this space in a next release.

[Crivaledaz]

Hi @GayLaurent ,

Thank you for your feedback. I have removed the leading space on the first line of token.php in commit c65ae73.

Regards