RE:NODE

როგორ მივცეთ AI-ს სერვერზე წვდომა საიდუმლოების გაჟონვის გარეშე

ავტორი RE:NODE-ის გუნდი
15 წუთის საკითხავი


AI ასისტენტს სერვერზე სასარგებლო წვდომა შეგიძლია მისცე პაროლების გადაცემის გარეშე, მაგრამ მხოლოდ იმ შემთხვევაში, თუ წვდომა სწორედ ამისთვისაა აგებული. root SSH გასაღები ან panel-ის სრული API key, ჩატში ჩასმული, ასისტენტს აძლევს ყველაფერს - და ჩატის ისტორიასაც, და ყველას, ვინც ამ ისტორიას წაიკითხავს. სამაგიეროდ მუშაობს ვიწრო წვდომა: ბმული ან კავშირი, რომელიც სერვერის აგებულებას ხედავს, მაგრამ მის საიდუმლოებებს - არა; რომელსაც მხოლოდ შენ არჩეული მოქმედებები შეუძლია; რომელიც თავისით მთავრდება, როცა ხმარებას წყვეტ; რომლის გაუქმებაც ერთი დაწკაპუნებით შეგიძლია; და რომელიც ტოვებს ჩანაწერს იმის შესახებ, რა გააკეთა. იმ ერთი სამუშაოსთვის, რომელსაც მართლაც სჭირდება საიდუმლო - პაროლის .env ფაილში ჩაწერა - სწორი ინსტრუმენტი მნიშვნელობას წერს და ფაილს უკან არასდროს კითხულობს. ეს არის მთელი სქემა, ხოლო ამ პოსტის დანარჩენი ნაწილი თითოეული ელემენტის დეტალებია და იმის ახსნა, სად თავდება მათი შესაძლებლობები.

AI ფუნქციები ჩვენს panel-ში სწორედ ამ წესებზე ავაგეთ, ამიტომ როცა პოსტი აღწერს, როგორ აკეთებს რაღაცას RE:NODE, ეს იმიტომაა, რომ ის ნაბიჯი პრინციპის კონკრეტული მაგალითია. თავად პრინციპები ნებისმიერ ჰოსტზე მუშაობს.

რა სჭირდება ასისტენტს სერვერიდან#

ასისტენტისთვის სასარგებლოდ მუშაობისთვის საჭირო ინფორმაციის უმეტესობა საიდუმლო არ არის. გაჭედილი Node აპლიკაციის გასასწორებლად სჭირდება runtime და მისი ვერსია, გაშვების ბრძანება, პორტი, რომელზეც სერვერი უნდა გაიხსნას, კონსოლის ბოლო რამდენიმე ასეული ხაზი და დირექტორიების ხე. ბაზასთან დასაკავშირებლად სჭირდება host, პორტი, ბაზის სახელი და იმ გარემოს ცვლადის სახელი, რომელსაც შენი კოდი კითხულობს. დომენის დასამატებლად სჭირდება მისამართი, რომელზეც A ჩანაწერი უნდა მიუთითებდეს.

არცერთ მათგანს პაროლი არ სჭირდება. პაროლი საჭიროა ზუსტად ერთხელ, იმ მომენტში, როცა კონფიგურაციის ფაილში ჩაიწერება, და ამის შემდეგ მისი ხელახლა წაკითხვა არავის სჭირდება - არც ადამიანს, არც მოდელს. ამ განსხვავებაზე დგას პოსტის დანარჩენი ნაწილი:

  • Context არის ის, რაც სერვერია: runtime, პორტები, ფაილების სტრუქტურა, ლოგები, ცვლადების სახელები. მისი ჩვენება უსაფრთხოა და სწორედ ის აქცევს ასისტენტს სასარგებლოდ.
  • საიდუმლოებები არის მნიშვნელობები, რომლებიც წვდომას იძლევა: ბაზის პაროლები, API token-ები, OAuth client secret-ები, ხელმოწერის გასაღებები, SMTP მონაცემები. წასაკითხად არასდროს არის საჭირო, ჩასაწერად - ერთხელ.
  • უფლებამოსილება არის ის, რისი შეცვლაც ასისტენტს შეუძლია: ფაილები, კონსოლი, გაშვება და გაჩერება. სასარგებლოა, მაგრამ სწორედ ეს ნაწილი უნდა იყოს ნებაყოფლობითი და ხანმოკლე.

