milux / ctldap

LDAP Wrapper for ChurchTools
GNU General Public License v3.0
12 stars 8 forks source link

Response code 403 after upgrade to churchtools 3.101.0 #48

Closed a-schild closed 11 months ago

a-schild commented 11 months ago

Hello,

our setup did work with the 3.100.0 release. On tuesday night the system did upgrade to churchtools 3.101.0 and now we can't login via ldap. The ctldap is on 3.1.2 and here what we see in the log of the ctldap docker container.

Interesting to note: Yesterday I did login as nextcloud admin (Without ldap authentication) and then I could verify the LDAP auth settings and then it did work for a few minutes. Then afterward it stopped working. I did the same again one more time, but then I could not get it working anymore...

Any ideas? Perhaps someting related to #46 ? The error/behaviour looks the same. Of course I did triple check the api_key We are using a dedicated ct account for ldap requests, which is not used in any other way by users or systems.

2023-09-21T06:40:07.384Z [DEBUG] churchtools - SEARCH base object: cn=bwagner, ou=users, o=churchtools scope: base
2023-09-21T06:40:07.384Z [DEBUG] churchtools - Filter: (objectclass=*)
2023-09-21T06:40:07.384Z [DEBUG] churchtools - Search for users
2023-09-21T06:40:07.385Z [DEBUG] churchtools - Wait on Promise for cache key "rawData".
2023-09-21T06:40:07.387Z [DEBUG] churchtools - Wait on Promise for cache key "users".
2023-09-21T06:40:07.993Z [DEBUG] churchtools - Assumed 2 page(s) of data for /api/persons, which was correct.
2023-09-21T06:40:08.491Z [DEBUG] churchtools - fetchPersons done
2023-09-21T06:40:08.564Z [DEBUG] churchtools - fetchGroupTypes done
2023-09-21T06:40:08.711Z [DEBUG] churchtools - fetchGroups done
2023-09-21T06:40:09.279Z [DEBUG] churchtools - Assumed 2 page(s) of data for /api/persons, which was correct.
2023-09-21T06:40:09.801Z [DEBUG] churchtools - fetchPersons done
2023-09-21T06:40:09.865Z [ERROR] churchtools - Error while retrieving users:
HTTPError: Response code 403 (Forbidden)
    at Request.<anonymous> (file:///app/node_modules/got/dist/source/as-promise/index.js:86:42)
    at Object.onceWrapper (node:events:628:26)
    at Request.emit (node:events:525:35)
    at Request._onResponseBase (file:///app/node_modules/got/dist/source/core/index.js:726:22)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Request._onResponse (file:///app/node_modules/got/dist/source/core/index.js:768:13)
2023-09-21T06:40:09.880Z [DEBUG] churchtools - SEARCH base object: cn=bwagner, ou=users, o=churchtools scope: base
2023-09-21T06:40:09.880Z [DEBUG] churchtools - Filter: (objectclass=*)
2023-09-21T06:40:09.880Z [DEBUG] churchtools - Search for users
2023-09-21T06:40:09.881Z [DEBUG] churchtools - Wait on Promise for cache key "rawData".
2023-09-21T06:40:09.881Z [DEBUG] churchtools - Wait on Promise for cache key "users".
2023-09-21T06:40:10.062Z [DEBUG] churchtools - Assumed 2 page(s) of data for /api/groups, which was correct.
2023-09-21T06:40:10.209Z [DEBUG] churchtools - fetchGroups done
2023-09-21T06:40:10.281Z [DEBUG] churchtools - fetchGroupTypes done
2023-09-21T06:40:10.426Z [DEBUG] churchtools - Assumed 2 page(s) of data for /api/groups, which was correct.
2023-09-21T06:40:10.990Z [DEBUG] churchtools - Assumed 2 page(s) of data for /api/persons, which was correct.
2023-09-21T06:40:11.128Z [DEBUG] churchtools - fetchGroups done
2023-09-21T06:40:11.215Z [DEBUG] churchtools - fetchGroupTypes done
2023-09-21T06:40:11.287Z [ERROR] churchtools - Error while retrieving users:
HTTPError: Response code 403 (Forbidden)
    at Request.<anonymous> (file:///app/node_modules/got/dist/source/as-promise/index.js:86:42)
    at Object.onceWrapper (node:events:628:26)
    at Request.emit (node:events:525:35)
    at Request._onResponseBase (file:///app/node_modules/got/dist/source/core/index.js:726:22)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Request._onResponse (file:///app/node_modules/got/dist/source/core/index.js:768:13)
2023-09-21T06:40:11.863Z [DEBUG] churchtools - fetchPersons done
a-schild commented 11 months ago

I now just redid the nextcloud configuration and for the moment it works again, just as twice yesterday. I fear it will break in a few Minutes/hours again...

What can I do to collect more debug information?

a-schild commented 11 months ago

Nun ist es wieder "defekt".

Um UTC 06:55:18 hatte ich es nochmals eingerichtet und getestet. Dann ca. 5 Minuten später:

2023-09-21T07:00:03.723Z [ERROR] churchtools - Error while retrieving users:
HTTPError: Response code 403 (Forbidden)
    at Request.<anonymous> (file:///app/node_modules/got/dist/source/as-promise/index.js:86:42)
    at Object.onceWrapper (node:events:628:26)
    at Request.emit (node:events:525:35)
    at Request._onResponseBase (file:///app/node_modules/got/dist/source/core/index.js:726:22)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Request._onResponse (file:///app/node_modules/got/dist/source/core/index.js:768:13)
a-schild commented 11 months ago

I'm wondering if this call interfers with the cookies?

The site.api calls all send the login token with it, but for the login this is not needed, and perhaps the resulting cookie intefers with subsequent site,api,xxx calls?

await site.api.post('login', {
      json: {
        "username": username,
        "password": req.credentials
      }
    });
a-schild commented 11 months ago

Aftear clearing everything and switching to the latest tag for the docker image it now runs. Looks like there was some older version running.

Sorry for the noise.

But the thing about the cookies, this migth realy be related to pool them across different instances/logins...

milux commented 11 months ago

Aftear clearing everything and switching to the latest tag for the docker image it now runs. Looks like there was some older version running.

Sorry for the noise.

But the thing about the cookies, this migth realy be related to pool them across different instances/logins...

I thought so. Sorry for not responding earlier. This is typical behavior for ctldap prior to 3.1.1, where I introduced separate CookieJars parallel requests. That issue is caused by PHPs "session ID generation", which CT is using for whatever reason. :man_shrugging: