Cara Self-host Open Connector untuk Ejen AI

Apakah fungsi Open Connector untuk ejen AI

Self-hosting Open Connector meletakkan satu gerbang pengesahan antara ejen AI anda dan setiap API software as a service (SaaS) yang dipanggil, supaya ejen tersebut tidak memegang token pembekal. Ia merupakan gerbang sumber tersedia daripada OOMOL Lab, yang kini dilesenkan di bawah lesen Apache 2.0 yang diubah suai dengan syarat tambahan. Keluaran sehingga v1.9.4 kekal di bawah Apache 2.0; v1.9.5 memperkenalkan perubahan tersebut. Menyediakan perkhidmatan hos atau terurus yang nilai utamanya ialah fungsi OpenConnector memerlukan lesen komersial daripada OOMOL. Ia berjalan sebagai satu kontena, menyimpan statusnya dalam satu fail SQLite, dan mendedahkan tindakan pembekal melalui HTTP serta MCP (model context protocol).

Masalah bermula pada integrasi kedua. Setiap pembekal mempunyai aliran OAuth (open authorization) sendiri, tempoh hayat token segar semula (refresh token) sendiri, dan nama skop sendiri. Menyambungkan lima pembekal ke dalam ejen secara manual bermakna lima pengendali ubah hala (redirect handler), lima stor kelayakan, dan lima gelung segar semula yang perlu berjalan sebelum token tamat tempoh. Hampir tiada sesiapa yang menulis kod tersebut. Mereka menjana satu personal access token jangka hayat panjang bagi setiap perkhidmatan dan menampalnya ke dalam konfigurasi ejen, fail persekitaran, atau prompt itu sendiri. Token tersebut kemudiannya boleh dibaca oleh setiap alat yang dijalankan oleh ejen, dan ia berakhir dalam transkrip, yang merupakan kegagalan yang diterangkan dalam menjaga rahsia daripada ejen AI.

Gerbang pengesahan memisahkan kelayakan kepada dua bahagian. Gerbang menyimpan kelayakan pembekal dan menjalankan aliran OAuth. Ejen mendapat token masa jalan (runtime token) yang hanya sah terhadap gerbang tersebut. Apabila ejen memanggil sesuatu tindakan, gerbang memuatkan kelayakan yang disimpan, menyuntiknya ke dalam permintaan keluar di bahagian pelayan, dan hanya mengembalikan badan respons. Ejen tidak pernah menerima token akses pembekal, jadi transkrip ejen yang bocor hanya merugikan anda satu token masa jalan yang boleh dibatalkan, bukannya akaun GitHub anda.

Katalog mengiklankan lebih daripada 1,000 pembekal dan 10,000 tindakan pra-bina, yang merupakan angka projek itu sendiri dan bukan sesuatu yang boleh anda sahkan dari luar. Apa yang boleh anda sahkan ialah bentuknya: satu endpoint HTTP bagi setiap tindakan, satu sambungan disimpan bagi setiap pembekal, satu token bagi setiap ejen. Jika bahagian ejen bagi perkara ini masih baharu dan istilah seperti tool call atau MCP server belum lagi mantap, laluan berperingkat dalam cara mempelajari ejen AI dari awal membina gelung, alatan, dan tabiat keselamatan yang diandaikan oleh gerbang seperti ini sudah anda miliki.

Mengapa anda perlu melakukan self-host Open Connector berbanding menggunakan perkhidmatan penyambung (connector) yang dihoskan

Perkhidmatan penyambung yang dihoskan melakukan kerja yang sama, dan ia menyimpan refresh token bagi setiap penyedia yang anda sambungkan kepadanya. Refresh token untuk Google atau GitHub merupakan kunci jangka hayat panjang yang memberikan akses kepada e-mel dan repositori anda. Kebocoran data mereka akan menjadi kebocoran data anda. Self-hosting memindahkan rekod tersebut ke dalam SQLite pada mesin yang anda sewa dan tadbir, yang dimeterai dengan kunci yang tidak pernah keluar dari pelayan anda.

