Jinsi ya kujihudumia Open Connector kwa mawakala wa AI

Open Connector hufanya nini kwa wakala wa AI

Kujihudumia Open Connector huweka lango moja la uthibitishaji kati ya mawakala wako wa AI na API zote za software as a service (SaaS) wanazoita, hivyo wakala huwa hashikilii tokeni ya mtoa huduma. Ni lango la open source kutoka OOMOL Lab, lenye leseni ya Apache 2.0. Huendeshwa kama container moja, huhifadhi hali yake katika faili moja ya SQLite, na hutoa vitendo vya watoa huduma kupitia HTTP na MCP (model context protocol).

Tatizo huanza kwenye muunganisho wa pili. Kila mtoa huduma ana mtiririko wake wa OAuth (open authorization), muda wake wa uhai wa refresh token, na majina yake ya scope. Kuunganisha watoa huduma watano kwa mkono kwenye wakala kunahitaji vishughulikiaji vitano vya redirect, hifadhi tano za vitambulisho, na mizunguko mitano ya refresh inayopaswa kuendeshwa kabla tokeni haijaisha muda. Karibu hakuna anayeandika msimbo huo. Badala yake, hutengeneza personal access token moja ya muda mrefu kwa kila huduma na kuiweka kwenye usanidi wa wakala, faili la mazingira, au prompt yenyewe. Tokeni hiyo inaweza kusomeka na kila zana inayoendeshwa na wakala, na huingia kwenye nakala ya mazungumzo; hili ndilo tatizo linaloelezwa na kuweka siri nje ya mawakala wa AI.

Lango la uthibitishaji hugawanya kitambulisho katika sehemu mbili. Lango huhifadhi kitambulisho cha mtoa huduma na huendesha mtiririko wa OAuth. Wakala hupata tokeni ya wakati wa utekelezaji ambayo ni halali tu inapowasilishwa kwa lango. Wakala anapokiita kitendo, lango hupakia kitambulisho kilichohifadhiwa, hukichomeka upande wa server kwenye ombi linalotoka, kisha hurudisha mwili wa jibu pekee. Wakala hapokei kamwe access token ya mtoa huduma, hivyo nakala ya mazungumzo ya wakala ikivuja, gharama yake ni tokeni moja ya wakati wa utekelezaji inayoweza kubatilishwa badala ya akaunti yako ya GitHub.

Katalogi inatangaza zaidi ya watoa huduma 1,000 na vitendo 10,000 vilivyojengwa awali. Hii ni takwimu ya mradi wenyewe, si jambo unaloweza kuthibitisha kutoka nje. Unachoweza kuthibitisha ni muundo wake: endpoint moja ya HTTP kwa kila kitendo, connection moja iliyohifadhiwa kwa kila mtoa huduma, na tokeni moja kwa kila wakala.

Kwa nini ujisimamie Open Connector badala ya kutumia huduma ya kiunganishi inayosimamiwa

Huduma ya kiunganishi inayosimamiwa hufanya kazi hiyo hiyo, na huhifadhi tokeni za kusasisha za kila mtoa huduma unayemunganisha nayo. Tokeni ya kusasisha ya Google au GitHub ni ufunguo wa muda mrefu wa kufikia barua pepe na hazina zako, na kwa kawaida hubaki halali baada ya kubadilisha nenosiri. Kuvamiwa kwao kunakuwa kuvamiwa kwako. Kujisimamia huhamisha rekodi hizo hadi kwenye SQLite kwenye mashine unayokodisha na kuisimamia, zikiwa zimelindwa kwa ufunguo ambao hautoki kamwe kwenye mashine yako.

Taja gharama hiyo wazi kabla ya kuanza. VPS hii inakuwa server yenye thamani kubwa zaidi unayoendesha. Inahifadhi vitambulisho vinavyotumika vya huduma kadhaa katika faili moja, kwa hiyo inahitaji ulinzi unaoupa host ya kidhibiti cha nenosiri: firewall inayoweka wazi 443 pekee, hakuna logins zinazoshirikiwa, backup ambayo umeirejesha angalau mara moja, na alert inapokosa kujibu. Ikiwa usingeweka vault yako ya nenosiri kwenye mashine hii, usiweke connector humo pia.

