Opanowanie RBAC w Logto: Kompleksowy przykład z życia codziennego

Wstęp#

Kontrola dostępu i bezpieczeństwo to iezbędne aspekty owoczesnych aplikacji, które zapewniają, że użytkownicy mają odpowiedni dostęp do zasobów. Kontrola dostępu oparta a rolach (RBAC) Logto oferuje programistom efektywny sposób zarządzania kontrolą dostępu i bezpieczeństwem w ich aplikacjach. W tym artykule przyjrzymy się mocnym stronom implementacji RBAC Logto, używając rzeczywistego przykładu, który pomoże Ci zrozumieć i zastosować te koncepcje w swoich projektach.

Analizując fragmenty kodu zarówno frontendowego, jak i backendowego, uzyskasz pełną perspektywę a integrację RBAC Logto z Twoim stosie aplikacji. Do końca tego artykułu będziesz dobrze przygotowany do wykorzystania funkcji RBAC Logto, aby zwiększyć bezpieczeństwo i kontrolę dostępu w Twoim projekcie.

Przedstawiamy BookHarber: Użycie sklepu internetowego z książkami jako przykładu#

Aby skutecznie zademonstrować funkcje RBAC Logto, użyjemy rzeczywistego przykładu: BookHarber, sklep internetowy z książkami. BookHarber oferuje szeroki zakres funkcji dla klientów i personelu, zapewniając bezproblemowe i bezpieczne doświadczenie zakupów.

Kluczowe funkcje oferowane przez BookHarber obejmują:

1. Przeglądanie i zakup książek: Użytkownicy mogą łatwo wyszukiwać i kupować książki z różnorodnej kolekcji, obejmującej różne gatunki i autorów.
2. Zarządzanie zamówieniami i śledzenie logistyki: Zarejestrowani klienci mogą zarządzać swoimi zamówieniami, śledzić przesyłki i otrzymywać aktualizacje a temat swoich zakupów.
3. Specjalne oferty i aktywności świąteczne: BookHarber oferuje ekskluzywne zniżki i promocje podczas specjalnych wydarzeń i świąt, aby angażować i agradzać swoją bazę klientów.
4. Wsparcie dla klienta: Klienci mogą otwierać zgłoszenia wsparcia w celu rozwiązania wszelkich problemów lub kwestii, które mogą apotkać, otrzymując szybką pomoc od personelu BookHarber.
5. Zarządzanie klientami: Pracownicy o różnych rolach mają możliwość zarządzania różnymi aspektami platformy, takimi jak konta klientów, przetwarzanie zamówień i rozwiązywanie problemów.

Role#

W ekosystemie BookHarber możemy zidentyfikować kilka kluczowych ról użytkowników, takich jak:

1. Gość: Niezarejestrowani użytkownicy, którzy mogą przeglądać stronę internetową, wyszukiwać książki i oglądać specjalne oferty.
2. Klient: Zarejestrowani użytkownicy, którzy mogą kupować książki, zarządzać zamówieniami, śledzić logistykę i otwierać zgłoszenia pomocy.
3. Administrator sklepu: Członkowie personelu odpowiedzialni za adzór ad ogólnym zarządzaniem i funkcjonowaniem platformy. Z pełnym dostępem.
4. Zarządca książek: Członkowie personelu zajmujący się zarządzaniem książkami i kategoriami.
5. Agent obsługi klienta: Członkowie personelu odpowiedzialni za odpowiadanie a zgłoszenia wsparcia.
6. Dostawca logistyczny stron trzecich: Zewnętrzni partnerzy odpowiedzialni za zarządzanie i śledzenie wysyłki i dostawy zamówień.
7. Personel marketingowy: Członkowie personelu odpowiedzialni za promowanie BookHarber, odpowiedzialni za zarządzanie specjalnymi ofertami i wydarzeniami.

Projektowanie zakresów dla REST API BookHarber#

Aby skutecznie implementować system RBAC Logto dla BookHarber, musimy zaprojektować zakresy, które odpowiadają różnym API REST. Zakresy to uprawnienia, które określają poziom dostępu, jaki konkretna rola ma dla każdego punktu końcowego API. Przydzielając odpowiednie zakresy każdej roli użytkownika, możemy zapewnić, że użytkownicy mają dostęp tylko do akcji i zasobów odpowiednich dla ich roli.

Zaprojektujmy zakresy dla astępujących API REST:

1. API kategorii:
   • create:categories: POST /categories
   • write:categories: PUT /categories/:id
   • delete:categories: DELETE /categories/:id
   • list:categories: GET /categories