Sebutkan kosnya dengan jelas sebelum anda bermula. VPS ini akan menjadi pelayan paling berharga yang anda jalankan. Ia menyimpan kelayakan kerja untuk sedozen perkhidmatan dalam satu fail, jadi ia perlu dilayan seperti hos pengurus kata laluan: firewall yang hanya mendedahkan port 443, tiada log masuk dikongsi, sandaran yang pernah anda pulihkan sekurang-kurangnya sekali, dan makluman apabila ia berhenti memberi respons. Jika anda tidak akan meletakkan peti simpanan kata laluan anda pada mesin ini, jangan letakkan penyambung (connector) tersebut di atasnya juga.

Tetapkan versi sebelum anda memasang apa-apa

Open Connector masih baharu. Panduan ini mengekalkan v1.3.3, yang diterbitkan pada 30 Julai 2026, sebagai snapshot pemasangan untuk 1 Ogos 2026. Ia bukan lagi keluaran terbaharu. Pendaftaran tersebut juga menerbitkan tag tip, yang dibina daripada commit terbaharu pada main.

Bagi projek yang baharu sebegini, tag yang berubah-ubah sering bergerak. docker compose pull yang melangkau dua keluaran boleh mengubah endpoint yang bergantung pada ejen anda, dan anda akan menghabiskan waktu malam untuk menyahpepijatnya sebagai masalah ejen. Tetapkan imej kepada tag keluaran, dan naik taraf apabila anda membuat keputusan, selepas membaca nota keluaran.

Menggunakan Open Connector di sebalik TLS pada VPS anda sendiri

Sebelum kontena dimulakan, anda memerlukan:

• Docker Engine 28.0.0 atau lebih baharu dengan pemalam Compose, pada Ubuntu 24.04 atau sistem yang setara
• nama hos yang rekod A-nya menghala ke VPS ini, contohnya connect.example.com
• reverse proxy yang sudah melakukan TLS (transport layer security) termination untuk nama hos tersebut
• dua rahsia rawak, dijana di bawah

Panduan Traefik reverse proxy untuk pelbagai aplikasi Docker Compose merangkumi bahagian proksi. Proses penyediaan sijil yang sama, dari mula hingga akhir untuk satu aplikasi, terdapat dalam panduan n8n pada VPS dengan Docker dan HTTPS.

Jana rahsia tersebut terlebih dahulu. Kunci penyulitan (encryption key) mengunci kelayakan yang disimpan. Token pentadbir (admin token) melindungi konsol web dan keseluruhan permukaan /api. Tiada nilai lalai untuk kedua-duanya, dan runtime akan bermula walaupun nilai ini tidak ditetapkan.

mkdir -p ~/open-connector && cd ~/open-connector
umask 077
printf 'OOMOL_CONNECT_ENCRYPTION_KEY=%s\n' "$(openssl rand -base64 32)" > .env
printf 'OOMOL_CONNECT_ADMIN_TOKEN=%s\n' "$(openssl rand -base64 32)" >> .env
chmod 600 .env

Salin kedua-dua nilai ke dalam pengurus kata laluan anda sekarang, sebelum permulaan pertama. Kunci penyulitan tidak mempunyai laluan pemulihan, dan sebabnya dinyatakan dalam senarai kegagalan di bawah.

Sekarang compose.yaml. Ia berbeza daripada contoh upstream pada dua tempat, dan kedua-duanya penting.

services:
  connector:
    image: ghcr.io/oomol-lab/open-connector:v1.3.3
    restart: unless-stopped
    ports:
      - "127.0.0.1:3000:3000"
    volumes:
      - connector-data:/app/data
    environment:
      OOMOL_CONNECT_DATA_DIR: /app/data
      OOMOL_CONNECT_ORIGIN: "https://connect.example.com"
      OOMOL_CONNECT_ENCRYPTION_KEY: "${OOMOL_CONNECT_ENCRYPTION_KEY:?set this in .env}"
      OOMOL_CONNECT_ADMIN_TOKEN: "${OOMOL_CONNECT_ADMIN_TOKEN:?set this in .env}"