Funga toleo kabla ya kusakinisha chochote

Open Connector ni mpya. Hifadhi hii ilionekana kwa mara ya kwanza tarehe 29 June 2026. Kufikia 1 August 2026, toleo jipya zaidi lenye tagi ni v1.3.3, lililochapishwa tarehe 30 July 2026 na pia likiwa na tagi ya latest. Registry pia huchapisha tagi ya tip, iliyoundwa kutokana na commit mpya zaidi kwenye main.

Katika mradi huu mpya, tagi zinazosonga hubadilika mara kwa mara. docker compose pull inayoruka matoleo mawili inaweza kubadilisha endpoint ambayo agent yako inategemea, na utatumia jioni nzima kutatua tatizo hilo ukidhani limesababishwa na agent. Weka image kwenye tagi ya toleo, kisha usasishe utakapoamua kufanya hivyo baada ya kusoma maelezo ya toleo.

Weka Open Connector nyuma ya TLS kwenye VPS yako

Kabla ya container kuanza unahitaji:

• Docker yenye Compose plugin, kwenye Ubuntu 24.04 au mfumo unaokaribiana nayo
• hostname ambayo rekodi yake ya A inaelekeza kwenye VPS hii, kwa mfano connect.example.com
• reverse proxy ambayo tayari inakamilisha TLS (usalama wa safu ya usafirishaji) kwa hostname hiyo
• siri mbili za nasibu, zitakazozalishwa hapa chini

Reverse proxy ya Traefik kwa programu nyingi za Docker Compose inaeleza upande wa proxy. Usanidi huo huo wa certificate, kutoka mwanzo hadi mwisho kwa programu moja, unaelezwa kwenye mwongozo wa n8n kwenye VPS yenye Docker na HTTPS.

Tengeneza siri kwanza. Encryption key hulinda credentials zilizohifadhiwa. Admin token hulinda web console na sehemu yote ya /api. Hakuna kati yake iliyo na thamani chaguo-msingi, na runtime huanza bila matatizo hata ikiwa haipo.

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

Nakili thamani zote mbili kwenye password manager yako sasa, kabla ya kuanza kwa mara ya kwanza. Encryption key haina njia ya kurejeshwa, na sababu imeelezwa kwenye orodha ya hitilafu hapa chini.

Sasa compose.yaml. Inatofautiana na mfano wa upstream katika sehemu mbili, na zote ni muhimu.

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:

Mabadiliko ya kwanza ni tag iliyowekwa badala ya latest. La pili ni port. Faili ya upstream huchapisha 3000:3000, ambayo hufungamana na kila interface kwenye host. Docker huandika ports zake zilizochapishwa kwenye jedwali la NAT (network address translation) kabla chain ya ufw filter haijaona packet, kwa hiyo ufw deny 3000 haifungi port hiyo. Hili ndilo tatizo lililoelezwa kwenye kwa nini ports za Docker hupita ufw. Kuandika 127.0.0.1:3000:3000 huchapisha kwenye loopback interface pekee, na reverse proxy yako huunganisha kutoka kwenye host hiyo hiyo.

:? huashiria kila variable kuwa ya lazima, kwa hiyo stack hukataa kuanza wakati .env haipo badala ya kuanza bila credentials zilizosimbwa. Kuhifadhi thamani hizo kwenye .env badala ya compose file ni muundo kutoka env files na secrets za Docker Compose.

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 hujibu { "ok": true } baada ya runtime kuanza. ss lazima ichapishe 127.0.0.1:3000. Mstari unaosomeka 0.0.0.0:3000 unamaanisha kuwa port mapping bado ni ile ya upstream, na gateway inajibu mtandao wote moja kwa moja. Ikiwa health check inarudisha connection refused, container bado haisikilizi, kwa hiyo soma logs kabla ya kugusa proxy.

    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"