თუ ინსტრუმენტს ამ სამის ერთმანეთისგან გარჩევა არ შეუძლია, ასისტენტს ან ყველაფერს უნდა მისცეს, ან არაფერს. ამიტომაა "უბრალოდ SSH მიეცი" არასწორი პასუხი, მაშინაც კი, როცა მოდელს სრულად ენდობი. უფრო ფართო არგუმენტი - რომ აგენტი წერს, ადამიანი კი ამოწმებს - განვიხილეთ პოსტში AI coding agents სერვერის სამუშაოებისთვის.

სად გაჟონავს საიდუმლოებები სინამდვილეში#

ღირს კონკრეტულად დავასახელოთ გზა, რომლითაც საიდუმლო ასისტენტის გავლით გაჟონავს, რადგან ამ გზების უმეტესობას მოდელის არასწორ ქცევასთან კავშირი არ აქვს.

  1. ტრანსკრიპტი. ყველაფერი, რასაც ასისტენტი კითხულობს, საუბრის ნაწილი ხდება. საუბრებს ინახავს პროვაიდერი, სინქრონდება სხვა მოწყობილობებზე, ბმულებით ეგზავნება კოლეგებს, ეკოპირება ticket-ებში და სკრინშოტებად ხვდება დახმარების ფორუმებზე. ბაზის პაროლი, რომელიც ერთხელ გამოჩნდა ინსტრუმენტის პასუხში, ახლა ამ ყველა ადგილას დევს.
  2. context ფაილები. Claude Code-ისა და Cursor-ის მსგავსი აგენტები repository-ში წერენ ჩანაწერებს და შეჯამებებს - CLAUDE.md, AGENTS.md, დაგეგმვის ფაილები. თუ საიდუმლო context-ში იყო, ის შეიძლება commit-ულ ფაილში აღმოჩნდეს და იქიდან - ყველა clone-ში.
  3. წრიული გზა. ასისტენტი, რომელსაც .env-ში ერთი ხაზის შეცვლა სთხოვეს, ხშირად კითხულობს ფაილს, მეხსიერებაში ცვლის და მთლიანს უკან წერს. თუ წაკითხვისას მნიშვნელობები დაფარული იყო, უკან ჩაწერა ყველა რეალურ მნიშვნელობას placeholder-ით ანაცვლებს და აპლიკაცია გაფუჭდება. თუ წაკითხვისას არაფერი იყო დაფარული, ყველა მნიშვნელობა ტრანსკრიპტში გავიდა.
  4. გრძელვადიანი credential. გასაღები, რომელიც მარტში ჩატში ჩაიკოპირეს, ოქტომბერშიც მუშაობს, თუ ვინმეს არ გაახსენდა მისი ცვლა. არავის ახსენდება.

ის, რომ მოდელი შენს პაროლს განზრახ გაიტანს, ამ ყველაფრიდან ყველაზე ნაკლებად სავარაუდოა. საიდუმლოებები უბრალო, მოსაწყენი გზებით გადის - ლოგებით, ისტორიით, ფაილებით. გარემოს ცვლადებისა და საიდუმლოებების შესახებ ჩვენი პოსტი ზოგად ჰიგიენას ეხება; ქვემოთ კი საუბარია ამ ოთხი გზის დახურვაზე იმ შემთხვევაში, როცა მკითხველი AI-ა.

რას მალავს panel#

RE:NODE-ზე ყველაფერი, რასაც ასისტენტი share link-ით ან ჩვენი MCP endpoint-ით იღებს, ჯერ redactor-ში გადის. ის სამი ფენით მუშაობს, რადგან თითოეული ცალკე რაღაცას ტოვებს, რასაც დანარჩენები იჭერენ.