volumes:
  connector-data:

Perubahan pertama ialah tag yang dipinkan (pinned tag) dan bukannya latest. Perubahan kedua ialah port. Fail upstream menerbitkan 3000:3000, yang mengikat setiap antara muka pada hos. Docker menulis port yang diterbitkan ke dalam jadual NAT (network address translation) sebelum rantaian penapis ufw melihat paket tersebut, jadi ufw deny 3000 tidak menutup port itu, perangkap yang diterangkan dalam mengapa port Docker memintas ufw. Menulis 127.0.0.1:3000:3000 menerbitkan hanya pada antara muka loopback, dan reverse proxy anda bersambung dari hos yang sama. Sebelum Docker Engine 28.0.0, hos pada segmen L2 yang sama boleh mencapai port yang diterbitkan ke localhost, itulah sebabnya panduan ini memerlukan versi 28.0.0 atau lebih baharu.

:? menandakan setiap pemboleh ubah sebagai wajib, jadi stack akan enggan bermula apabila .env tiada, bukannya bermula dengan kelayakan yang tidak disulitkan. Menyimpan nilai dalam .env dan bukannya dalam fail compose adalah corak daripada fail env dan rahsia Docker Compose. Pastikan /v1 dan /mcp kekal peribadi pada reverse proxy sehingga anda mencipta token runtime pertama di bawah.

docker compose up -d
docker compose logs -n 30 connector
curl -s http://127.0.0.1:3000/health
sudo ss -tlnp | grep 3000

/health menjawab { "ok": true } sebaik sahaja runtime aktif. ss mesti mencetak 127.0.0.1:3000. Baris yang membaca 0.0.0.0:3000 bermakna pendengar terikat pada setiap antara muka IPv4, tetapi tidak membuktikan kebolehcapaian internet: firewall upstream atau peraturan dalam rantaian DOCKER-USER Docker masih boleh menyekat trafik luaran. Connection refused pada pemeriksaan kesihatan bermakna kontena belum mendengar, jadi baca log sebelum anda menyentuh proksi.

    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.connector.rule=Host(`connect.example.com`)"
      - "traefik.http.routers.connector.entrypoints=websecure"
      - "traefik.http.routers.connector.tls.certresolver=le"
      - "traefik.http.services.connector.loadbalancer.server.port=3000"

Mengapa callback OAuth memerlukan origin yang betul

OOMOL_CONNECT_ORIGIN ialah tetapan yang sering dilangkau oleh pengguna, dan tindakan melangkaunya akan menyebabkan OAuth gagal dengan ralat yang kelihatan seperti pepijat pada pihak penyedia. Runtime membina URI ubah hala (redirect URI) daripada origin tersebut, dalam bentuk <origin>/oauth/callback. Jika dibiarkan kosong, origin akan ditetapkan secara lalai kepada http://localhost:3000, jadi runtime menghantar URI ubah hala http://localhost:3000/oauth/callback kepada penyedia, sedangkan aplikasi OAuth anda telah mendaftarkan https://connect.example.com/oauth/callback. Kedua-dua rentetan ini berbeza, maka GitHub akan memberikan respons:

The redirect_uri MUST match the registered callback URL for this application.

Penyedia OAuth mengubah hala pelayar kembali ke URI tersebut, jadi alamat itu mestilah boleh dicapai oleh pelayar berkenaan. OAuth tidak mewajibkan nama hos awam secara universal: OpenConnector mendokumentasikan callback GitHub pada http://localhost:3000/oauth/callback. Pelaksanaan VPS ini menggunakan nama hos dan sijil supaya pelayar boleh mencapai gateway pada origin HTTPS-nya. Tetapkan origin sebelum permulaan pertama, kerana nilai ini dibaca semasa startup: selepas menyunting .env atau compose.yaml, jalankan docker compose up -d sekali lagi untuk mengaplikasikannya.