Kwa nini OAuth inakulazimisha kuwa na jina halisi la seva

OOMOL_CONNECT_ORIGIN ni mpangilio ambao watu huupuuza, na kuupuuza husababisha OAuth ishindwe kwa njia inayoonekana kama hitilafu ya mtoa huduma. Runtime huunda URI ya kuelekeza upya kutokana na origin hiyo, kwa muundo wa <origin>/oauth/callback. Ikiwa haijawekwa, origin huwa http://localhost:3000 kwa chaguo-msingi. Kwa hiyo runtime humtumia mtoa huduma URI ya kuelekeza upya ya http://localhost:3000/oauth/callback, ilhali programu yako ya OAuth imesajili https://connect.example.com/oauth/callback. Kamba hizo mbili zinatofautiana, hivyo GitHub hujibu:

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

Mtoa huduma wa OAuth humwelekeza kivinjari kwenye URI hiyo. Hivyo, URI hiyo lazima iwe anwani inayoweza kufikiwa na watu kutoka nje. Watoa huduma hukataa http:// isiyo na usimbaji kwa kila kitu isipokuwa localhost. Hiyo ndiyo sababu deployment hii inahitaji jina la seva na cheti. Weka origin kabla ya kuanzisha kwa mara ya kwanza, kwa sababu thamani husomwa wakati wa kuanzisha. Baada ya kuhariri .env au compose.yaml, endesha docker compose up -d tena ili kutumia mabadiliko.

Unganisha mtoa huduma wako wa kwanza kupitia OAuth

Kwanza, unda programu ya OAuth kwenye mtoa huduma. Kwenye GitHub, nenda kwenye Settings, kisha Developer settings, OAuth Apps, halafu New OAuth App. Weka URL ya callback ya uidhinishaji kuwa https://connect.example.com/oauth/callback. Hifadhi client ID na client secret.

Kila ombi la /api hubeba tokeni ya msimamizi, kwa hiyo i-export mara moja kwa kipindi cha shell.

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

Orodha hiyo inaonyesha URI ya uelekezaji upya ambayo runtime inatarajia kwa kila mtoa huduma. Hii ndiyo njia ya haraka zaidi ya kuthibitisha kuwa origin yako imetumika. Ikiwa bado inaonyesha localhost, container inaendesha kwa thamani ya zamani na mtiririko wa OAuth utashindwa katika hatua ya mwisho.

Hifadhi vitambulisho vya client, kisha uanze uidhinishaji.

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"}'

Ombi la pili linarudisha authorizationUrl. Ifungue kwenye kivinjari, kubali scopes, kisha mtoa huduma atarudisha kivinjari kwenye /oauth/callback. Hapo runtime itabadilishana code na kuhifadhi credential. Web console kwenye origin yako hupitia hatua hizo hizo kwa kutumia fomu, ikiwa nyuma ya tokeni hiyo hiyo ya msimamizi. Watoa huduma wanaotumia API key ya kawaida huruka mchakato huu wote: PUT /api/connections/<service> pamoja na {"authType":"api_key","values":{"apiKey":"..."}} huhifadhi key moja kwa moja.

Mpa kila wakala tokeni ya wakati wa utekelezaji, kamwe si kitambulisho

Wakala hujithibitisha kwa gateway kwa kutumia tokeni ya wakati wa utekelezaji, ambayo API ya msimamizi hutengeneza.

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"}'

Jibu lina tokeni inayoanza na oct_. Toa tokeni moja kwa kila wakala na ipe jina la wakala huyo, kwa sababu kubatilisha tokeni usiyoweza kuitambua kunamaanisha kubatilisha tokeni zote. Kisha wakala huita vitendo kupitia HTTP ya kawaida.

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":{}}'

