Drukowana wersja tematu

Napisany przez: Lord 4.07.2019, 14:05:42

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

Napisany przez: netir 19.07.2019, 11:46:38

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.

Napisany przez: Lord 19.07.2019, 12:02:58

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

[PHP] pobierz, plaintext 
$api->get('/', 'App\Http\Controllers\UserController@index'); 
[PHP] pobierz, plaintext 

gdzie zwracam tylko te dane jakie o użytkowniku może widziec inny user

[PHP] pobierz, plaintext 
$api->get('/', 'App\Http\Controllers\UserAdminController@index'); 
[PHP] pobierz, plaintext 

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.

Napisany przez: netir 19.07.2019, 12:16:45

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

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

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

Napisany przez: Lord 19.07.2019, 12:34:28

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.

Napisany przez: markonix 20.07.2019, 11: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).

Napisany przez: netir 21.07.2019, 00:13:29

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?

Napisany przez: viking 21.07.2019, 06:37:10

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.

Napisany przez: netir 21.07.2019, 10:58:15

@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?

Napisany przez: markonix 21.07.2019, 17:16:44

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".