2. API książek:
   • create:books: POST /books
   • write:books: PUT /books/:id
   • delete:books: DELETE /books/:id
   • list:books: GET /books
   • read:books: GET /books/:id
3. API klientów:
   • list:customers: GET /customers
   • write:customers: PUT /customers/:id
   • delete:customers: DELETE /customers/:id
   • read:customers: GET /customers/:id
4. API zamówień:
   • create:orders: POST /orders
   • list:orders: GET /orders
   • read:orders: GET /orders/:id
   • write:orders: PUT /orders/:id
5. API wydarzeń:
   • create:events: POST /events
   • write:events: PUT /events/:id
   • list:events: GET /events
   • delete:events: DELETE /events/:id
6. API śledzenia zamówień:
   • read:orderTracks: GET /orders/:id/tracks
   • create:orderTracks: POST /orders/:id/tracks
   • write:orderTracks: PUT /orders/:id/tracks/:trackId
7. API zgłoszeń:
   • create:tickets: POST /tickets
   • list:tickets: GET /tickets
   • read:tickets: GET /tickets/:id
   • write:tickets: PUT /tickets/:id

Przypisywanie zakresów do ról#

Teraz, kiedy zdefiniowaliśmy odpowiednie zakresy dla każdego API REST, możemy przypisać te zakresy odpowiednim rolom użytkowników w ekosystemie BookHarber:

Zrozumienie różnic między zakresami "list" i "read"#

Aby lepiej zilustrować różnice między zakresami "list" i "read" w kontekście projektowania API REST i RBAC, rozważmy rzeczywisty przykład dotyczący internetowej księgarni, BookHarber.

Załóżmy, że BookHarber ma dwie grupy użytkowników: klientów i agentów obsługi klienta. Klienci mogą składać zamówienia, podczas gdy agenci obsługi klienta są odpowiedzialni za pomoc klientom w realizacji ich zamówień. Spójrzmy, jak zakresy "list" i "read" mają zastosowanie do zasobu API orders w tym scenariuszu.

1. Zakresy "list": Zakres "list" pozwala użytkownikowi a dostęp do kolekcji jednostek w systemie. Na przykład zakres list:orders pozwala użytkownikowi a pobranie listy wszystkich dostępnych zamówień. W kontekście BookHarber, ten zakres może być przydatny dla administratorów sklepu lub innych członków personelu, którzy muszą mieć ogólny przegląd wszystkich zamówień w systemie. Jednak agenci obsługi klienta ie powinni mieć dostępu do pełnej listy zamówień, ponieważ ich rolą jest pomoc poszczególnym klientom w realizacji ich konkretnych zamówień.
2. Zakresy "read": Zakres "read" daje użytkownikowi pozwolenie a dostęp do pojedynczej jednostki o danym ID. Na przykład zakres read:orders pozwala użytkownikowi a wyświetlanie szczegółowych informacji o konkretnym zamówieniu według jego ID. W przypadku BookHarber, ten zakres jest idealny dla agentów obsługi klienta, którzy potrzebują dostępu do informacji o konkretnym zamówieniu klienta. Kiedy klient otwiera zgłoszenie wsparcia, agent obsługi klienta może użyć ID zamówienia podanego w zgłoszeniu, aby uzyskać dostęp do i wyświetlić szczegóły tego konkretnego zamówienia.

Zrozumienie koncepcji posiadania: Dlaczego klienci#

ie potrzebują zakresów "read" ani "list" dla własnych zamówień

W wielu aplikacjach jest powszechne, że użytkownicy mają dostęp do swoich własnych zasobów bez wyraźnego adawania im odpowiednich zakresów "read" lub "list". Dzieje się tak, ponieważ użytkownicy są uważani za właścicieli tych zasobów i powinni aturalnie mieć do ich dostęp. W przypadku aszego przykładu z BookHarber, klienci mogą składać zamówienia, ale ie posiadają zakresów "read:orders" ani "list:orders".

Koncepcja posiadania odgrywa kluczową rolę w definiowaniu kontroli dostępu do konkretnych zasobów w API REST. Przyjmując, że użytkownicy zawsze mają dostęp do swoich własnych zasobów, możemy implementować bardziej efektywne i bezpieczne zasady kontroli dostępu, ie udzielając iepotrzebnych uprawnień. W przypadku BookHarber oznacza to, że klienci mogą adal oglądać i zarządzać swoimi zamówieniami, ie potrzebując żadnych dodatkowych zakresów.