ფენარას იჭერს
ცვლადის სახელითყველაფერს, რასაც TOKEN, PASSWORD, KEY, SECRET, AUTH, SALT ჰგავს
ფორმითGitHub, Slack, OpenAI და AWS გასაღებებს, JWT-ებს, URL-ში ჩაწერილ პაროლებს, გრძელ შემთხვევით სტრიქონებს
მნიშვნელობითსერვერის რეალურ საიდუმლოებებსა და ბაზის პაროლებს, მზა გამოტანიდან ამოგლეჯილს

სახელის ფენა აშკარა შემთხვევას ფარავს: გაშვების ცვლადში DB_PASSWORD=... სახელს აჩვენებს, მნიშვნელობა კი დაფარულია. ფორმის ფენა იჭერს token-ს, რომელიც მოულოდნელ ადგილას გამოჩნდა - stack trace, რომელმაც user:password@host შემცველი connection string დაბეჭდა, ან GitHub token, რომელიც დაუდევარმა install სკრიპტმა კონსოლში გამოაჩინა. მნიშვნელობის ფენა სარეზერვოა: panel-მა იცის, რომელია ამ სერვერის რეალური საიდუმლოებები, ამიტომ მზა გამოტანაში სწორედ ამ სტრიქონებს ეძებს და ყველგან შლის, სახელის მიუხედავად.

განსაკუთრებით ბაზის პაროლები გამოტანაში არასდროს ჩანს. ასისტენტი იღებს host-ს, პორტს, ბაზის სახელსა და მომხმარებელს, რაც საკმარისია დასაკავშირებელი კოდის დასაწერად და იმ ცვლადის სახელის გასაგებად, საიდან უნდა წაიკითხოს; პაროლს კი ან თავად ათავსებ, ან ქვემოთ აღწერილი write-only ინსტრუმენტით.

ამას პირდაპირ ვამბობთ, რადგან კოდიც თავის თავზე ამას ამბობს. სამი ფენა გაჟონვას ბევრად ნაკლებსავარაუდოს ხდის, მაგრამ შეუძლებელს არა, და ვინც სხვა რამეს გეუბნება, ის რეალურ კონსოლის გამოტანაზე არ გამოუცდია.

წაკითხვის წვდომას განზრახ დატოვებული ხარვეზიც აქვს: ნაგულისხმევი share link აჩვენებს დირექტორიების სიას, მაგრამ არა ფაილების შიგთავსს. ასისტენტს შეუძლია დაინახოს, რომ config/database.php არსებობს; წაკითხვა კი არ შეუძლია, სანამ ბმულს არ მისცემ, რომელსაც მოქმედება შეუძლია, და მაშინაც წაკითხული იმავე redactor-ში გადის.

საიდუმლოს ჩაწერა მისი წაკითხვის გარეშე: set_env#

ადრე აღწერილ წრიულ პრობლემას სუფთა გამოსავალი აქვს: შერწყმა სერვერის მხარეს გააკეთე და ფაილი ასისტენტს საერთოდ არ გაუგზავნო. ჩვენი MCP ინსტრუმენტები სწორედ ამისთვის შეიცავს set_env-ს. ის იღებს .env-ის გზას, დასაყენებელი გასაღებების ნაკრებს და წასაშლელი გასაღებების სიას. panel თავად კითხულობს ფაილს, დასახელებულ ხაზებს ცვლის ან ამატებს, დანარჩენ ყველა ბაიტს ადგილზე ტოვებს, ფაილს უკან წერს და აბრუნებს მხოლოდ იმ გასაღებების სახელებს, რომლებსაც შეეხო.

ასისტენტის გამოძახება ასე გამოიყურება:

set_env arguments
{  "server": "1a2b3c4d",  "path": "/.env",  "set": {    "DATABASE_URL": "postgres://app:the-real-password@db-host:5432/app",    "SESSION_SECRET": "a-long-random-string"  },  "unset": ["OLD_API_KEY"]}

