Mam aplikacje Windows Forms i druga aplikacje w webapi. Loguje sie do aplikacji desktop poprzez webapi. W odpowiedzi z api dostaje uprawnienia jakie mi przysługuja. W jaki sposob sprawdzac te uprawnienia po stronie api? Jakos je odsyłać z aplikacji desktopowej do kazdej akcji webapi jakiej bede uzywal zeby sprawdzic czy moge jej uzyc?
0
2
W odpowiedzi z api dostaje uprawnienia jakie mi przysługuja.
W jaki sposob sprawdzac te uprawnienia po stronie api? Jakos je odsyłać z aplikacji desktopowej do kazdej akcji webapi jakiej bede uzywal zeby sprawdzic czy moge jej uzyc?
no przecież je masz po stronie api
odbieranie uprawnien od klienta to mega zly pomysl bo może tam wpisać co chce :o
musisz zidentyfikować usera który wysyła request, a właściwie twoje auth middleware powinno to zrobić
0
możesz albo przy każdej akcji po stronie serwera odpytywać bazę danych o uprawnienia albo przy logowaniu utworzyć po stronie serwera sesję w pamięci lub w bazie i sprawdzać uprawnienia tam. to drugie rozwiązanie odciąża trochę bazę danych w przypadkach kiedy zdobycie efektywnych uprawnień użytkownika jest trudne - na przykład przy skomplikowanej hierarchii dziedziczenia uprawnień według grupy, ale ma taką wadę że przy zmianie uprawnień użytkownika trzeba zresetować dane w sesji i poinformować o tym wszystkie serwery przy aplikacjach rozproszonych.
0
właśnie zastanawialem sie czy tworzyc jakies sesje czy nie. @WeiXiao a moglbys przyblizyc taką identyfikacje uzytkownika w auth middleware?
0
Można zrobić uprawnienia po stronie API tak jak napisał @WeiXiao ale dodatkowo powinieneś też na podstawie tych uprawnień budować UI. Możesz jakieś drzewko uprawnień wysłać użytkownikowi w tokenie jaki dostanie z API po zalogowaniu się. Jaki jest sens wyświetlać użytkownikowi coś do czego nie ma dostępu?
3
Załóżmy że używasz jwt.
Przy logowaniu generujesz token i wprowadzasz do niego tzw. claimsy np. id usera
User go przechowuje i przy każdym requescie dodaje header Authorization: Bearer <token>
Auth Middleware przy endpointach [Authorize] waliduje ten token, z tego co kojarzę to działa to +- jakoś tak: bierze m.in zawartość tego jsona i przelicza token stosując secret key podany w startupie i jeżeli wyjdzie ten sam token co od usera, to jest poprawny.
Jeżeli jest poprawny to puszcza do endpointa, a jak nie to elo
Później możesz wyciągnąć sobie z http contextu te claimsy przesłane w tym tokenie, więc m.in id usera.
Tutaj masz opisane jak to się konfiguruje itd.
ASP.NET Core 3.1 - JWT Authentication Tutorial with Example API
0
@WeiXiao: dzięki. Mam jeszcze pytanie. Jak juz bede miał wyciagniety z contextu ten id uzytkownika to api powinno na jego podstawie przy kazdym requescie uzytkownika poszukac w bazie do czego ma on uprawnienia i na podstawie tego dodawac atrubut np [Authorize(Role="można usunąć uzytkownika")]?
0
Jeżeli w claimsach dodasz claims dotyczący ról, to wtedy atrybut Authorize z niego skorzysta i sobie wyciągnie je sam.
Ale jeżeli są to bardziej skomplikowane uprawnienia, to chyba pozostaje baza albo cache, no bo jeżeli te uprawnienia pewnie się zmieniają raz na pół roku, to nie ma sensu za każdym razem walić do bazy. Pamiętaj tylko aby przy zmianie uprawnień wywalać to z cache.
0
@WeiXiao: tylko wtedy musiałbym juz zrobic jakis swoj atrybut, zeby sie to sprawdzanie w bazie wykonało?
0
Nie musisz tworzyć atrybutu, ale możesz, są rożne podejścia.
Możesz też w kontrolerze przekazać Id usera do "warstwy" niżej.