Sambungkan pembekal pertama anda melalui OAuth

Cipta aplikasi OAuth di pihak pembekal terlebih dahulu. Di GitHub, laluannya ialah Settings, kemudian Developer settings, seterusnya OAuth Apps, dan akhirnya New OAuth App. Tetapkan URL panggil balik kebenaran (authorization callback URL) kepada https://connect.example.com/oauth/callback. Simpan client ID dan client secret tersebut.

Setiap panggilan /api membawa token admin, jadi eksport token tersebut sekali untuk sesi shell semasa.

export ADMIN_TOKEN='paste-the-admin-token'
curl -s https://connect.example.com/api/oauth/configs \
  -H "authorization: Bearer $ADMIN_TOKEN"

Senarai tersebut menunjukkan URI ubah hala (redirect URI) yang dijangkakan oleh runtime untuk setiap pembekal. Ini merupakan cara terpantas untuk menyemak sama ada asal (origin) anda telah berkuat kuasa. Jika ia masih memaparkan localhost, kontena tersebut sedang berjalan dengan nilai lama dan aliran OAuth akan gagal pada langkah terakhir.

Simpan kelayakan pelanggan (client credentials), kemudian mulakan kebenaran.

curl -s -X PUT https://connect.example.com/api/oauth/configs/github \
  -H "authorization: Bearer $ADMIN_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"clientId":"...","clientSecret":"..."}'

curl -s -X POST https://connect.example.com/api/oauth/authorizations \
  -H "authorization: Bearer $ADMIN_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"service":"github"}'

Panggilan kedua mengembalikan authorizationUrl. Buka pautan tersebut dalam pelayar, luluskan skop (scopes), dan pembekal akan menghantar pelayar kembali ke /oauth/callback, di mana runtime menukar kod tersebut dan menyimpan kelayakan. Konsol web pada asal anda melakukan langkah yang sama melalui borang, di sebalik token admin yang sama. Pembekal yang menggunakan API key biasa tidak perlu melalui semua ini: PUT /api/connections/<service> dengan {"authType":"api_key","values":{"apiKey":"..."}} menyimpan kunci tersebut secara terus.

Berikan setiap ejen token masa jalan, jangan sekali-kali memberikan kelayakan

Ejen mengesahkan diri kepada get laluan (gateway) menggunakan token masa jalan yang dijana oleh API pentadbir.

curl -s -X POST https://connect.example.com/api/runtime-tokens \
  -H "authorization: Bearer $ADMIN_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"name":"research-agent"}'

Respons tersebut membawa token yang bermula dengan oct_. Keluarkan satu token bagi setiap ejen dan namakannya mengikut ejen tersebut, kerana membatalkan token yang tidak dapat dikenal pasti bermakna anda membatalkan kesemuanya. Ejen kemudian memanggil tindakan melalui HTTP biasa.

curl -s -X POST https://connect.example.com/v1/actions/github.get_current_user \
  -H "authorization: Bearer oct_..." \
  -H 'content-type: application/json' \
  -d '{"input":{}}'

Jawapan yang sihat ialah sampul yang medan success-nya ialah true, dengan muatan pembekal di bawah data. Token GitHub tidak terdapat di mana-mana dalam respons tersebut. Bagi klien MCP, halakan ia ke https://connect.example.com/mcp dengan pengepala bearer yang sama, dan get laluan akan menawarkan alat penemuan seperti search_actions dan execute_action dan bukannya satu alat bagi setiap API, yang memastikan senarai alat ejen kekal kecil. Menjalankan pelayan MCP pada VPS merangkumi separuh bahagian klien bagi pendawaian tersebut.

