სიახლეები და ანალიზი
რამდენიმე კომპანიის პორტალი: შესვლა მონაცემებზე წვდომას არ ადგენს
Auth0, Neon და GitLab იზოლაციის სამ ფენას აჩვენებს: ორგანიზაციის კონტექსტს, შენახვის საზღვრებსა და აპლიკაციის შიდა უფლებებს.
თანამშრომელი შევიდა, მაგრამ რომელი კომპანიის სახელით მოქმედებს? შეძლებს სხვა კომპანიის შეკვეთის პირდაპირი ბმულით გახსნას? B2B პროდუქტის ზრდასთან ერთად ეს კითხვები რთულ SSO გამართვამდე ჩნდება. Auth0-სა და GitLab-ის ახალი პუბლიკაციები Neon-ის სექტემბრის არქიტექტურულ სტატიასთან ერთად გადაწყვეტილების სამ ფენას განასხვავებს.
ორგანიზაციის კონტექსტი დაადგინეთ
9 ოქტომბერს Auth0-მ Organizations აღწერა ორგანიზაციის ფარგლებში წევრობით, იდენტობის მომწოდებლის კავშირებით, მეტამონაცემებითა და როლებით. მისი FlowGrid და Acme მაგალითები პირდაპირ გამოგონილად არის აღნიშნული. ისინი სცენარს ხსნის და არა კლიენტთან დანერგვას ან შედეგს.
საკუთარ პორტალში დაადგინეთ თითოეული ჩანაწერის მფლობელი ორგანიზაცია. ერთ ადამიანს რამდენიმე კომპანიაში სხვადასხვა უფლება შეიძლება ჰქონდეს. ამიტომ შერჩეული ორგანიზაცია მოქმედებას უნდა ახლდეს და მხოლოდ სათაურში სახელად არ დარჩეს. ერთი კომპანიის შეკვეთის წაკითხვის უფლება ყველა კომპანიის შეკვეთების რედაქტირების უფლებად არ უნდა იქცეს.
შენახვის გამოყოფა სხვა ფენაა
14 სექტემბრის LuBot-ის არქიტექტურის აღწერაში Neon თითო კლიენტზე ცალკე ბაზას აღწერს, საერთო ანგარიშებითა და ბილინგით Supabase-ში. ეს შედარების ადრინდელი კონტექსტია და არა ოქტომბრის განცხადება.
ცალკე ბაზებს შენახვის მკაფიო საზღვრის შექმნა შეუძლია, მაგრამ გამოსაყენებელ ბაზას კვლავ აპლიკაცია ირჩევს. მარშრუტიზაციის შეცდომა ან ადმინისტრატორის გადაჭარბებული წვდომა მხოლოდ საცავის გამოყოფით არ ქრება. გადაწყვეტილება მოვლის, აღდგენისა და კლიენტის ანგარიშის მართვის მოთხოვნებთან ერთად მიიღეთ.
კლიენტის პორტალში კომპანიების გამიჯვნის კონცეპტუალური AI ილუსტრაცია.
ავტენტიფიკაციის შემდეგ ავტორიზაცია შეამოწმეთ
5 ოქტომბერს GitLab-მა შიდა Django აპლიკაცია განიხილა, რომელიც ორ აუდიტორიას მოემსახურა. მხოლოდ login_required ცალკე მოდულების წვდომის შესაზღუდად საკმარისი არ იყო. მენიუს პუნქტის დამალვაც სერვერულ ავტორიზაციას არ ცვლის.
ერთად ეს სტატიები მიღების პრაქტიკულ პირობას გვთავაზობს: სისტემამ იცის მომხმარებელი, აქტიური ორგანიზაცია და კონკრეტული მოქმედების უფლება. ამ ფაქტებმა შერჩეული მონაცემები თანმიმდევრულად უნდა განსაზღვროს. იდენტობის მომწოდებელი, ბაზის დიზაინი და აპლიკაციის კოდი სხვადასხვა ფენაზე მუშაობს და ერთმანეთს ვერ ცვლის.
მიღებისთვის შექმენით ორი სატესტო კომპანია და მომხმარებელი თითოეულში განსხვავებული როლით. სცადეთ სხვა კომპანიის ჩანაწერის პირდაპირი URL, API მოთხოვნაში იდენტიფიკატორის შეცვლა, ორგანიზაციის კონტექსტის გადართვა და ადრე რიგში მოთავსებული სამუშაოს შესრულება. შემდეგ წვდომა მოხსენით და მოქმედებები გაიმეორეთ. მოსალოდნელი შედეგი, მათ შორის გასაგები უარი, წინასწარ შეათანხმეთ.
ბიზნესწესებისა და უფლებების გზამკვლევი შემოწმებების ჩარჩოს შექმნაში გვეხმარება. API-ის საარქივო დიზაინი წვდომის მოდელებს ეხება და არა ამ ახალი პროდუქტების გამოყენებას. კლიენტის პორტალის შექმნისას კიდევ ერთი ინტეგრაციის დამატებამდე განვიხილოთ ორგანიზაციები, როლები და მონაცემთა საზღვრები.