search

Crivaledaz / Mattermost-LDAP

This module provides an external LDAP authentication in Mattermost for the Team Edition (free).
MIT License
357 stars 71 forks source link

authorize.php error 500 #91

Closed demogorgonz closed 2 years ago

demogorgonz commented 2 years ago

Describe the bug

To Reproduce Steps to reproduce the behavior:

  1. run the demo, open http://localhost:8065 and try to login
  2. See error : 
http://localhost/oauth/authorize?response_type=code&client_id=123456789abcdef123456789abcdef&redirect_uri=http%3A%2F%2Flocalhost%2Fsignup%2Fgitlab%2Fcomplete&state=eyJhY3Rpb24iOiJsb2dpbiIsImlzTW9iaWxlIjoiZmFsc2UiLCJ0b2tlbiI6InhycDgzN3B5cTEzcmRkODRqbnBkYXhpeWhjb3QxdGc0ZHNqN2RtMzQ5YWpxNXpyaW56M3JkYnM4emFneHR5eDkifQ%3D%3D

This page isn’t workinglocalhost is currently unable to handle this request.
HTTP ERROR 500

Exact steps:

git clone https://github.com/Crivaledaz/Mattermost-LDAP
cd Mattermost-LDAP/Demo
cp -p ../oauth/config_db.php.example ../oauth/config_db.php
cp -p ../oauth/LDAP/config_ldap.php.example ../oauth/LDAP/config_ldap.php
docker-compose up -d

Seems like the demo is not working. P.S i have generated the certs.

Crivaledaz commented 2 years ago

Hi,

The demo was working for me on december 2021, but I confirm this does not work anymore now, at least on my server with podman-compose. It took a while to find out the problem's root, but I finally find it, and a way to solve it.

Nginx throws an error 500 because it cannot reach the mattermost backend. In fact, the mattermost upstream points to localhost, but containers are not sharing the same local loop anymore, so the mattermost port 8065 is not available in the Nginx container on the localhost. A similar problem is happening in the PHP container, which cannot reach the database on 127.0.0.1 or the LDAP server on localhost.

Thus, I think issue #86 has the same root problem and that's why PostgreSQL database and LDAP server are not reachable from the Nginx container.

To patch these issues, localhost reference must be replaced by corresponding service DNS entries. By default with podman/docker compose, each container is accessible from its service name in other containers.

I need to do more tests to be sure my patch is reliable and do not introduce regression, but I think I will push it soon.

Thank you for your feedback, please let me know if the patch solves your issue.

Regards,

demogorgonz commented 2 years ago

Hi, thanks for reply. I tried baremetal and docker-compose deploy too.

Currently it seems like it is not working at all with recent version of Mattermost v6.5.0, token.php throws error 500 on PHP v7.3.20. 

GET /oauth/authorize.php?response_type=code&client_id=XXX&redirect_uri=https%3A%2F%2Fxxx.com%2Fsignup%2Fgitlab%2Fcomplete&state=XXX HTTP/2.0" 302 0 "https://XXX.com/oauth/access_token" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.60 Safari/537.36" "-" "-"
172.21.3.178 - - [31/Mar/2022:22:57:05 +0200] "POST /oauth/token.php HTTP/1.1" 500 11 "-" "Mattermost-Bot/1.1" "-" "-"

Tried /oauth/index.php and that works, however redirect to Mattermost results in error:

Bad response from token request.

Can you maybe verify that code is compatible with Mattermost v6.5.0 ?

Crivaledaz commented 2 years ago

Hi,

I have pushed the patch on branch master.

Now, the demo is working on my Fedora 35 with podman 3.4.4 and podman-compose 1.0.3. I can confirm Mattermost-LDAP with Nginx 1.21.6 and PHP 8.1.4 is compatible with Mattermost v6.5.0. I tried on Firefox 98.0 and Chromium 99.0.

I don't know why you get an error 500 on the token.php page, please share your logs from the PHP container. The Mattermost error results of the error 500 from the Oauth server. In fact, the token.php page should return tokens into a JSON, but due to the error 500 Mattermost does not get the expected output.

Can you try the demo with the patch ? Let me know if it solves your issue.

Regards

demogorgonz commented 2 years ago

Just tried a fresh demo, copied the configs :

cp -p ../oauth/config_db.php.example ../oauth/config_db.php
cp -p ../oauth/LDAP/config_ldap.php.example ../oauth/LDAP/config_ldap.php

from Demo folder run:

docker-compose up -d

Logs from php container:

NOTICE: PHP message: PHP Fatal error:  Uncaught PDOException: SQLSTATE[08006] [7] FATAL:  role "oauth" does not exist in /var/www/html/oauth/OAuth2/Storage/Pdo.php:67
172.18.0.6 -  26/Apr/2022:12:04:13 +0000 "GET /oauth/authorize.php" 500
Stack trace:
#0 /var/www/html/oauth/OAuth2/Storage/Pdo.php(67): PDO->__construct()
#1 /var/www/html/oauth/server.php(14): OAuth2\Storage\Pdo->__construct()
#2 /var/www/html/oauth/authorize.php(11): require_once('...')
#3 {main}
  thrown in /var/www/html/oauth/OAuth2/Storage/Pdo.php on line 67

Going to http://localhost/oauth/index.php and logging in with jdoe/test1234 works.

I have tried to expose DB on host port, and instrcuted in config to connect to my IP 192.168.1.7.

From php container i have tried telnet too to the DB:

root@6171404260d0:/var/www/html# telnet 192.168.1.7 5432
Trying 192.168.1.7...
Connected to 192.168.1.7.
Escape character is '^]'.

Further inspecting logs of DB, i saw that initialization failed due to ^M characters, quick dos2unix on init_postgres.sh & config_init.sh.example in db_init folder fixed it (had to recreate containers/purge db volume). Demo is working for me currently on Windows & Docker.

Next thing is to try same thing but on mattermost server with AD.

demogorgonz commented 2 years ago

Ok i have found solution for my setup, i was using Mattermost-LDAP behind reverse proxy as seperate domain "auth.example.com"

Had to add to nginx location block:

proxy_set_header Origin "";
error_page  405     =200 $uri;

Since nginx was returning 405 on POST request.