პასუხად კი ბრუნდება მხოლოდ ეს:

code
/.env - updated: DATABASE_URL; added: SESSION_SECRET; removed: OLD_API_KEY.Values are not echoed. Restart the server for the app to read them.

დეტალები, რომლებიც მას მხოლოდ მოხერხებულს კი არა, უსაფრთხოსაც ხდის:

  • ის თავისი აგებულებით write-only-ა. არ არსებობს რეჟიმი, რომელშიც მნიშვნელობას დააბრუნებს, ამიტომ არაფერია არასწორად გასაწყობი.
  • ის მხოლოდ `.env` ან `.env.something` ფაილებს ცვლის. დანარჩენი ყველაფერი ჩვეულებრივი ფაილური ინსტრუმენტებით კეთდება.
  • დანარჩენი ხაზები ხელუხლებელი რჩება. კომენტარები, თანმიმდევრობა, ცარიელი ხაზები და ხაზის დასასრულები ისე რჩება, როგორც იყო. გასაღები, რომელიც ორჯერ გვხვდება, ყველა ადგილას იცვლება, რადგან რომელსაც შენი loader მიიღებს, იმას ახალი მნიშვნელობა უნდა ჰქონდეს.
  • მნიშვნელობები ერთხაზიანია. ახალი ხაზის შემცველი მნიშვნელობა უარყოფილია, ფაილის ჩუმად გაყოფის ნაცვლად.
  • ის მხოლოდ იმ ბმულებზე არსებობს, რომლებსაც მოქმედება შეუძლიათ. წაკითხვის ბმულს ვერაფრის ჩაწერა ვერ შეუძლია, .env-ისაც.

ერთი პატიოსანი შენიშვნაა. თუ პაროლს ჩატში თავად აკრეფ, რომ ასისტენტმა set_env-ს გადასცეს, პაროლი ტრანსკრიპტშია, რადგან შენ ჩასვი იქ. set_env ხელს უშლის ფაილის დანარჩენი საიდუმლოებების გაჟონვას და უკან ჩაწერისას მათ განადგურებას; იმას კი ვერ გააუქმებს, რაც შენ აკრიფე. მაღალი ღირებულების credential-ისთვის უფრო სუფთა მიდგომაა, რომ ასისტენტმა ყველა არასაიდუმლო გასაღები დააყენოს, ერთადერთი პაროლი კი შენ თავად დაამატო file manager-ში, ან მნიშვნელობა სერვერზე დაგენერირდეს და არავის უჩვენო.

.env
# Set by the assistant through set_env - safe to discussNODE_ENV=productionPORT=25601DATABASE_HOST=db-hostDATABASE_NAME=app# Added by hand in the file manager - never in a chatDATABASE_PASSWORD=

ზემოთ მოცემული პორტი და host placeholder-ებია; გამოიყენე ის მნიშვნელობები, რომლებსაც panel შენს სერვერზე აჩვენებს.

Scope-ები: რას შეუძლია და რას არა ბმულს#

წვდომა უნდა იყოს ყველაზე მცირე, რაც საქმეს აკეთებს. RE:NODE-ზე share link ორი სახისაა, მათ აკეთებ კონსოლის ზემოთ ზოლში არსებული Connect AI ღილაკიდან, და სახეობა იმაზეა დამოკიდებული, რისთვისაც ასისტენტი გინდა.

ბმულირას შეუძლიანაგულისხმევი
Readსერვერის context, ამოცანის prompt-ები, კონსოლის ბოლო ხაზები, დირექტორიების სიადიახ
Can actყველაფერი ზემოთ აღნიშნული, ასევე გაშვება, გაჩერება, restart, kill, კონსოლში ბრძანების შეყვანა და ფაილების რედაქტირებამხოლოდ "Manage this server"-ისთვის

General, Set up a new project, Fix my repository, Connect a database ან Add a domain არჩევა read ბმულს ქმნის. მხოლოდ "Manage this server" ქმნის ისეთს, რომელსაც მოქმედება შეუძლია. "Server won't start" ბმულს საერთოდ არ ქმნის: ის აკოპირებს მზა prompt-ს კონსოლის ბოლო ხაზებით, რაც ხშირად საკმარისია ასისტენტისთვის გაჭედვის დიაგნოსტიკისთვის.

ზოგი რამ არცერთი ბმულით არ არის ხელმისაწვდომი, ბმულის სახეობის მიუხედავად:

  • სერვერის წაშლა, გადარქმევა ან ხელახლა ინსტალაცია
  • გაშვების ბრძანებისა და ცვლადების შეცვლა
  • ბაზები და მათი პაროლები
  • backup-ები და განრიგები
  • მომხმარებლები და subuser-ები
  • SFTP მონაცემები და API key-ები

ბმულით ჩაწერა მხოლოდ ტექსტია, ფაილზე არაუმეტეს 1 MB-ისა და არასდროს .git/-ის შიგნით. თითოეული ბმული შეზღუდულია წუთში 60 მოთხოვნით, 20 მოქმედებით და 6 power მოქმედებით, რაც ხელგაშლილია ასისტენტისთვის, რომელიც რეალურ საქმეს აკეთებს, და მკაცრი მუხრუჭია იმისთვის, რომელიც ციკლში გაჩერდა და შენს სერვერს უსასრულოდ რესტარტავს.

თუ ბმულის ჩასმის ნაცვლად ასისტენტის შენს ანგარიშზე მიერთება გირჩევნია, panel-ს აქვს hosted MCP endpoint OAuth 2.1 შესვლით. URL-ს ამატებ და თანხმობის გვერდზე ერთხელ ადასტურებ:

bash
$ claude mcp add --transport http renode https://panel.renode.space/api/client/mcp

თანხმობის გვერდზე ირჩევ, რომელი სერვერები (შენი ყველა ან რამდენიმე) და რომელი დონე: Files (ფაილების წაკითხვა და რედაქტირება, კონსოლი) ან Manage (ის, ასევე გაშვება, გაჩერება და restart). ბაზები, backup-ები, განრიგები, მომხმარებლები, startup და პარამეტრები არასდროს არის შემოთავაზებული. წვდომის token-ები ერთ საათს გრძელდება; refresh token-ები - 30 დღეს და გამოყენებასთან ერთად გადაინაცვლებს. განმეორებით გამოყენებული refresh token მთელ გრანტს აუქმებს, ამიტომ მოპარული token, რომელსაც ის შემდეგ იყენებს, როცა რეალურმა კლიენტმა უკვე გამოიყენა, თავისით კვდება. ეს ავაგეთ და გამოვცადეთ Claude Code-თან და Claude.ai-ის custom connector-ებთან; სხვა კლიენტები, რომლებსაც remote MCP ესმით, უნდა მუშაობდეს, მაგრამ ცალკე არ გვიცდია.

უმცირესი პრივილეგიის იგივე აზროვნება ადამიანებზეც ვრცელდება, და panel-ის მოდელი ამისთვის აღწერილია პოსტში subuser-ები და უმცირესი პრივილეგია.

ვადა და როტაცია#

წვდომის token-ების ჩვეულებრივი პრობლემა ის არ არის, რომ პირველ დღეს იპარავენ. პრობლემა ისაა, რომ ორასე დღეზეც ძალაშია. ამიტომ share link-ები ვადას არ გეკითხება და წაშლას არ საჭიროებს. ისინი თავისით იწურება:

ბმულიუმოქმედობის ვადამკაცრი ზღვარი
Readბოლო გამოყენებიდან 7 დღეშექმნიდან 90 დღე
Can actბოლო გამოყენებიდან 24 საათიშექმნიდან 30 დღე

ყოველი გამოყენება უმოქმედობის ვადას წინ სწევს, ამიტომ ბმული, რომელსაც ასისტენტი აქტიურად იყენებს, მუშაობას აგრძელებს, ის კი, რომელიც დაგავიწყდა, კვდება კვირაში, ან დღე-ღამეში, თუ რაღაცის შეცვლა შეეძლო. მკაცრი ზღვარი ნიშნავს, რომ მუდმივად გამოყენებული ბმულიც მთავრდება.

როტაცია იმავე პრინციპით მუშაობს. იმავე სერვერისა და იმავე მიზნისთვის ახალი ბმულის შექმნა წინას ანაცვლებს; ძველის პოვნა და წაშლა წინასწარ არ გჭირდება. სერვერს შეიძლება ჰქონდეს მაქსიმუმ ხუთი აქტიური ბმული, რომელთაგან ორს შეუძლია მოქმედება, და ამ რაოდენობის გადაჭარბებისას ყველაზე ძველი გამოდის ხმარებიდან.

URL თავად ერთხელ ჩანს. panel ინახავს მხოლოდ მის hash-ს, ამიტომ ბაზის ასლი მომუშავე ბმულს არ შეიცავს. თუ დაკარგე, შექმენი ახალი - ძველი იმავე ნაბიჯში უქმდება.

კიდევ ორი წესი ხურავს იმ ხარვეზებს, რომლებსაც ადამიანები ხშირად მოგვიანებით პოულობენ:

  • ბმული იმდენად კარგია, რამდენადაც მისი შემქმნელის წვდომაა. თუ subuser იყავი და შენი წვდომა მოიხსნა, შენ მიერ შექმნილი ყველა ბმული მაშინვე წყვეტს მუშაობას, ყოველი მოთხოვნისას.
  • ყოველი უარი უბრალო 404-ია. ვადაგასული, გაუქმებული, შემქმნელმა წვდომა დაკარგა, სერვერი შეჩერებულია - პასუხი იგივეა. ვინც ბმულს სინჯავს, არაფერს იგებს იმის შესახებ, რატომ არ მუშაობს ან მუშაობდა თუ არა ოდესმე.
else 404action loggedoutputsecrets withheldასისტენტიClaude, ChatGPTShare linkhash მოწმდებაშემქმნელის წვდომამოწმდება ყოველ ჯერზეScope და ლიმიტებიread ან actშენი სერვერიRedactorსახელი, ფორმა, მნიშვნ.
ყველა მოთხოვნა ერთსა და იმავე შემოწმებას გადის

წვდომის გაუქმება#

ვადა იმ ბმულებს უმკლავდება, რომლებიც დაგავიწყდა. გაუქმება კი იმისთვისაა, რაც ახლავე უნდა გაქრეს - ბმული არასწორ ჩატში ჩასვი, კოლეგას ლეპტოპი მოსპარეს, ან უბრალოდ დაამთავრე.

ყველაფერი ერთ ადგილასაა: Account, შემდეგ Connected AI. იქ ჩანს ყველა OAuth კავშირი Disconnect ღილაკით და შენი ანგარიშის მიერ შექმნილი ყველა აქტიური share link, ნებისმიერ სერვერზე, Revoke ღილაკით. თითოეული ბმული აჩვენებს, რამდენი მოქმედება შეასრულა და როდის გამოიყენეს ბოლოს, რაც ყველაზე სწრაფი გზაა იმის დასანახად, რომ ბმულს ისევ იყენებენ მაშინ, როცა მისით დასრულებული გეგონა.

გაუქმებული ბმული შემდეგ მოთხოვნაზე 404-ს პასუხობს. გათიშული OAuth კავშირი წვდომას ანალოგიურად კარგავს. არცერთს პაროლის შეცვლა არ სჭირდება, თუმცა თუ ასისტენტს მოქმედება შეეძლო და არ იცი, რა გააკეთა, წაიკითხე შემდეგი ნაწილი, სანამ გადაწყვეტ, რომ ამით საქმე დასრულდა.

იმის audit, რა გააკეთა ასისტენტმა#

