Opanowanie RBAC w Logto: Kompleksowy przykład z życia codziennego
Ten artykuł oferuje kompleksowy przewodnik po opanowaniu kontroli dostępu opartej
a rolach (RBAC) w Logto, przy użyciu rzeczywistego przykładu internetowej księgarni do zbadania kluczowych ról użytkowników, zakresów i integracji funkcji RBAC Logto w aplikacjach frontendowych i backendowych w celu zwiększenia bezpieczeństwa i kontroli dostępu.
SijieDeveloper
Przestań tracić tygodnie na uwierzytelnianie użytkowników
Uruchamiaj bezpieczne aplikacje szybciej z Logto. Zintegruj uwierzytelnianie użytkowników w kilka minut i skup się na swoim głównym produkcie.
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ą:
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.
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.
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.
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.
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.
W ekosystemie BookHarber możemy zidentyfikować kilka kluczowych ról użytkowników, takich jak:
Gość: Niezarejestrowani użytkownicy, którzy mogą przeglądać stronę internetową, wyszukiwać książki i oglądać specjalne oferty.
Klient: Zarejestrowani użytkownicy, którzy mogą kupować książki, zarządzać zamówieniami, śledzić logistykę i otwierać zgłoszenia pomocy.
Administrator sklepu: Członkowie personelu odpowiedzialni za
adzór
ad ogólnym zarządzaniem i funkcjonowaniem platformy. Z pełnym dostępem.
Zarządca książek: Członkowie personelu zajmujący się zarządzaniem książkami i kategoriami.
Agent obsługi klienta: Członkowie personelu odpowiedzialni za odpowiadanie
a zgłoszenia wsparcia.
Dostawca logistyczny stron trzecich: Zewnętrzni partnerzy odpowiedzialni za zarządzanie i śledzenie wysyłki i dostawy zamówień.
Personel marketingowy: Członkowie personelu odpowiedzialni za promowanie BookHarber, odpowiedzialni za zarządzanie specjalnymi ofertami i wydarzeniami.
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:
API kategorii:
create:categories: POST /categories
write:categories: PUT /categories/:id
delete:categories: DELETE /categories/:id
list:categories: GET /categories
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
API klientów:
list:customers: GET /customers
write:customers: PUT /customers/:id
delete:customers: DELETE /customers/:id
read:customers: GET /customers/:id
API zamówień:
create:orders: POST /orders
list:orders: GET /orders
read:orders: GET /orders/:id
write:orders: PUT /orders/:id
API wydarzeń:
create:events: POST /events
write:events: PUT /events/:id
list:events: GET /events
delete:events: DELETE /events/:id
API śledzenia zamówień:
read:orderTracks: GET /orders/:id/tracks
create:orderTracks: POST /orders/:id/tracks
write:orderTracks: PUT /orders/:id/tracks/:trackId
Teraz, kiedy zdefiniowaliśmy odpowiednie zakresy dla każdego API REST, możemy przypisać te zakresy odpowiednim rolom użytkowników w ekosystemie BookHarber:
Zakresy
Gość
Klient
Administrator sklepu
Zarządca książek
Agent obsługi klienta
Dostawca logistyczny stron trzecich
Personel marketingowy
create:categories
✓
✓
write:categories
✓
✓
delete:categories
✓
✓
list:categories
✓
✓
✓
✓
✓
✓
✓
create:books
✓
✓
write:books
✓
✓
delete:books
✓
✓
list:books
✓
✓
✓
✓
✓
✓
✓
read:books
✓
✓
✓
✓
✓
✓
✓
list:customers
✓
✓
write:customers
✓
delete:customers
✓
read:customers
✓
✓
create:orders
✓
✓
✓
✓
✓
✓
list:orders
✓
read:orders
✓
✓
write:orders
✓
create:events
✓
✓
write:events
✓
✓
list:events
✓
✓
✓
✓
✓
✓
✓
delete:events
✓
✓
read:orderTracks
✓
✓
✓
create:orderTracks
✓
✓
write:orderTracks
✓
✓
create:tickets
✓
✓
✓
✓
✓
✓
list:tickets
✓
✓
read:tickets
✓
✓
write:tickets
✓
✓
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.
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ń.
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:
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.
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.
Aby dokończyć konfigurację w konsoli Logto, wykonaj
astępujące kroki:
Stwórz Aplikację typu Single Page (SPA) dla React: Skonfiguruj SPA w konsoli Logto dla swojej aplikacji React.
Utwórz zasób API: Dodaj
owy zasób API z identyfikatorem https://api.bookharber.com.
Zdefiniuj Zakresy dla zasobów: Utwórz
iezbędne zakresy w ramach
owo utworzonego zasobu API.
Utwórz role i przypisz zakresy: Zdefiniuj role użytkowników dla swojej aplikacji i przypisz odpowiednie zakresy do każdej roli.
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.
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.
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.
