Aktywne Wpisy
tenebrarum +2
#samochody #motoryzacja
Jakie auto do 30,000 szekli?
Wymagania (w kolejności ważności):
1. Nie wygląda jak gówno
2. Mała awaryjność silnika
3. Wszystko tylko nie kombi
4. Do dojazdów do pracy/przejażdżek krajowych i międzykrajowych/ogolnie daily
Bo serio poza E90 nie widzę opcji wszystko wygląda jak masa kałowa, może poza dobrym A5 8T
Jakie auto do 30,000 szekli?
Wymagania (w kolejności ważności):
1. Nie wygląda jak gówno
2. Mała awaryjność silnika
3. Wszystko tylko nie kombi
4. Do dojazdów do pracy/przejażdżek krajowych i międzykrajowych/ogolnie daily
Bo serio poza E90 nie widzę opcji wszystko wygląda jak masa kałowa, może poza dobrym A5 8T
GN0SIS +34
Aktualnie mam w ten sposób wyglądający schemat bazy danych:
https://i.imgur.com/CHuwz5f.png
Chciałbym, żeby ten serwer autoryzacyjny wspierał obecnie trzy sposoby autoryzacji: Authorization Code, Client Credentials oraz Resource Owner Password Credentials.
1. Authorization Code
2. Client Credentials
3. Resource Owner Password Credentials
---
W przypadku 1. i 3.,
access_token
jest powiązany z kontem użytkownikiem. Zakładając, że miałby zawierać informacje ooauth_scopes
, do których ma dostęp, byłyby to elementy wspólne między uprawnieniami użytkownika oraz klienta.W przypadku 2.,
access_token
nie miałby żadnych informacji na temat użytkownika.---
Jak w takiej sytuacji powinna wyglądać obsługa ról użytkownika? Ok, mamy te
oauth_scopes
przypisane do klienta i do konta użytkownika, ale one chyba bardziej definiują dostęp do konkretnych zasobów. Co z rolami typu admin / menedżer / etc, definiującymi np. do jakich podstron klient powinien mieć dostęp?Jak powinna wyglądać autoryzacja zapytań w mikroserwisach? Przeglądarka użytkownika komunikuje się z API. API ma dostęp do kilku innych mikroserwisów. Co, jeśli te mikroserwisy komunikują się z innymi, które są gdzieś jeszcze bardziej zagnieżdżone? API powinno mieć do nich dostęp? Czy API powinno mieć dostęp tylko do mikroserwisów, z którymi się komunikuje bezpośrednio? Co wtedy ze scopem? W końcu użytkownik ma swoje
oauth_scopes
, API ma swoje i wyodrębniamy tylko wspólne elementy, więc te głębiej zagnieżdżone mikroserwisy mogą już nie znać wszystkich uprawnień użytkownika.Pewnie o czymś zapomniałem, więc jeśli ktoś miałby jakieś inne sugestie / uwagi / cokolwiek, byłbym wdzięczny!
#webdev #javascript #nodejs
scope=x,y,z
.W takiej sytuacji powinna chyba powstać relacja między
access_tokenem
, aoauth_scopes
. No ale właśnie - skoro ja chciałbym używać JWT, nie mam w bazie tabeli dla tokenów.A i tak pewnie nie przewidziałem lub źle podszedłem do dziesiątek innych rzeczy (╥﹏
Stąd mój schemat. Jest on takim zlepkiem
Co do ról użytkownika, to oauth2 tego nie obsługuje. Role i dostęp do poszczególnych akcji to ACL - powinna to
access_tokenie
, żeby przeglądarka użytkownika też miała do nich dostęp, a przy okazji pozostałe mikroserwisy nie musiały odpytywać o role bazy danych przy każdym zapytaniu.Jeśli chodzi o komunikację wewnętrzną - ok, przekazujesz jakiś tam token jako nagłówek. Ale co teraz z tokenem użytkownika? Jakiś głębiej zagnieżdżony mikroserwis w ogóle go nie dostaje? Więc zakładasz, że