ნებისმიერი ინციდენტის შემდეგ კითხვაა "რა შეიცვალა?", და პასუხი ისეთი ჩანაწერიდან უნდა მოდიოდეს, რომელიც ასისტენტს არ დაუწერია. RE:NODE-ზე ბმულით ან OAuth კავშირით შესრულებული ყოველი მოქმედება წერს იმავე activity event-ს, რასაც panel-ში შესაბამისი ღილაკი. ასისტენტით შეცვლილი ფაილი არის server:file.write ხაზი; restart - power event; set_env გამოძახება - ფაილის ჩაწერაა, რომელიც აფიქსირებს ფაილსა და გასაღებების სახელებს, მნიშვნელობებს არასდროს.

ეს ხაზები იწერება იმ ანგარიშის სახელით, რომელმაც ბმული შექმნა ან კავშირი დაადასტურა, რადგან ასისტენტმა სწორედ მისი უფლებამოსილება გამოიყენა. კულისებში თითოეული ხაზი იმასაც აფიქსირებს, რომელი კარით შემოვიდა - share link, OAuth grant თუ API key - რათა support-მა ისინი ერთმანეთისგან გაარჩიოს. ბმულების შექმნა და გაუქმებაც event-ებია: server:ai.link.create და server:ai.link.revoke. OAuth კლიენტის მიერთება და გათიშვა ანგარიშის სახელით ილოგება.

პრაქტიკაში ასე გამოიყენე:

  1. სანამ ბმულს გადასცემ, რომელსაც მოქმედება შეუძლია, Backups tab-იდან backup აიღე. activity ჟურნალი გეუბნება, რა შეიცვალა; backup კი საშუალებას გაძლევს, უკან დააბრუნო.
  2. მუშაობისას კონსოლი ღია გქონდეს, რომ restart-ები და შეცდომები დაინახო, როცა ხდება.
  3. შემდეგ Connected AI გვერდზე მოქმედებების რაოდენობა შეადარე იმას, რასაც ელოდი. ბმული, რომელსაც სამი ცვლილება უნდა გაეკეთებინა და ორმოცი მოქმედება აქვს, ლოგის წაკითხვად ღირს.
  4. თუ რამე არასწორია, ჯერ გააუქმე, მერე წაიკითხე activity ჟურნალი იმ პერიოდისთვის, როცა ბმული ძალაში იყო, და მხოლოდ შემდეგ აღადგინე ან გაასწორე.

ჟურნალი არაფერს აჩერებს; ის გეუბნება, რა გასაკეთებელია. ამიტომაა ის scope-ების, ლიმიტებისა და ვადის გვერდით და არა მათ ნაცვლად.

ჩამონათვალი ბმულის ჩასმამდე#

მთელი პოსტი სიის სახით, რომელიც ერთ წუთში გადაიარე:

  1. სჭირდება თუ არა ასისტენტს რაიმეს შეცვლა? თუ არა, გამოიყენე read ბმული. დიაგნოსტიკის უმეტესობას უფლებამოსილება არ სჭირდება.
  2. თუ მოქმედება სჭირდება, ჯერ backup აიღე.
  3. პაროლები ჩატს მოარიდე. ასისტენტმა set_env-ით არასაიდუმლო გასაღებები დააყენოს, საიდუმლო კი შენ თავად დაამატე.
  4. SFTP პაროლი, panel-ის API key ან ბაზის პაროლი საუბარში არასდროს ჩასვა. თუ ჩასვი, შეცვალე.
  5. ბმული ჩასვი მხოლოდ იმ საუბარში, რომელსაც სჭირდება. გაზიარებული საუბარი ბმულსაც აზიარებს.
  6. როცა ამოცანა დასრულდა, ბმული გააუქმე Connected AI გვერდზე.
  7. გადახედე activity ჟურნალს და მოქმედებების რაოდენობას. თუ ორიდან რომელიმე გაგაკვირვებს, გააგრძელებამდე გამოიკვლიე.