Jibu sahihi ni envelope ambayo sehemu yake ya success ni true, huku payload ya mtoa huduma ikiwa chini ya data. Tokeni ya GitHub haipo popote katika jibu hilo. Kwa mteja wa MCP, mwelekeze kwenye https://connect.example.com/mcp ukitumia kichwa kilekile cha bearer, na gateway itatoa zana za ugunduzi kama search_actions na execute_action badala ya zana moja kwa kila API. Hilo huweka orodha ya zana za wakala ikiwa ndogo. Kuendesha seva za MCP kwenye VPS inaeleza upande wa mteja wa usanidi huo.

Fanya ukaguzi mmoja zaidi kabla ya kutangaza kuwa umemaliza. Rudia mwito wa kitendo baada ya kufuta kichwa cha authorization. Quickstart ya mradi yenyewe huita /v1 bila bearer yoyote, kwa hiyo usakinishaji usio na uthibitishaji wa wakati wa utekelezaji uliosanidiwa utatekeleza vitendo kwa mtu yeyote anayeweza kufikia port hiyo. Ikiwa mwito wako usio na uthibitishaji utafaulu, una njia mbili za kurekebisha hali hiyo: sanidi tokeni za wakati wa utekelezaji na uthibitishe kuwa mwito usiojulikana sasa unashindwa, au zuia /api, /v1 na /mcp kwenye reverse proxy ili ziruhusu anwani ambazo mawakala wako hutoka. Ni /oauth/callback pekee inayopaswa kubaki wazi kwa umma, kwa sababu hiyo ndiyo njia pekee inayohitajiwa na uelekezaji upya wa kivinjari cha mtoa huduma.

Punguza orodha ya vitendo hadi vile ambavyo wakala anahitaji

Lango lenye watoa huduma elfu moja nyuma yake lina eneo pana sana la kumpa modeli ya lugha. Vidhibiti viwili hulipunguza.

OOMOL_CONNECT_ALLOWED_ACTIONS hupokea orodha ya kuruhusu iliyotenganishwa kwa koma na kuelewa service.* na *. OOMOL_CONNECT_BLOCKED_ACTIONS ni orodha ya kukataa, na orodha ya kukataa huwa na kipaumbele. Kuweka orodha ya kuruhusu kuwa github.get_current_user,github.list_issues kunamaanisha kuwa kila kitendo kingine kinakataa, bila kujali wakala anaomba nini. Hii ndiyo tofauti kati ya kosa na tukio la usalama. Tokeni za wakati wa utekelezaji huwa na sheria zao za vitendo juu ya sheria za kimataifa. Orodha yao ya allowedProxies huanza ikiwa tupu, kwa hiyo POST /v1/proxy/:service hukataliwa hadi uiruhusu. Endpoint hiyo ya proksi hutuma ombi ghafi kwa mtoa huduma ikiwa na kitambulisho chako cha ufikiaji. Iache ikiwa tupu isipokuwa wakala mmoja mahususi anaihitaji.

OOMOL_CONNECT_ALLOW_PRIVATE_NETWORK huwa na thamani chaguo-msingi ya false. Hii huzuia muunganisho wa mtoa huduma unayejihudumia kuelekezwa kwenye anwani ya faragha, kama vile huduma ya metadata ya wingu kwenye 169.254.169.254, au hifadhidata yako iliyo kwenye mtandao huo huo. Iache ikiwa imezimwa. Iwashe tu kwa mtoa huduma unayemiliki na kumhudumia mwenyewe.

Hifadhi nakala ya seva inayohifadhi tokeni zote

Mambo mawili ni muhimu, na kila moja haliwezi kutumika bila lingine. Hifadhidata iliyo katika /app/data/connect.sqlite ndani ya ujazo wa connector-data huhifadhi vitambulisho vilivyofungwa. Ufunguo wa usimbaji fiche katika .env hufungua vitambulisho hivyo. Nakala ya ujazo bila ufunguo haiwezi kurejesha chochote, na ufunguo bila ujazo pia hauwezi kurejesha chochote. Kwa hiyo, hifadhi ufunguo katika kidhibiti chako cha nywila, na ujumuishe ujazo katika mzunguko wako wa kawaida wa kuhifadhi nakala.