Jalankan satu lagi semakan sebelum anda menganggap tugas ini selesai. Ulangi panggilan tindakan dengan pengepala authorization dipadamkan. Panduan permulaan pantas projek itu sendiri memanggil /v1 tanpa sebarang bearer, jadi pemasangan tanpa pengesahan masa jalan yang dikonfigurasikan akan melaksanakan tindakan bagi sesiapa sahaja yang boleh mencapai port tersebut. Jika panggilan tanpa pengesahan anda berjaya, anda mempunyai dua jalan keluar: konfigurasikan token masa jalan dan sahkan bahawa panggilan tanpa nama kini gagal, atau sekat /api, /v1 dan /mcp pada proksi terbalik (reverse proxy) kepada alamat asal ejen anda. /oauth/callback mestilah boleh dicapai oleh pelayar yang melengkapkan kebenaran; ia tidak perlu dibuka kepada seluruh internet.

Hadkan senarai tindakan kepada apa yang diperlukan oleh ejen

Gerbang dengan seribu penyedia di belakangnya merupakan permukaan serangan yang luas untuk diberikan kepada model bahasa. Permukaan ini menjadi lebih luas apabila model tersebut mula membaca teks yang tidak ditulisnya sendiri, kerana halaman yang dikembalikan oleh instans SearXNG anda sendiri yang menjawab carian web ejen boleh membawa arahan yang disasarkan kepada mana-mana tindakan yang dimiliki oleh ejen tersebut. Kekangan yang sama yang membuatkan ejen pengekodan mengambil perubahan terkecil yang berfungsi perlu digunakan pada kebenarannya: berikan hanya segelintir tindakan yang benar-benar diperlukan oleh tugas tersebut, dan tiada yang lain. Dua kawalan mengehadkan perkara ini.

OOMOL_CONNECT_ALLOWED_ACTIONS mengambil senarai benarkan (allowlist) yang dipisahkan dengan koma dan memahami service.* serta *. OOMOL_CONNECT_BLOCKED_ACTIONS ialah senarai sekat (denylist), dan senarai sekat adalah yang utama. Menetapkan senarai benarkan kepada github.get_current_user,github.list_issues bermakna setiap tindakan lain akan ditolak tidak kira apa yang diminta oleh ejen, yang merupakan perbezaan antara kesilapan dan insiden. Token masa jalan (runtime tokens) membawa peraturan tindakan mereka sendiri di samping peraturan global, dan senarai allowedProxies mereka bermula dalam keadaan kosong, jadi POST /v1/proxy/:service akan ditolak sehingga anda memberikannya. Titik akhir proksi tersebut memajukan permintaan mentah kepada penyedia dengan kelayakan anda dilampirkan, jadi biarkan ia kosong kecuali satu ejen khusus memerlukannya.

OOMOL_CONNECT_ALLOW_PRIVATE_NETWORK ditetapkan secara lalai kepada false, yang menghalang sambungan penyedia yang dihoskan sendiri daripada menghala ke alamat peribadi seperti perkhidmatan metadata awan pada 169.254.169.254, atau pangkalan data anda pada rangkaian yang sama. Biarkan ia dimatikan. Hidupkannya hanya untuk penyedia yang anda hoskan sendiri.

Sandarkan kotak yang menyimpan setiap token

Dua perkara adalah penting, dan setiap satunya tidak berguna tanpa yang lain. Pangkalan data pada /app/data/connect.sqlite di dalam volum connector-data menyimpan kelayakan yang dimeterai. Kunci penyulitan dalam .env pula menyahsulit kelayakan tersebut. Sandaran volum tanpa kunci tidak akan memulihkan apa-apa, dan kunci tanpa volum juga tidak akan memulihkan apa-apa, jadi simpan kunci dalam pengurus kata laluan anda dan masukkan volum ke dalam kitaran sandaran biasa anda.

Hentikan kontena semasa anda menyalin fail SQLite, kerana salinan yang diambil semasa proses penulisan boleh menyebabkan pangkalan data yang dipulihkan menjadi rosak.

docker volume ls | grep connector-data
docker compose stop connector
docker run --rm -v open-connector_connector-data:/data -v "$PWD":/backup alpine \
  tar czf /backup/connector-data.tgz -C /data .
docker compose start connector