თუ GitHub-იდან აკეთებ deploy-ს, საიდუმლოებები კიდევ ერთ ადგილას იმალება: repository-ში. commit-ული .env GitHub tab-ზე pre-flight შემოწმებით სახელით მოგეხსენიება, panel-ის მიერ მისი გახსნის გარეშე. ჩვენი გზამკვლევი Node აპლიკაციის GitHub-იდან deploy-ის შესახებ აღწერს, როგორ უნდა მიაღწიოს გარემოს მნიშვნელობებმა სერვერამდე ამის ნაცვლად.

FAQ#

შეუძლია თუ არა AI-ს ჩემი ბაზის პაროლის დანახვა?

panel-ის ბმულებითა და MCP endpoint-ით - არა. ბაზის პაროლები ყველა გამოტანიდან დაფარულია და არცერთ ბმულს ბაზის პარამეტრების გახსნა არ შეუძლია. ასისტენტი იღებს host-ს, პორტს, ბაზის სახელსა და მომხმარებელს, რაც კოდის დასაწერად საკმარისია. თუ პაროლს თავად ჩაწერ ჩატში, ის ტრანსკრიპტშია, ისევე როგორც ყველაფერი, რასაც აკრეფ.

საკმარისია თუ არა redaction იმისთვის, რომ ნებისმიერი სერვერის გაზიარება უსაფრთხო იყოს?

არა. ის გაჟონვას ბევრად ნაკლებსავარაუდოს ხდის, მაგრამ მოულოდნელი ფორმატის საიდუმლო შეიძლება გაიპაროს. შეუთავსე ის read-only ბმულს, სადაც შეგიძლია, დასრულებისას გააუქმე ბმულები და ნებისმიერი credential, რომელსაც ტრანსკრიპტში შეამჩნევ, შეცვალე.

share link URL-ია, ამიტომ მუშაობს ნებისმიერი ასისტენტი, რომელსაც მისი გახსნა შეუძლია - Claude და ChatGPT ჩათვლით. hosted MCP endpoint და OAuth შესვლა აგებულია და გამოცდილია Claude Code-თან და Claude.ai custom connector-ებთან. Cursor სერვერის წესებს იღებს context ფაილებიდან, რომელთა დამატებაც GitHub ინტეგრაციას შენს repository-ში შეუძლია.

რა მოხდება, თუ ჩემი ბმული სხვას ჩაუვარდა ხელში?

მას იგივე ხელმისაწვდომი იქნება, რასაც ბმული უშვებს, rate limit-ების ფარგლებში, სანამ ვადა არ გაუვა ან შენ არ გააუქმებ. read ბმული აჩვენებს context-სა და ლოგებს დაფარული საიდუმლოებებით; ბმულს, რომელსაც მოქმედება შეუძლია, ფაილების რედაქტირებაც და სერვერის restart-იც შეუძლია, ამიტომ ისინი უმოქმედობიდან 24 საათში კვდება. გააუქმე Connected AI გვერდზე და შემდეგივე მოთხოვნიდან 404-ს უპასუხებს.

შეუძლია თუ არა ბმულს ჩემი სერვერის წაშლა ან backup-ებთან შეხება?

არა. წაშლა, ხელახლა ინსტალაცია, გადარქმევა, backup-ები, განრიგები, მომხმარებლები, startup პარამეტრები და ბაზები ყველა ბმულისა და ყველა OAuth დონის გარეთაა, ამიტომ ამისთვის ყოველთვის შენ გჭირდები panel-ში.

უნდა წავშალო თუ არა ძველი ბმულები?

არა. read ბმულები იწურება ბოლო გამოყენებიდან 7 დღეში, ხოლო ბმულები, რომლებსაც მოქმედება შეუძლიათ - 24 საათში, მკაცრი ზღვრებით 90 და 30 დღე. იმავე მიზნისთვის ახალი ბმულის შექმნა ძველს ანაცვლებს. გაუქმება მაინც სწორი ჩვევაა, როცა ამოცანას ამთავრებ.

გამოგადგათ?