Simamisha kontena unapokuwa unanakili faili ya SQLite. Nakala inayochukuliwa wakati wa uandishi inaweza kurejeshwa ikiwa hifadhidata imeharibika.

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

Jina la ujazo ni saraka ya mradi wako pamoja na _connector-data. Ndiyo sababu amri ya kwanza ipo hapo: bandika jina halisi katika amri ya tatu. Tuma kumbukumbu nje ya VPS ukitumia nakala rudufu za restic kutoka VPS. Hii huisimba kabla haijaondoka, kwa sababu kumbukumbu hiyo ndiyo hifadhi ya vitambulisho.

Runtime huhifadhi utekelezaji wa hivi karibuni wa vitendo kama rekodi za ukaguzi, 5,000 kwa chaguo-msingi. Hivyo, dashibodi inaweza kukuonyesha ni agent gani ilitekeleza kitendo gani na lini. Soma kumbukumbu hiyo kwanza agent inapofanya mambo yasiyo ya kawaida. Pia elekeza ukurasa wa hali wa Uptime Kuma kwenye https://connect.example.com/health. Gateway inapoacha kujibu, agent hushindwa kwa njia zinazochanganya. Kujua kuwa gateway iko chini kunaweza kuokoa saa moja ya kusoma matokeo ya agent.

Kinachoharibika, na ujumbe utakaouona

redirect_uri_mismatch kwa mtoa huduma. Asili na URL ya callback iliyosajiliwa hazilingani. Linganisha mfuatano halisi kutoka /api/oauth/configs na mipangilio ya programu ya mtoa huduma, ikijumuisha https dhidi ya http na slash yoyote ya mwisho.

Kila ombi la /api linarudisha 401. Kichwa cha tokeni ya msimamizi hakipo au kimeandikwa vibaya. Kichwa hicho ni Authorization: Bearer <token>, na kiweko cha wavuti huomba tokeni hiyo hiyo.

Kontena linaendesha, na vitambulisho vimehifadhiwa kama maandishi wazi. Hali hii hutokea wakati OOMOL_CONNECT_ENCRYPTION_KEY haifiki kwenye kontena, kwa sababu runtime huhifadhi rekodi za vitambulisho bila usimbaji badala ya kukataa kuanza. Thibitisha kwenye usakinishaji wako: unganisha mtoa huduma kwa kutumia API key unayoweza kuitambua, kisha itafute kwenye database.

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

Idadi iliyo juu ya 0 inamaanisha kuwa key haitumiki, kwa hiyo hakikisha .env iko kwenye saraka moja na compose.yaml na kwamba docker compose config inaonyesha thamani hiyo. Key ikiwa imewekwa, utafutaji huo huo hurudisha 0, kwa sababu rekodi imefungwa kwa AES-256-GCM (kiwango cha juu cha usimbaji, key ya biti 256, hali ya Galois/counter).

Hakuna kinachoweza kusimbuliwa baada ya kurejesha nakala. Key ya usimbaji imebadilika au imepotea. Haiandikwi kamwe karibu na data, kwa usanifu, kwa hiyo hakuna njia ya kurejesha data na hakuna tiketi ya usaidizi itakayosaidia. Unganisha tena kila mtoa huduma. Kubadilisha key kunaungwa mkono kupitia kigezo tofauti cha key na amri ya data katika runtime, kwa hiyo soma maelezo ya toleo la sasa kabla ya kubadilisha key yoyote.

Agent inapata hitilafu inayotaja kitendo ambacho inaweza kukiona kwenye katalogi. Ugunduzi na utekelezaji ni michakato tofauti. Kitendo kinaweza kuonekana kwenye search_actions na bado kikakataliwa na OOMOL_CONNECT_ALLOWED_ACTIONS, na denylist, au na sheria za tokeni hiyo ya runtime.

