Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

 
Reply to this topicStart new topic
> [inny][Laravel] Uprawnienia w RestAPI
Lord
post 4.07.2019, 14:05:42
Post #1





Grupa: Zarejestrowani
Postów: 239
Pomógł: 32
Dołączył: 10.03.2004

Ostrzeżenie: (10%)
X----


Mam dany model i moim celem jest by w zależności od uprawnień użytkownika zwracać określone pole lub pozwalać na modyfikacje tylko określonych pól.
Może ktoś wyjaśnić jak to zrobić dobrze nie chodzi mi o sam kod ale o idee. Gdzie i jak i co wykorzystać.

Przykład:

Użytkownik może zmienić dane adresowe (miasto itd) ale nie może zmienić np. statusu swojego konta.
Przy pobieraniu danych, użytkownik i admin ma pełne dane konta, ale nie zalogowany użytkownik widzi tylko część danych.

Korzystam z https://github.com/dingo/api

Ten post edytował Lord 4.07.2019, 14:06:11
Go to the top of the page
+Quote Post
netir
post 19.07.2019, 11:46:38
Post #2





Grupa: Zarejestrowani
Postów: 44
Pomógł: 5
Dołączył: 20.05.2019

Ostrzeżenie: (0%)
-----


Zależy jak bardzo rozbudowany ma być ten system uprawnień, możesz skorzystać z paczki.

Jeżeli chodzi o idee to ja bym dodał typ użytkownika do migracji users'ów i w modelu w atrybutach (https://laravel.com/docs/5.8/eloquent-mutators) sprawdzał z kim mam do czynienia przed zwróceniem pól - wszystko zależy od tego co dokładnie musisz rozwiązać.