Nama volum adalah direktori projek anda ditambah dengan _connector-data, itulah sebabnya arahan pertama diletakkan di situ: tampal nama sebenar ke dalam arahan ketiga. Hantar arkib keluar dari VPS dengan sandaran restic daripada VPS, yang menyulitkan arkib tersebut sebelum ia dihantar keluar, kerana arkib itu merupakan stor kelayakan.

Runtime menyimpan rekod tindakan terkini sebagai rekod audit, secara lalai sebanyak 5,000 rekod, supaya konsol boleh memberitahu anda ejen mana yang menjalankan apa dan bila. Log tersebut adalah perkara pertama yang perlu dibaca apabila ejen berkelakuan pelik. Halakan halaman status Uptime Kuma ke https://connect.example.com/health juga. Apabila get laluan berhenti memberi respons, ejen akan gagal dengan cara yang mengelirukan, dan mengetahui bahawa get laluan tidak berfungsi dapat menjimatkan masa selama sejam daripada membaca output ejen.

Apa yang rosak, dan mesej yang akan anda lihat

redirect_uri_mismatch di pihak pembekal. Origin dan URL panggil balik (callback URL) yang didaftarkan tidak sepadan. Bandingkan rentetan tepat daripada /api/oauth/configs dengan tetapan aplikasi pembekal, termasuk https berbanding http dan sebarang garis miring (trailing slash) di hujungnya.

Setiap panggilan /api mengembalikan 401. Pengepala (header) token pentadbir hilang atau tersalah eja. Pengepala tersebut ialah Authorization: Bearer <token>, dan konsol web meminta token yang sama.

Kontena berjalan, dan kelayakan (credentials) disimpan dalam teks biasa. Ini berlaku apabila OOMOL_CONNECT_ENCRYPTION_KEY tidak pernah sampai ke kontena, kerana runtime menyimpan rekod kelayakan tanpa penyulitan dan bukannya enggan bermula. Buktikan perkara ini pada pemasangan anda sendiri: sambungkan pembekal dengan kunci API yang anda kenali, kemudian cari kunci tersebut di dalam pangkalan data.

docker compose cp connector:/app/data/connect.sqlite /tmp/connect.sqlite
grep -c 'github_pat_' /tmp/connect.sqlite
shred -u /tmp/connect.sqlite

Kiraan melebihi 0 bermakna kunci tidak berkuat kuasa, jadi pastikan .env berada dalam direktori yang sama dengan compose.yaml dan docker compose config memaparkan nilai tersebut. Apabila kunci ditetapkan, carian yang sama akan mengembalikan 0, kerana rekod tersebut dimeterai dengan AES-256-GCM (advanced encryption standard, 256-bit key, Galois/counter mode).

Tiada apa-apa yang boleh dinyahsulit selepas pemulihan (restore). Kunci penyulitan telah berubah atau hilang. Kunci tersebut tidak pernah ditulis bersebelahan dengan data, mengikut reka bentuknya, jadi tiada laluan pemulihan dan tiada tiket sokongan yang dapat membantu. Sambungkan semula setiap pembekal. Putaran (rotation) disokong melalui pemboleh ubah kunci yang berasingan dan arahan data dalam runtime, jadi baca nota keluaran (release notes) terkini sebelum anda memutar apa-apa.

Ejen mendapat ralat yang menamakan tindakan yang boleh dilihat dalam katalog. Penemuan (discovery) dan pelaksanaan (execution) adalah berasingan. Sesuatu tindakan boleh muncul dalam search_actions tetapi masih ditolak oleh OOMOL_CONNECT_ALLOWED_ACTIONS, oleh senarai hitam (denylist), atau oleh peraturan token runtime itu sendiri.

Peningkatan (upgrades). Sandarkan volum, sunting tag imej kepada keluaran baharu, kemudian docker compose pull && docker compose up -d. Pantau docker compose logs -n 50 connector untuk melihat baris migrasi, dan jalankan semula pemeriksaan kesihatan serta satu tindakan sebenar sebelum anda mempercayainya semula. Melakukan rollback bermakna meletakkan semula tag lama, yang hanya berfungsi kerana anda telah menetapkannya (pinned).

FAQ

Adakah saya memerlukan domain awam untuk mengehos sendiri Open Connector?

Bagi penyedia yang menggunakan API key, tidak: gateway pada 127.0.0.1 sudah memadai. OAuth juga tidak semestinya memerlukan domain awam: OpenConnector mendokumentasikan callback tempatan GitHub sebagai http://localhost:3000/oauth/callback. Pelayar yang melengkapkan kebenaran mesti boleh mencapai URL callback tersebut. Untuk penempatan VPS ini, tetapkan OOMOL_CONNECT_ORIGIN kepada hostname https:// anda sebelum permulaan pertama, dan daftarkan <origin>/oauth/callback dalam aplikasi OAuth penyedia tersebut.

Apakah yang berlaku jika saya kehilangan kunci penyulitan Open Connector?

Kredensial yang disimpan tidak boleh dinyahsulit, dan tiada cara pemulihan. Kunci tersebut sengaja tidak disimpan bersama data supaya sesiapa yang memegang pangkalan data tidak boleh membacanya, termasuk anda sendiri. Satu-satunya pilihan anda ialah menetapkan kunci baharu dan menyambung semula setiap penyedia. Simpan kunci tersebut dalam pengurus kata laluan dan pangkalan data dalam kitaran sandaran anda, kerana pemulihan memerlukan kedua-duanya.

Bolehkah ejen AI saya melihat token akses penyedia?

Tidak apabila ia memanggil melalui gateway. Ejen mengesahkan diri dengan token runtime yang bermula dengan oct_, dan gateway menyuntik kredensial penyedia ke dalam permintaan keluar pada pelayan, lalu hanya memulangkan respons. Dua perkara melanggar sifat tersebut: endpoint /v1/proxy/:service, yang memajukan permintaan mentah dengan kredensial anda dilampirkan dan yang geran-gerannya bermula kosong atas sebab tertentu, serta menampal API key ke dalam ejen sendiri, yang melangkau gateway sepenuhnya.

Patutkah gateway boleh dicapai dari internet awam?

Callback OAuth mesti boleh dicapai oleh pelayar yang melengkapkan kebenaran, yang tidak memerlukan akses daripada seluruh internet. Dengan Docker Engine 28.0.0 atau lebih baharu dan rangkaian bridge lalai, terbitkan port kontena pada 127.0.0.1 untuk memastikan port yang diterbitkan hanya boleh diakses dari hos, dan letakkan reverse proxy di hadapan. Keluaran Docker yang lebih lama membenarkan hos pada segmen L2 yang sama mencapai port yang diterbitkan pada localhost. Kemudian, uji satu panggilan tindakan tanpa header authorization. Jika ia berjaya, hadkan /api, /v1 dan /mcp pada proxy kepada alamat yang digunakan oleh ejen anda sehingga hanya panggilan yang disahkan sahaja yang berfungsi.

Adakah Open Connector sedia untuk kegunaan pengeluaran?

Keluaran semasa menggunakan lesen Apache 2.0 yang diubah suai dengan syarat tambahan; keluaran sehingga v1.9.4, termasuk v1.3.3 yang disematkan, kekal sebagai Apache 2.0. Perkhidmatan penyambung yang dihoskan atau diuruskan yang nilai utamanya ialah fungsi OpenConnector memerlukan lesen komersial daripada OOMOL di bawah lesen semasa. Perintah pemasangan v1.3.3 kekal sebagai snapshot pada 1 Ogos 2026, dan keluaran tersebut dilancarkan pada 30 Julai 2026. Jalankannya dengan menyematkannya pada tag keluaran, jangan sekali-kali pada latest atau tip, baca nota keluaran sebelum setiap naik taraf, dan simpan sandaran volum yang pernah anda pulihkan sekali. Reka bentuknya adalah kukuh untuk pelayan milik anda, dan risikonya terletak pada perubahan versi yang kerap, bukan pada seni bina.