Uboreshaji wa matoleo. Tengeneza nakala rudufu ya volume, hariri tag ya image iwe toleo jipya, kisha docker compose pull && docker compose up -d. Fuatilia docker compose logs -n 50 connector ili kuona mstari wa uhamishaji, kisha endesha tena ukaguzi wa afya na kitendo kimoja halisi kabla ya kukiamini tena. Kurudisha toleo la awali kunamaanisha kuweka tena tag ya zamani; hii hufanya kazi kwa sababu uliibandika.

FAQ

Je, ninahitaji kikoa cha umma ili kujiendeshea Open Connector?

Kwa watoa huduma wanaotumia ufunguo wa API, hapana: gateway kwenye 127.0.0.1 inatosha. Kwa OAuth, kwa vitendo ndiyo. Mtoa huduma humwelekeza kivinjari kwenye URL yako ya callback, kwa hiyo URL hiyo lazima ipatikane kutoka kwenye intaneti ya umma, na watoa huduma hukataa http:// isiyo salama nje ya localhost. Weka OOMOL_CONNECT_ORIGIN iwe jina la hosti la https:// kabla ya kuanza kwa mara ya kwanza, na usajili <origin>/oauth/callback katika programu ya OAuth ya mtoa huduma.

Nini hutokea nikimpoteza ufunguo wa usimbaji wa Open Connector?

Vitambulisho vilivyohifadhiwa haviwezi kusimbuliwa, na hakuna njia ya kuvirejesha. Ufunguo huo hauhifadhiwi kamwe pamoja na data kimakusudi, kwa hiyo hakuna mtu aliye na hifadhidata anayeweza kuisoma, ukiwemo wewe. Chaguo lako pekee ni kuweka ufunguo mpya na kuunganisha tena kila mtoa huduma. Hifadhi ufunguo katika kidhibiti cha nywila na hifadhidata katika mzunguko wako wa nakala rudufu, kwa sababu urejeshaji unahitaji vyote viwili.

Je, wakala wangu wa AI anaweza kuona tokeni ya ufikiaji ya mtoa huduma?

Si wakati anapiga simu kupitia gateway. Wakala hujithibitisha kwa tokeni ya wakati wa utekelezaji inayoanza na oct_, na gateway huingiza kitambulisho cha mtoa huduma katika ombi linalotoka kwenye seva, kisha hurudisha jibu pekee. Mambo mawili huvunja sifa hiyo: endpoint ya /v1/proxy/:service, ambayo hupitisha maombi ghafi ikiwa na kitambulisho chako na ambayo ruhusa zake huanza zikiwa tupu kwa sababu maalumu, na kubandika ufunguo wa API wewe mwenyewe katika wakala, hali inayoruka gateway kabisa.

Je, gateway inapaswa kufikiwa kutoka kwenye intaneti ya umma?

Ni /oauth/callback pekee inayopaswa kufikiwa. Chapisha port ya kontena kwenye 127.0.0.1 ili sheria za NAT za Docker zisiweze kuiweka wazi upande wa firewall yako, kisha weka reverse proxy mbele yake. Halafu jaribu ombi moja la kitendo bila kichwa cha authorization. Likifanikiwa, zuia /api, /v1 na /mcp kwenye proxy kwa anwani zinazotumiwa na mawakala wako hadi maombi yaliyothibitishwa pekee ndiyo yafanye kazi.

Je, Open Connector iko tayari kutumika katika mazingira ya uzalishaji?

Imepewa leseni ya Apache 2.0 na inaendelea kubadilika kwa kasi: hazina ilionekana tarehe 29 June 2026 na v1.3.3 ilitolewa tarehe 30 July 2026, kwa hiyo chukulia kila nambari ya toleo katika mwongozo huu kuwa picha ya hali ya tarehe 1 August 2026. Iendeshe ikiwa imefungwa kwenye lebo ya toleo, kamwe usiitumie kwenye latest au tip, soma maelezo ya toleo kabla ya kila uboreshaji, na uhifadhi nakala rudufu ya volume ambayo umeirejesha mara moja. Muundo huo ni thabiti kwa seva unayomiliki, na hatari iko kwenye mabadiliko ya matoleo, si kwenye usanifu.