[GH-ISSUE #24377] issue: LDAP signup does not trigger WEBHOOK_URL notification (signup webhook only fires for password and OAuth signups) #58951

New Issue

GiteaMirror · 2026-05-06T00:36:16-05:00

GiteaMirror commented

2026-05-06 00:36:16 -05:00

Originally created by @JulienDelRio on GitHub (May 5, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24377

Check Existing Issues

I have searched for any existing and/or related issues.
I have searched for any existing and/or related discussions.
I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!).
I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

v0.9.2

Ollama Version (if applicable)

No response

Operating System

Debian 12 (Coolify host)

Browser (if applicable)

No response

Confirmation

I have read and followed all instructions in README.md.
I am using the latest version of both Open WebUI and Ollama.
I have included the browser console logs.
I have included the Docker container logs.
I have provided every relevant configuration, setting, and environment variable used in my setup.
I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
Start with the initial platform/version/OS and dependencies used,
Specify exact install/launch/configure commands,
List URLs visited, user input (incl. example values/emails/passwords if needed),
Describe all options and toggles enabled or changed,
Include any files or environmental changes,
Identify the expected and actual result at each stage,
Ensure any reasonably skilled user can follow and hit the same issue.

Expected Behavior

When a new user account is created in Open WebUI through any supported authentication method (password signup, OAuth, or LDAP), and a WEBHOOK_URL is configured in the admin settings, Open WebUI should send a POST request to the configured URL with the standard signup payload:

{
  "action": "signup",
  "message": "<USER_SIGNUP message>",
  "user": "<user object as JSON>"
}

This is the documented behavior of the admin signup webhook (https://docs.openwebui.com/features/administration/webhooks/) and is required for any external automation that reacts to new user creation: auto-promotion workflows, provisioning, audit logging, notification channels.

Actual Behavior

When a new user is provisioned through the LDAP authentication path (first successful LDAP login that creates the local user record), WEBHOOK_URL is never called. No HTTP request is emitted, no log line is produced, and any external system listening for signup events is silently bypassed.

The webhook does fire correctly for:

Password-based signups (handled by signup_handler in routers/auths.py)
OAuth/OIDC signups (handled in utils/oauth.py)

But not for LDAP signups, which go through a different code path (ldap_auth in routers/auths.py) where post_webhook(...) is never invoked. This looks like an unintentional omission rather than a design choice — see the root cause analysis in Additional Information.

Steps to Reproduce

Deploy Open WebUI v0.9.2 via Docker.
Configure LDAP authentication with valid settings:
- ENABLE_LDAP=true
- LDAP_SERVER_HOST, LDAP_SERVER_PORT=636, LDAP_USE_TLS=true
- LDAP_APP_DN, LDAP_APP_PASSWORD
- LDAP_SEARCH_BASE, LDAP_ATTRIBUTE_FOR_USERNAME, LDAP_ATTRIBUTE_FOR_MAIL
Set DEFAULT_USER_ROLE=pending (the bug is unrelated to the role).
Generate a temporary webhook URL for testing — for example at https://webhook.site (free, no signup needed, instant).
Log in to Open WebUI as admin → Admin Panel → Settings → General → set "Webhook URL" to the webhook.site URL → click Save. Verify the value persists in the UI (it's a PersistentConfig variable).
Confirm reachability from inside the OWU container:
docker exec -it open-webui curl -v -X POST <webhook_url> -H "Content-Type: application/json" -d '{"test":"manual"}'
The request must succeed and appear on webhook.site. This rules out networking, DNS, TLS, or proxy issues.
From a clean browser session, log in for the first time with an LDAP user that does not yet exist in the OWU users table.
The login succeeds and the new user appears in Admin Panel → Users.
Check webhook.site: no request received. This is the bug.
Control test: temporarily set ENABLE_SIGNUP=true and create a new user via the password signup form. webhook.site receives the expected {"action": "signup", ...} payload. This confirms the webhook configuration itself is correct — the issue is specific to the LDAP code path.7.

Logs & Screenshots

Browser console: N/A (server-side issue).

Docker logs are not included to avoid leaking internal infrastructure details. The behavior is fully reproducible and the source-code analysis in "Additional Information" pinpoints the omission directly.

Visual evidence (attached):

webhook.site remains empty after a successful LDAP signup — the new user is created in Admin Panel → Users at the same timestamp.
webhook.site receives the expected {"action": "signup", ...} payload after a control password signup with the same WEBHOOK_URL configured. This confirms the webhook configuration is correct and the issue is specific to the LDAP code path.

Additional Information

Root cause analysis

A direct read of backend/open_webui/routers/auths.py on the current dev branch confirms the omission.

Password signup path (signup_handler, around line 711) — webhook IS called after user creation:

if request.app.state.config.WEBHOOK_URL:
    await post_webhook(
        request.app.state.WEBUI_NAME,
        request.app.state.config.WEBHOOK_URL,
        WEBHOOK_MESSAGES.USER_SIGNUP(user.name),
        {
            'action': 'signup',
            'message': WEBHOOK_MESSAGES.USER_SIGNUP(user.name),
            'user': user.model_dump_json(exclude_none=True),
        },
    )

OAuth signup path (backend/open_webui/utils/oauth.py, around line 1681) — webhook IS also called.

LDAP signup path (ldap_auth, around lines 502–543) — webhook is NOT called. The function inserts the user via Auths.insert_new_auth, handles the first-user-becomes-admin promotion, calls apply_default_group_assignment, and returns directly to create_session_response, skipping the webhook entirely.

Since OAuth follows the same pattern as password signup but LDAP does not, this looks like an unintentional gap rather than a design choice.

Suggested fix

Add the same post_webhook block to ldap_auth immediately after apply_default_group_assignment, scoped to the if not user: branch so the webhook fires only on actual user creation, not on subsequent logins of existing LDAP users.

I'd happily contribute a PR if maintainers confirm the fix is wanted, but I don't currently have a test environment matching the project's quality bar to validate it properly. Hence this issue rather than a PR.

Impact

This affects deployments that combine LDAP authentication with downstream automation triggered by new user signup events:

Auto-promotion workflows that move LDAP users from pending to user based on an external pre-authorization list
Provisioning pipelines for other systems
Compliance and audit logging that requires real-time notification of new account creation

Workaround: polling GET /api/v1/users/ filtered on role=='pending' every few minutes works as a substitute, just with higher latency.

The scoped-events webhook system in PR #16426 / discussion #16428 introduces an auth.user.signup event type. If/when that work lands, the LDAP path will need to be wired in there as well — same fix at the same location.

Originally created by @JulienDelRio on GitHub (May 5, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/24377 ### Check Existing Issues - [x] I have searched for any existing and/or related issues. - [x] I have searched for any existing and/or related discussions. - [x] I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!). - [x] I am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version v0.9.2 ### Ollama Version (if applicable) _No response_ ### Operating System Debian 12 (Coolify host) ### Browser (if applicable) _No response_ ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** Open WebUI and Ollama. - [x] I have included the browser console logs. - [x] I have included the Docker container logs. - [x] I have **provided every relevant configuration, setting, and environment variable used in my setup.** - [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc). - [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. My steps: - Start with the initial platform/version/OS and dependencies used, - Specify exact install/launch/configure commands, - List URLs visited, user input (incl. example values/emails/passwords if needed), - Describe all options and toggles enabled or changed, - Include any files or environmental changes, - Identify the expected and actual result at each stage, - Ensure any reasonably skilled user can follow and hit the same issue. ### Expected Behavior When a new user account is created in Open WebUI through any supported authentication method (password signup, OAuth, or LDAP), and a `WEBHOOK_URL` is configured in the admin settings, Open WebUI should send a POST request to the configured URL with the standard signup payload: ```json { "action": "signup", "message": "<USER_SIGNUP message>", "user": "<user object as JSON>" } ``` This is the documented behavior of the admin signup webhook (https://docs.openwebui.com/features/administration/webhooks/) and is required for any external automation that reacts to new user creation: auto-promotion workflows, provisioning, audit logging, notification channels. ### Actual Behavior When a new user is provisioned through the LDAP authentication path (first successful LDAP login that creates the local user record), `WEBHOOK_URL` is never called. No HTTP request is emitted, no log line is produced, and any external system listening for signup events is silently bypassed. The webhook does fire correctly for: - Password-based signups (handled by `signup_handler` in `routers/auths.py`) - OAuth/OIDC signups (handled in `utils/oauth.py`) But not for LDAP signups, which go through a different code path (`ldap_auth` in `routers/auths.py`) where `post_webhook(...)` is never invoked. This looks like an unintentional omission rather than a design choice — see the root cause analysis in Additional Information. ### Steps to Reproduce 1. Deploy Open WebUI v0.9.2 via Docker. 2. Configure LDAP authentication with valid settings: - ENABLE_LDAP=true - LDAP_SERVER_HOST, LDAP_SERVER_PORT=636, LDAP_USE_TLS=true - LDAP_APP_DN, LDAP_APP_PASSWORD - LDAP_SEARCH_BASE, LDAP_ATTRIBUTE_FOR_USERNAME, LDAP_ATTRIBUTE_FOR_MAIL 3. Set DEFAULT_USER_ROLE=pending (the bug is unrelated to the role). 4. Generate a temporary webhook URL for testing — for example at https://webhook.site (free, no signup needed, instant). 5. Log in to Open WebUI as admin → Admin Panel → Settings → General → set "Webhook URL" to the webhook.site URL → click Save. Verify the value persists in the UI (it's a PersistentConfig variable). 6. Confirm reachability from inside the OWU container: `docker exec -it open-webui curl -v -X POST <webhook_url> -H "Content-Type: application/json" -d '{"test":"manual"}'` The request must succeed and appear on webhook.site. This rules out networking, DNS, TLS, or proxy issues. 7. From a clean browser session, log in for the first time with an LDAP user that does not yet exist in the OWU users table. 8. The login succeeds and the new user appears in Admin Panel → Users. 9. Check webhook.site: no request received. **This is the bug.** 10. Control test: temporarily set ENABLE_SIGNUP=true and create a new user via the password signup form. webhook.site receives the expected `{"action": "signup", ...}` payload. This confirms the webhook configuration itself is correct — the issue is specific to the LDAP code path.7. ### Logs & Screenshots Browser console: N/A (server-side issue). Docker logs are not included to avoid leaking internal infrastructure details. The behavior is fully reproducible and the source-code analysis in "Additional Information" pinpoints the omission directly. Visual evidence (attached): 1. `webhook.site` remains empty after a successful LDAP signup — the new user is created in Admin Panel → Users at the same timestamp. 2. `webhook.site` receives the expected `{"action": "signup", ...}` payload after a control password signup with the same `WEBHOOK_URL` configured. This confirms the webhook configuration is correct and the issue is specific to the LDAP code path. ### Additional Information ## Root cause analysis A direct read of `backend/open_webui/routers/auths.py` on the current `dev` branch confirms the omission. **Password signup path** (`signup_handler`, around line 711) — webhook IS called after user creation: ```python if request.app.state.config.WEBHOOK_URL: await post_webhook( request.app.state.WEBUI_NAME, request.app.state.config.WEBHOOK_URL, WEBHOOK_MESSAGES.USER_SIGNUP(user.name), { 'action': 'signup', 'message': WEBHOOK_MESSAGES.USER_SIGNUP(user.name), 'user': user.model_dump_json(exclude_none=True), }, ) ``` **OAuth signup path** (`backend/open_webui/utils/oauth.py`, around line 1681) — webhook IS also called. **LDAP signup path** (`ldap_auth`, around lines 502–543) — webhook is NOT called. The function inserts the user via `Auths.insert_new_auth`, handles the first-user-becomes-admin promotion, calls `apply_default_group_assignment`, and returns directly to `create_session_response`, skipping the webhook entirely. Since OAuth follows the same pattern as password signup but LDAP does not, this looks like an unintentional gap rather than a design choice. ## Suggested fix Add the same `post_webhook` block to `ldap_auth` immediately after `apply_default_group_assignment`, scoped to the `if not user:` branch so the webhook fires only on actual user creation, not on subsequent logins of existing LDAP users. I'd happily contribute a PR if maintainers confirm the fix is wanted, but I don't currently have a test environment matching the project's quality bar to validate it properly. Hence this issue rather than a PR. ## Impact This affects deployments that combine LDAP authentication with downstream automation triggered by new user signup events: - Auto-promotion workflows that move LDAP users from `pending` to `user` based on an external pre-authorization list - Provisioning pipelines for other systems - Compliance and audit logging that requires real-time notification of new account creation Workaround: polling `GET /api/v1/users/` filtered on `role=='pending'` every few minutes works as a substitute, just with higher latency. ## Related work The scoped-events webhook system in PR #16426 / discussion #16428 introduces an `auth.user.signup` event type. If/when that work lands, the LDAP path will need to be wired in there as well — same fix at the same location.

GiteaMirror added the bug label 2026-05-06 00:36:17 -05:00

GiteaMirror commented

2026-05-06 00:36:19 -05:00

@owui-terminator[bot] commented on GitHub (May 5, 2026):

🔍 Similar Issues Found

I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions:

#23582 issue: [Bug] OIDC Authentication fails after Identity Provider Key Rotation (bad_signature)
by IRScorpio · bug
#21300 issue: LDAP authentication causes the service to hang
by Booting-O · bug
#20389 issue: ENABLE_SIGNUP not working properly
by jayteaftw · bug
#20240 LDAP Authentication Failed (HTTP 400) despite valid config & successful ldap3 connection test
by AgatheBauer · bug
#19792 issue: OAuth Login redirects to https://openwebui.domain.org/oauth/oidc/openwebui.domain.org after succesful login
by StNiosem · bug

💡 If this is a duplicate, consider closing it and adding details to the existing issue.

This comment was generated automatically. React with 👍 if helpful, 👎 if not.

@owui-terminator[bot] commented on GitHub (May 5, 2026): 🔍 **Similar Issues Found** I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions: 1. [#23582](https://github.com/open-webui/open-webui/issues/23582) **issue: [Bug] OIDC Authentication fails after Identity Provider Key Rotation (bad_signature)** *by IRScorpio · `bug`* 2. [#21300](https://github.com/open-webui/open-webui/issues/21300) **issue: LDAP authentication causes the service to hang** *by Booting-O · `bug`* 3. [#20389](https://github.com/open-webui/open-webui/issues/20389) **issue: ENABLE_SIGNUP not working properly** *by jayteaftw · `bug`* 4. [#20240](https://github.com/open-webui/open-webui/issues/20240) **LDAP Authentication Failed (HTTP 400) despite valid config & successful ldap3 connection test** *by AgatheBauer · `bug`* 5. [#19792](https://github.com/open-webui/open-webui/issues/19792) **issue: OAuth Login redirects to https://openwebui.domain.org/oauth/oidc/openwebui.domain.org after succesful login** *by StNiosem · `bug`* --- 💡 If this is a duplicate, consider closing it and adding details to the existing issue. *This comment was generated automatically.* React with 👍 if helpful, 👎 if not.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#58951