← Обзор / ai-search / configuration / retrieval / public-endpoint

Cloudflare Access

A публичная конечная точка намеренно не требует аутентификации. Любой, кто знает URL адрес, может обращаться к вашему проиндексированному содержимому.

Разместите пользовательский домен перед публичной конечной точкой и защитите её с помощью Cloudflare Access. После этого пользователи проходят аутентификацию у вашего провайдера идентификации, прежде чем запрос попадёт в AI Search. Так публичная база знаний становится внутренней без необходимости писать собственный уровень аутентификации.

Пользовательский домен представляет собой имя хоста в зоне, которой вы владеете. Когда CNAME запись для этого имени хоста имеет значение Proxied, запросы проходят через вашу собственную зону, прежде чем попасть в AI Search:

flowchart LR
  A[Client] --> B["Your zone<br/>Access, WAF, Bots"]
  B --> C["AI Search<br/>public endpoint"]
  C --> D[Your indexed content]

Access работает в вашей зоне, поэтому обрабатывает каждый запрос первым. Запросы, которые не проходят политику, никогда не доходят до AI Search. Для этого AI Search не требует никакой настройки и применяет собственную ограничения скорости запросов после этого.

Эта маршрутизация называется orange-to-orange. Для этого требуется CNAME запись, чтобы она проксировалась. DNS only запись полностью обходит вашу зону, и Access вообще не запускается.

• A пользовательский домен на экземпляре или пространстве имён, которые нужно защитить, с Proxied CNAME запись.
• В вашем аккаунте включён Cloudflare Access.
• Одна поставщик удостоверений подключённый к Cloudflare Access, либо одноразовый PIN-код Cloudflare.

Access защищает только ваш пользовательский домен. Значение по умолчанию <PUBLIC_ENDPOINT_ID>.search.ai.cloudflare.com имя хоста не проходит через вашу зону, поэтому оно продолжает отвечать на неаутентифицированные запросы и сводит на нет политику, которую вы собираетесь написать.

Задайте default_domain_enabled к false перед созданием приложения Access.

curl -X PUT "https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/ai-search/namespaces/default/instances/<INSTANCE_ID>" \
  -H "Authorization: Bearer <API_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "public_endpoint_params": {
      "enabled": true,
      "custom_domains": ["access.search.example.com"],
      "default_domain_enabled": false
    }
  }'

Теперь имя хоста по умолчанию возвращает 404 с ошибкой 60018.

Полный набор вариантов см. в Публикация локально размещённого приложения.

Приложение без политики отклоняет все запросы. Добавьте хотя бы одну Политика Allow который описывает, кто может выполнять запросы к вашему содержимому.

Используйте адрес электронной почты, страну, диапазон IP-адресов или группу провайдера идентификации селекторы которые соответствуют вашей организации. Больше примеров см. в Распространённые политики для дополнительных примеров.

Браузеры переходят по перенаправлению для входа Access и получают CF_Authorization cookie-файл. MCP-клиенты, бэкенд-сервисы и скрипты не могут пройти интерактивный вход, поэтому им нужен токен службы.

Отправляйте оба набора учётных данных в виде заголовков с каждым запросом.

curl https://access.search.example.com/search \
  --header "Content-Type: application/json" \
  --header "CF-Access-Client-Id: <CLIENT_ID>" \
  --header "CF-Access-Client-Secret: <CLIENT_SECRET>" \
  --data '{
    "messages": [
      {
        "content": "How do I configure AI Search?",
        "role": "user"
      }
    ]
  }'

{
	"mcpServers": {
		"ai-search": {
			"url": "https://access.search.example.com/mcp",
			"headers": {
				"CF-Access-Client-Id": "<CLIENT_ID>",
				"CF-Access-Client-Secret": "<CLIENT_SECRET>"
			}
		}
	}
}

Поддержка заголовков зависит от MCP-клиента. Если ваш клиент не может отправлять пользовательские заголовки, см. Защита MCP-серверов для альтернатив на основе идентификации, или используйте cloudflared access curl для запросов из командной строки.

Запрос без учётных данных возвращает страницу входа Access вместо результатов поиска:

curl --include https://access.search.example.com/search \
  --header "Content-Type: application/json" \
  --data '{"messages":[{"content":"test","role":"user"}]}'

Убедитесь, что имя хоста по умолчанию закрыто:

curl https://<PUBLIC_ENDPOINT_ID>.search.ai.cloudflare.com/search \
  --header "Content-Type: application/json" \
  --data '{"messages":[{"content":"test","role":"user"}]}'

Ответ представляет собой 404 с кодом ошибки 60018.

• UI-сниппеты на публичном сайте перестают работать. UI-сниппеты вызывают публичный эндпойнт из браузера посетителя. За Access им могут пользоваться только посетители, прошедшие ваши политики. Используйте Access для внутренних сайтов, а для публичных маркетинговых сайтов оставляйте эндпойнт открытым.
• Запросам браузера с другого источника нужна настройка CORS в Access. Если к защищённому имени хоста обращается страница с другого источника, настройте CORS в приложении Access в дополнение к разрешённые origin на публичной конечной точке.
• Ограничения скорости запросов по-прежнему действуют. После Access AI Search применяет собственное ограничение скорости запросов, общее для всех аутентифицированных вызывающих сторон.
• Разрешённые origin не являются аутентификацией. Заголовок authorized_hosts настройка задаёт заголовки ответа CORS, которые учитывают только браузеры. Она не блокирует прямой запрос от curl или скрипт.

После того как CNAME запись проксируется, к этому имени хоста также применяются другие продукты Cloudflare: