infiniflow / infiniflow/ragflow

[Feature Request]: Support custom CA certificate / SSL verification option for WebDAV connector

Open
#16,635 3 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

💞 feature
Dominant language
Go
Stars
91k
Forks
10.8k
Avg merge
1d 14h
Merged PRs (30d)
705

Description

Self Checks
  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report (Language Policy).
  • Non-english title submitions will be closed directly ( 非英文标题的提交将会被直接关闭 ) (Language Policy).
  • Please do not modify this template :) and fill in all the required fields.
Is your feature request related to a problem?
`webdav_connector.py` instantiates the WebDAV client without any SSL verification override:


self.client = WebDAVClient(base_url=self.base_url, auth=(username, password))


This means `httpx`'s default certificate verification against public root CAs is always used. Self-hosted WebDAV servers (OpenMediaVault, Synology NAS, home-lab Nextcloud/Apache instances, etc.) very commonly use self-signed certificates, since they're not exposed to the public internet. In that case, the connection fails with an SSL certificate verification error, and the WebDAV data source cannot sync at all.

The only current workaround is to patch the source file directly to pass a `verify=` argument pointing to a local CA bundle. This requires shell access to the container and isn't upgrade-safe — reapplying the patch after an image update without checking for an existing `verify=` argument can result in a duplicate keyword argument and a hard SyntaxError that crashes the entire RAGFlow backend on startup.
Describe the feature you'd like

Add an optional field to the WebDAV data source configuration (both in the connector class and the corresponding UI form), e.g.:

  • ca_cert_path (string, optional): path to a custom CA certificate/bundle mounted into the container, passed as verify=ca_cert_path to WebDAVClient.
  • Alternatively/additionally, a verify_ssl boolean toggle (default true) to allow disabling verification entirely for quick testing, with a clear warning in the UI about the security implications.

This would let self-hosted users configure trust for their own certificate directly through the data source settings, without touching source code.

Describe implementation you've considered

Manually patching webdav_connector.py and bind-mounting the patched file in docker-compose.yml to survive image updates. Functional, but fragile and not discoverable for most users, and error-prone if the patch is reapplied without checking whether a verify= argument already exists.

Documentation, adoption, use case
Example: a home-lab user running RAGFlow in Docker, connecting to a WebDAV share on OpenMediaVault (or Synology, self-hosted Nextcloud, etc.) secured with a self-signed certificate. Currently the only path forward is to patch source code inside the container. Related connectors in the same codebase (S3/blob, Seafile) may have similar needs for self-hosted/on-premise deployments with internal CAs.
Additional information

Happy to provide the exact traceback and reproduction steps from a real-world OMV setup if useful.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with webdav_connector.py and the corresponding WebDAV data source UI form, then trace how connector settings reach WebDAVClient. Compare the optional CA path and SSL toggle requested in the issue, including the UI warning for disabled verification. Done means users can configure a self-hosted WebDAV certificate without patching source files.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
backend, frontend
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.