კონექტები (OAuth2 თითოეული მომხმარებლისთვის)
კავშირები ეს არის ის, როგორ აძლევს ერთი კერძო მომხმარებელი AiHummer-ს წვდომას მესამე მხარის სერვისზე თავის სახელით. საერთო სერვისის ანგარიშის ნაცვლად, თითოეული ადამიანი იყენებს სტანდარტულ ავტორიზაციის ნაკადი OAuth2 კოდით, მიღებული ტოკენი ინახება დაშიფრულ სართულში, ხოლო შესრულების დროს სისტემა ანიჭებს ამ მომხმარებლის ტოკენს, როდესაც ინსტრუმენტი ეს მოითხოვს.
ეს არის AiHummer-ის ანგარიშების მონაცემთა მოდელის „პირადი“ ნაწილი. საერთო სურათისთვის — თუ როდის მიანიჭოთ უპირატესობა ერთობლივ ანგარიშს და როგორ მუშაობს სარეზერვო სქემა — იხილეთ პირადი და საერთო სერთიფიკატები.
რას წარმოადგენს წყვეტა
კავშირი აერთიანებს სამ ნივთს: a მომწოდებელი (OAuth2 აპლიკაცია, რომლის ავტორიზაციასაც თქვენ ანიჭებთ), და მომხმარებელი (ადამიანი, რომელმაც აივსო თანხმობის ეკრანი), და ჩაწერა საცავში (სად ინახება გაცემული ტოკენი). მისი დაყენების შემდეგ, ნებისმიერი ინსტრუმენტი, რომელიც მოქმედებს ამ მომხმარებლის სახელით, შეიძლება გამჭვირვალედ გამოიყენოს ტოკენი, ისე რომ იგი არ გამოჩნდეს არც მოდელის კონტექსტში, არც ჟურნალებში, არც დასახმარებელ წინადადებაში.
კავშირები მართება ადმინისტრაციული ინტერფეისის vasitებით. სია აჩვენებს თითოეული მომხმარებლის დაკავშირებულ მიმწოდებლებს, მათ სტატუსს და ბოლო განახლების დროს.
ავტორიზაციის კოდის ნაკადი
შექმნილია კავშირი, რომელიც იყენებს კანონიკურ სამადგილ ბრაინ OAuth2 ავტორიზაციის კოდით:
- მომხმარებელი იწყებს კავშირის დამყარებას პროვაიდერთან ადმინისტრაციული ინტერფეისის საშუალებით — და
POST/GET /v1/admin/connections/oauth/startკითხვა. - AiHummer აჩქარებს ბრაუზერს მომწოდებლისკენ ავტორიზაცია საბოლოო წერტილი მოთხოვნილ სფეროებთან ერთად.
- მომხმარებელი იცნობს თანხმობის ეკრანს; მიმწოდებელი უკან გადამისამართებს
ერთჯერადი ავტორიზაციის კოდი კ
/v1/admin/connections/oauth/callback. - AiHummer-ის გამოძახების დამამუშავებელში ეს კოდი სერვერულ მხარეს იცვლება მისაწვდომობის ტოკენი (და, როცა ამას გამყიდველი მხარს უჭერს, a ტოკენის განახლება) ტოკენის მომწოდებლის ბოლოს წერტილზე.
- ტოკენი ინახება საცავში, ხოლო კავშირი მონიშნულია აქტიურად.
კოდის გაცვლა ტოკენზე ხდება სერვერის მხარეს კოლბექის ფარგლებში, ამიტომ მომხმარებლის საიდუმლო და გამოყოფილი ტოკენი არასოდეს ტოვებს კარიბჭეს.
[!NOTE] არ ავურიოთ ეს ნაკადი
POST /v1/oauth/token: ეს ეკუთვნის AiHummer საკუთარი OAuth2 client-credentials ეანდფოინტი — სერვისული ანგარიშები, დარეგისტრირებული საშუალებით/v1/admin/apikeys/register-clientგაცვალო ისინიclient_id/client_secretიქ დიდხანს არააah-ტოკინი. ამას მესამე მხარესთან არაფერი აქვს საერთო კავშირები.
[!NOTE] ავტორიზაციის კოდის ნაკადი ყოველთვის მოიცავს რეალური ბრაუზერის თანხმობის ნაბიჯს. კავშირი არ შეიძლება შექმნილიყო მხოლოდ API გასაღების გამოყენებით ხელმძღვანელის გარეშე — მოქმედი მომხმარებელი მინი-მხრილები უნდა დამტკიცდეს ერთხელ.
სად ცხოვრობს ტოკენი
მიცემული ტოკენი ინახება AiHummer-ში შიფრირებული მონაცემთა საცავი, არ არის ჩვეულებრივ კონფიგურაციაში. საცავი იყენებს კონვერტის შიფრირებას (AES-256-GCM მონაცემთა გასაღებით თითოეული მორიგისთვის მთავარი გასაღების ქვეშ), და საიდუმლოებები არასოდეს ირიცხება მოდელის კონტექსტში, მითითებებში ან ლოგებში. გაუქმებული ან ვადის ამოწურული კავშირი უბრალოდ არ ტოვებს უკან არცერთ გამოსადეგ საიდუმლოს.
oauth/start ─▶ consent ─▶ code ─▶ oauth/callback (exchange at the provider) ─▶ access/refresh token ─▶ vault (encrypted)მოქმედი მომხმარებლის მიერ გადაწყდა
შეკრების განსაზღვრული თვისება არის ის, რომ იგი გადაწყვეტილია მოქმედი მომხმარებლის მიერ. როცა აგენტი იყენებს ინსტრუმენტს, რომელსაც სჭირდება პროვაიდერი, გაუშვების დროს სისტემა ათვალიერებს კავშირს, რომელიც ეკუთვნის იმ მომხმარებელს, რომლის სახელითაც მიმდინარეობს ტური, და იყენებს მის ტოკენს. ორი თანამშრომელი, რომლებიც საუბრობენ იმავე აგენტთან ამიტომ ისინი მოქმედებენ საკუთარი ნებართვებით და ხედავენ მხოლოდ იმას, რასაც აძლევს მათი საკუთარი გრანტი.
ეს არის ის, რაც Connections-ს პირადი, თითოეული მომხმარებლისთვის განკუთვნილი ინტეგრაციებისთვის შესაფერისს ხდის: თითოეულის წვდომა იზოლირებულია, შესამოწმებელია და ინდივიდუალურად შესაძლებელია გაუქმება.
მისაწვდომი ინტეგრაციები
OAuth2 ნაკადის დახმარებით, მომხმარებელი შეუძლია თავისი ანგარიში დაუკავშიროს ნებისმიერ მიწოდების სერვისს. ეს პერსონალური ინტეგრაციები ხელმისაწვდომია მაშინვე:
| ჯგუფი | სერვისები |
|---|---|
| გუგლი | Gmail, Google კალენდარი, Google კონტაქტები, Google დავალებები, Google დისკი, YouTube |
| მაიქროსოფთ | Outlook-ის ფოსტა, Outlook-ის კალენდარი, OneDrive, Microsoft To Do |
| პროდუქტიულობა | Todoist, Asana, Jira Cloud, ClickUp, GitLab, Linear, monday.com |
| ჯანმრთელობა და ცხოვრების stil | ფიტბიტი, ოურა რგოლი, სტრავა, სპოტიფაი, სამსუნგ სმარტთინგსი |
თითოეული ერთდება იგივე ავტორიზაციის კოდის პროდუცირების სტრიქტით: მომხმარებელი ასრულებს მიმწოდებლის თანხმობის ეკრანს, ტოკენი იბეჭდება სპეციალურ შესვენებაში და ის გაშვებული ხდება იმ მომხმარებლისთვის, როდესაც ინსტრუმენტი მიუახლოვდება სერვისს.
კავშირების მართვა ადმინისტრაციულ ინტერფეისში
ადმინისტრატორის ინტერფეისიდან ოპერატორს შეუძლია:
- იხილეთ, რომელი პროვაიდერები არიან დაკავშირებული თითოეულ მომხმარებელთან და თითოეული ტოკენის მდგომარეობა.
- დაიწყეთ ახალი კავშირის შექმნა (აიწყოს პროცესის შეთანხმების მიღება არჩეული მიმწოდებლისთვის).
- შეწყვიტოს კავშირი, რომელიც ანაზღაურებს საცავის ჩანაწერს და გამორთავს ნებართვას.
კავშირები ან პირადი (მიკუთვნებული კონკრეტულ მომხმარებელს, რომელიც მათ გამორთვას შეძლებს) ან სამუშაო სფეროს საერთო გამოყენება (ნიშნულია როგორც „საერთო სამუშაო სივრცე“; მათ პირადად ვერ გამორთავ). ერთი მიმწოდებელი შეუძლია შეინახოს რამდენიმე ანგარიში: ღილაკი „+ ანგარიში“ მოითხოვს ლეიბელს და შეინახავს კიდევ ერთ ანგარიშს იმავე მიმწოდებლისგან — მაგალითად, რამდენიმე Google კალენდარი ან მეილბოქსი.
მდინარე სერთიფიკატების პირადობის გამო, კავშირი ყველაზე ხშირად სწორ ინსტრუმენტად ითვლება, როცა მოქმედება უნდა მიენიჭოს და შემოიფარგლოს კონკრეტული ადამიანის ავტორიზაციით, არამედ არა სამუშაო სივრცის მასშტაბური ანგარიშით.
სად შემდეგ?
- პირადი და საერთო სერთიფიკატები — სრული ფართობის მოდელი და როდის აირჩიოთ თითოეული.
- LLM BYOK მიმწოდებლები — მიიღეთ თქვენი მოდელის გასაღებები ქირავნილის პასუხისმგებლობა.
- სავაჭრო პლატფორმის მიმოხილვა და დონეები — სად ინტეგრაციები, რომლებიც მხარს უჭერენ OAuth-ს, შესაფერისია.