Co do przykładu to można dodać middleware (https://laravel.com/docs/5.8/middleware) do grupy routsów i w zależności od typu usera kierować do odpowiedniego panelu - admina, użytkownika etc.

Ten post edytował netir 19.07.2019, 11:47:41
Go to the top of the page
+Quote Post
Lord
post 19.07.2019, 12:02:58
Post #3





Grupa: Zarejestrowani
Postów: 239
Pomógł: 32
Dołączył: 10.03.2004

Ostrzeżenie: (10%)
X----


Czyli co dla każdego rodzaju zapytania mam tworzyć oddzielnny controller inny endpoint?


  1. $api->get('/', 'App\Http\Controllers\UserController@index');
gdzie zwracam tylko te dane jakie o użytkowniku może widziec inny user

  1. $api->get('/', 'App\Http\Controllers\UserAdminController@index');
gdzie zwracam tylko te dane jakie o użytkowniku moze widziec admin

dobrze rozumiem ?

bo mam tutaj też classe transform gdzie mogę sobie ustawić sposób prezentacji danych w odpowiedzi i może tam mógłbym podać inne dane w zależności od roli użytkownika.

Oddzielne controllery może by i rozwiązały kwestię update, bo uzytkownik może utworzyć konto ale nie może po jego utworzeniu modyfikować wszystkich danych, tylko admin ma uprawnienia do pełnej edycji.

System nie jest skomplikowany bo tak naprawdę są 3 lvl użytkowników, admin, użytkownik i nie zarejestrowany.

Ten post edytował Lord 19.07.2019, 12:07:35
Go to the top of the page
+Quote Post
netir
post 19.07.2019, 12:16:45
Post #4





Grupa: Zarejestrowani
Postów: 44
Pomógł: 5
Dołączył: 20.05.2019

Ostrzeżenie: (0%)
-----


Tak dokładnie po to są controllery, żeby kontrolować smile.gif

Jeżeli chodzi o strukturę to bym zrobił to tak:
Http
--Controllers
----Panel
------Admin
--------ProfileController
------User
--------ProfileController


w routsach zrób sobie grupę i dodaj w niej middleware w którym sprawdzasz typ usera i kierujesz do \Admin lub \User ProfileController'a przemyśl sobie to jakoś czytelnie wrzuć w foreach'a, żeby nie pisać 10 razy prawie tego samego endpoint'a.

EDIT:
teraz tak się wczytałem mocniej i z tego co rozumiem to nie jest panel, tylko typowo frontowe dane? W takim razie zasada ta sama, tylko struktura dopasowana inaczej tongue.gif

Co do paczki API to nigdy z niego nie korzystałem, Laravel oferuje własne rozwiązania REST API i resources do modelowania danych.

Ten post edytował netir 19.07.2019, 12:31:14
Go to the top of the page
+Quote Post
Lord
post 19.07.2019, 12:34:28
Post #5





Grupa: Zarejestrowani
Postów: 239
Pomógł: 32
Dołączył: 10.03.2004

Ostrzeżenie: (10%)
X----


Cytat(netir @ 19.07.2019, 13:16:45 ) *
EDIT:
teraz tak się wczytałem mocniej i z tego co rozumiem to nie jest panel, tylko typowo frontowe dane? W takim razie zasada ta sama, tylko struktura dopasowana inaczej tongue.gif


Tak to są dane na front pod appke w Vue i chodziło mi o to by nikt nie dostawał za dużo danych bo wiadomo, że mogę wyświetlić na froncie co chce, ale w odpowiedzi nie chce by jakies dane wyszły ponad to co jest konieczne.
Go to the top of the page
+Quote Post
markonix
post 20.07.2019, 11:40:56
Post #6





Grupa: Zarejestrowani
Postów: 2 707
Pomógł: 290
Dołączył: 16.12.2008
Skąd: Śląsk

Ostrzeżenie: (0%)
-----


Cytat(netir @ 19.07.2019, 12:46:38 ) *
i w modelu w atrybutach (https://laravel.com/docs/5.8/eloquent-mutators) sprawdzał z kim mam do czynienia przed zwróceniem pól - wszystko zależy od tego co dokładnie musisz rozwiązać.

Autoryzacja w getterach i setterach? Mega słabe. Nie do tego służą.

Do tego czy użytkownik może edytować służy po pierwsze fillable, jako tak pierwsza linia obrony dla najważniejszych atrybutów, potem dla tych mniej istotnych najnormalniej w świecie walidacja za pomocą klasy Request - do insert/update przekazujesz przefiltrowany request, albo jeżeli chcesz komunikować o braku dostępu do danej zmiennej to robisz to krok wcześniej czyli w rules (walidacja właściwa).

Ten post edytował markonix 20.07.2019, 11:43:51


--------------------
Go to the top of the page
+Quote Post
netir
post 21.07.2019, 00:13:29
Post #7





Grupa: Zarejestrowani
Postów: 44
Pomógł: 5
Dołączył: 20.05.2019

Ostrzeżenie: (0%)
-----


Cytat(markonix @ 20.07.2019, 12:40:56 ) *
Autoryzacja w getterach i setterach? Mega słabe. Nie do tego służą.

Do tego czy użytkownik może edytować służy po pierwsze fillable, jako tak pierwsza linia obrony dla najważniejszych atrybutów, potem dla tych mniej istotnych najnormalniej w świecie walidacja za pomocą klasy Request - do insert/update przekazujesz przefiltrowany request, albo jeżeli chcesz komunikować o braku dostępu do danej zmiennej to robisz to krok wcześniej czyli w rules (walidacja właściwa).



Założenie jest takie, że na froncie user dostaje w requescie tylko pola, które może edytować, więc rules i fillable odpada. Chyba najlepsze będzie w tym wypadku po prostu middleware, które skieruje do odpowiedniego kontrolelra, a reszta w service layer nie sądzisz?

Ten post edytował netir 21.07.2019, 00:17:21
Go to the top of the page
+Quote Post
viking
post 21.07.2019, 06:37:10
Post #8





Grupa: Zarejestrowani
Postów: 6 365
Pomógł: 1113
Dołączył: 30.08.2006

Ostrzeżenie: (0%)
-----


Klasy reprezentujących model możesz mieć wiele i dla każdego odpowiednie fillable. Poczytaj jeszcze o gate. Spatie permission domyślnie też ogranicza w ten sposób dostęp do modelu.


--------------------
Go to the top of the page
+Quote Post
netir
post 21.07.2019, 10:58:15
Post #9





Grupa: Zarejestrowani
Postów: 44
Pomógł: 5
Dołączył: 20.05.2019

Ostrzeżenie: (0%)
-----


@viking

Gates i policies są mega, nie czytałem o nich wcześniej, dzięki.

Natomiast co do "Klasy reprezentujących model możesz mieć wiele i dla każdego odpowiednie fillable", proponujesz tworzyć dodatkowe klasy rozszerzające model dla każdego typu usera, po to, żeby dodać fillable?
Go to the top of the page
+Quote Post
markonix
post 21.07.2019, 17:16:44
Post #10





Grupa: Zarejestrowani
Postów: 2 707
Pomógł: 290
Dołączył: 16.12.2008
Skąd: Śląsk

Ostrzeżenie: (0%)
-----


Dostęp do edycji/dodawania już napisałem jak rozwiązujemy - walidacją/filtracją, a to aby get'em otrzymać odchudzony obiekt możemy wykorzystać API Resource.
Oczywiście możliwe, że już ktoś wpadł na to aby ubrać to w jakąś libkę, która by to robiła za pomocą jednej "konfiguracji".


--------------------
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 Użytkowników czyta ten temat (1 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Wersja Lo-Fi Aktualny czas: 19.03.2024 - 05:35