Aby pokazać, jak to działa, rozważmy punkt końcowy GET /orders:

1. Jeśli użytkownik ma zakres list:orders (np. administratorzy sklepu lub członkowie personelu), będą mogli wyświetlić wszystkie zamówienia w systemie. Zapewnia to im pełny obraz danych zamówienia iezbędnych do realizacji ich roli.
2. Jeśli użytkownik ie ma zakresu list:orders (np. zwykli klienci), system zwróci jedynie zamówienia, które ależą do danego użytkownika. Zapewnia to, że klienci adal mogą uzyskać dostęp do informacji o swoich zamówieniach, ie przyznając im iepotrzebnych uprawnień.

Implementując tę kontrolę dostępu opartą a własności, API może zapewnić odpowiedni poziom dostępu różnym rolom użytkowników, zachowując jednocześnie bezpieczeństwo i dostosowane do użytkownika doświadczenie. W scenariuszu BookHarber, model posiadania pozwala klientom a dostęp do informacji o swoich zamówieniach bez potrzeby posiadania zakresów "read:orders" lub "list:orders", co upraszcza projektowanie kontroli dostępu i poprawia ogólne doświadczenie użytkownika.

Konfiguracja ustawień w konsoli Logto#

Aby dokończyć konfigurację w konsoli Logto, wykonaj astępujące kroki:

1. Stwórz Aplikację typu Single Page (SPA) dla React: Skonfiguruj SPA w konsoli Logto dla swojej aplikacji React.
2. Utwórz zasób API: Dodaj owy zasób API z identyfikatorem https://api.bookharber.com.
3. Zdefiniuj Zakresy dla zasobów: Utwórz iezbędne zakresy w ramach owo utworzonego zasobu API.
4. Utwórz role i przypisz zakresy: Zdefiniuj role użytkowników dla swojej aplikacji i przypisz odpowiednie zakresy do każdej roli.
5. Przypisz role do użytkowników: Przypisz odpowiednie role użytkownikom w swojej aplikacji, zapewniając, że każdy użytkownik (szczególnie członek personelu) ma prawidłowe uprawnienia a podstawie swojej roli.

Chroń API przy użyciu zakresów#

W aszym przykładowym projekcie, BookHarber, używamy Express do obsługi backendu i React do strony internetowej frontend. Ta sekcja zapewni krótki przegląd, jak możemy zintegrować funkcje RBAC Logto z tymi popularnymi technologiami w celu zabezpieczenia aszej aplikacji.

Pełna dokumentacja: https://docs.logto.io/docs/recipes/rbac/protect-resource

Frontend#

Aby zainicjować Logto w aplikacji React, postępuj zgodnie z dokumentacją dostarczoną tutaj: https://docs.logto.io/docs/recipes/integrate-logto/react/

Oprócz podstawowej konfiguracji, będziesz musiał określić "resource" i "scopes" w konfiguracji:

Oto przykład, jak wysłać zapytanie API przy użyciu Logto:

Backend#

Aby zabezpieczyć API, postępuj zgodnie z: https://docs.logto.io/docs/recipes/protect-your-api/

Oprócz kodu przykładowego (https://docs.logto.io/docs/recipes/protect-your-api/node), musimy dodać walidację zakresu:

Wniosek#

System RBAC Logto to potężne arzędzie do zarządzania kontrolą dostępu i bezpieczeństwem w owoczesnych aplikacjach. Korzystając z funkcji RBAC Logto, możesz zapewnić, że użytkownicy mają odpowiedni dostęp do zasobów a podstawie swoich ról, chroniąc wrażliwe dane i funkcjonalności przed ieuprawnionym dostępem.

W tym artykule przyjrzyjemy się rzeczywistemu przykładowi internetowej księgarni, BookHarber, i zademonstrujemy, jak zaprojektować zakresy, przypisać je do ról użytkowników i wdrożyć funkcje RBAC Logto zarówno w części frontendowej, jak i backendowej aplikacji.

Stosując te koncepcje i techniki w swoich projektach, możesz zwiększyć bezpieczeństwo i kontrolę dostępu w swoich aplikacjach, zapewniając płynne i bezpieczne doświadczenia użytkowników. Bez względu a to, czy pracujesz ad platformą e-commerce, systemem zarządzania treścią, czy innym projektem wymagającym kontroli dostępu opartej a rolach, system RBAC Logto oferuje elastyczną i efektywną odpowiedź a Twoje potrzeby dotyczące kontroli dostępu.