Czy użycie warunkowych warunków bezpieczeństwa w związku z naruszeniem MVC?

10

Często to, co wyświetla się użytkownikowi (np. Na stronie internetowej), będzie częściowo oparte na kontroli bezpieczeństwa. Zazwyczaj uważam bezpieczeństwo na poziomie użytkownika / ACL za część logiki biznesowej systemu. Jeśli widok wyraźnie sprawdza zabezpieczenia w celu warunkowego wyświetlania elementów interfejsu użytkownika, czy narusza MVC poprzez zawieranie logiki biznesowej?

— Matt S.
źródło

Jaka byłaby alternatywa?

1

Używasz tego, co zapewnia najlepsze bezpieczeństwo, nawet jeśli jest to przez niektórych uważane za anty-wzór .

— zxcdw,

6

Mogą istnieć dwa typy warunków bezpieczeństwa, jeden w modelu, a drugi w widoku. Widok kontroluje wyświetlanie odpowiednich elementów w zależności od uprawnień bieżącego użytkownika, ale model kontroluje dostęp do podstawowych danych. Tak długo, jak model ma wszystkie odpowiednie weryfikacje / walidacje, nawet jeśli brakuje widoku, nadal istnieje bezpieczeństwo.

Zwykle musisz mieć jedno i drugie, ponieważ widok musi się zmienić dla różnych poziomów / ról. Kontroler wysyła odpowiednie dane, które zmieniłyby widok, ale widok nadal musi coś zrobić z tymi danymi, aby ukryć / wyświetlić zawartość właściwemu użytkownikowi.

Właśnie dlatego większość ram szablonów ma elementy warunkowe ( przykład kierownicy ):

{{#if isCurrentUserAdmin}}
    ....
{{/if}

Oznacza to, że nie stanowi to naruszenia, o ile odpowiednie elementy znajdują się we właściwym miejscu.

— znane
źródło

4

Tak i nie.

Jeśli widok podejmuje właściwą decyzję bezpieczeństwa, to tak, naruszasz MVC. Jeśli jednak widok deleguje rzeczywistą decyzję do modelu, to nic ci nie jest. Nie ma nic złego w widoku podejmowania decyzji, które elementy pokazać, na podstawie informacji z modelu.

Na przykład, jeśli masz przycisk „edytuj”, który jest widoczny tylko dla użytkowników z uprawnieniami „redaktora”, możesz zapytać model, kto jest bieżącym użytkownikiem i czy ma on uprawnienia „redaktora”, używając tych informacji, aby zdecydować, czy wyświetlić przycisk, czy nie. Jeśli jednak widok miałby wykonywać logikę uwierzytelniania i autoryzacji, naruszyłbyś MVC.

— tdammers
źródło

2

Powiedziałbym „ nie” .

Ale z innego powodu niż powiedział @rvcoutinho (choć cytuje wikipedię, co sprawia, że źle się czuję)

Powiedziałbym, że wszelkie istotne obawy dotyczące bezpieczeństwa powinny być podzielone przez Model podany dla widoku (w zależności od liczby kombinacji, z których możesz chcieć użyć ViewModel z tego powodu), ponieważ możesz mieć przełączniki dla bitów bezpieczeństwa.

Pozwala to na weryfikację bezpieczeństwa dwuwarstwowego: w warstwie interfejsu użytkownika, w przypadku normalnego przypadku, informacje zwrotne są odwracane, a także w warstwie serwerowej w przypadku złych aktorów, w których model utrzymuje w sobie wiedzę o bezpieczeństwie, więc kontroler przekazuje informacje do model, który natychmiast go odrzuca.

Takie dwuwarstwowe zabezpieczenia są standardem w branży, a dzięki temu logika bezpieczeństwa musi istnieć tylko w dwóch miejscach, więc jest to bonus, gdy tylko umieścisz logikę bezpieczeństwa w kontrolerze, umieścisz ją tam i w Interfejs użytkownika i model (model potrzebuje go, ponieważ jest to ostatnia linia obrony i jest szczególnie ważny do wszelkich zastosowań poza tą aplikacją internetową MVC, takich jak klient stacjonarny lub dowolne narzędzia do zarządzania serwerem)

— Jimmy Hoffa
źródło

Twierdzenie Wikipedii, że „kontroler może wysyłać polecenia do powiązanego widoku w celu zmiany prezentacji modelu widoku” wydaje się bardziej pasować do Model-View-Presenter , ponieważ model interaktywny, który zdaje się opisywać, jest tam możliwy, podczas gdy w MVC jeden raz widok jest renderowany, nie ma żadnych dalszych działań między widokiem a kontrolerem.

— Robert Harvey

1

@RobertHarvey Zgadzam się, że stwierdzenie nie pasuje do mojej definicji MVC, ale na szczęście pracujemy w branży, w której o poprawności decyduje wiele umów, a nie jakakolwiek sprawdzalność, ponieważ definicje te unoszą się jakby z eteru z stale ewoluująca podstawa pozwalająca każdemu na przygotowanie własnych dań na wynos. Innymi słowy, prawdopodobnie tak samo się mylę jak wszyscy tutaj.

— Jimmy Hoffa

3

Dlatego myślę, że ludzie i tak są zbyt pedantyczni w takich sprawach.

— Robert Harvey,

1

@rvcoutinho W ogóle nie powiedziałbym, że byłem dosłowny; masz po swojej stronie referencje, wszystko, co mam, to moja opinia, więc w mojej opinii oznacza to, że prawdopodobnie się mylę i dlatego o tym wspomniałem. Wydaje mi się, że moja opinia jest na tyle wiarygodna, że warto się nią podzielić, mimo że nie mam żadnych referencji, więc i tak to zrobiłem, niezależnie od tego, jak powiedziałem, prawdopodobnie się mylę.

— Jimmy Hoffa

1

@rvcoutinho: Właściwie to miałem na myśli pytanie OP. :) Nie ma nic złego w regułach, chyba że reguły utrudniają wykonanie zadania.

— Robert Harvey

2

Powiedziałbym „ nie” .

Zazwyczaj tego rodzaju kontrole bezpieczeństwa przeprowadzane są przez kontrolera.

Z Wikipedii :

Kontroler może wysyłać polecenia do skojarzonego z nim widoku w celu zmiany prezentacji modelu w widoku

I nie sądzę, że należy to zrobić bezpośrednio w widoku. Na przykład, jeśli odbywa się to za pomocą javascript, może to stanowić problem bezpieczeństwa (można wyłączyć javascript i uzyskać dostęp do uprzywilejowanych danych).

Znów z Wikipedii :

Widok żąda od modelu informacji potrzebnych do wygenerowania reprezentacji wyjściowej .

— rvcoutinho
źródło

1

W wielu systemach oprogramowania wyświetlanie elementu zależy od poziomu bezpieczeństwa użytkownika. Chociaż możesz zablokować wyświetlanie elementu danych, ustawiając go na zero lub zero w widoku modelu, nazwa lub opis elementu danych nadal będą wyświetlane. Jedynym miejscem, w którym można (w praktyczny sposób) zablokować wyświetlanie opisu elementu danych, jest widok.

— Robert Harvey

Nie zgadzam się. Powiedziałbym, że widok zażąda danych, kontroler manipuluje modelem, a widok ponownie go reprezentuje. Widok powinien odpowiadać tylko za reprezentację danych wyjściowych.

— rvcoutinho

Dlatego widok musi ukrywać te elementy wizualne, których użytkownik nie musi widzieć. Administrator nie ponosi odpowiedzialności za tworzenie wizualnej reprezentacji danych; Widok jest. Oczywiście, jeśli to, co wyświetlasz, jest tak wrażliwe, że nie może nawet znajdować się w widoku / źródle, to kontroler musi zrobić inny widok.

— Robert Harvey

1

O to mi chodzi. Widok powinien być inny. O ile rozumiem, wygląda na to, że widok powinien zajmować się tylko reprezentacją danych. Poprzez reprezentację miałbym na myśli, jak coś pokazać, a nie kiedy to pokazywać. Twoje komentarze są jednak całkowicie trafne.

— rvcoutinho

Myślę, że możemy używać tego samego wyrażenia do dwóch różnych rzeczy. Jaki jest inny widok? Ale myślę, że zgadzamy się w najważniejszej sprawie: jeśli jest wrażliwa na bezpieczeństwo, widok nie powinien być rozpatrywany.

— rvcoutinho

1

Istnieje kilka problemów związanych z tym pytaniem.

Uwierzytelnianie (to ten użytkownik, o którym mówi, że jest) nie powinno być przedmiotem zainteresowania Widoku.
Autoryzacja (jest bieżący użytkownik może robić to ) jest problemem z widzenia, gdyż może to mieć wpływ na to, co zostanie zaprezentowane użytkownikowi. Zatem kod wyświetlający przycisk edycji może być otoczony warunkowym podobnym if model.userCanEdit() ... endif.
Określenie, jakie atrybuty autoryzacji posiada użytkownik, czyli logiki biznesowej i należy je umieścić w modelu. (Na przykład, że uprawnienie do edycji wymaga posiadania 2000 reputacji lub że musisz być autorem lub moderatorem)

— Bart van Ingen Schenau
źródło

0

Jeśli chodzi tylko o wyświetlanie elementu interfejsu użytkownika, myślę, że jest w porządku (jak inaczej byś to zrobił?). Jeśli w tych elementach byłyby jakieś dane, model powinien upewnić się, że pojemniki są puste. I oczywiście kod, aby uzyskać dane uprawnień, powinien był zostać przetworzony przed widokiem, więc tutaj nie ma aktywnego dostępu do modelu.

— Thorsten Müller
źródło

0

Jeśli widok wyraźnie sprawdza zabezpieczenia w celu warunkowego wyświetlania elementów interfejsu użytkownika, czy narusza MVC poprzez zawieranie logiki biznesowej?

Tak, jest to naruszenie MVC.

Widok służy tylko do wyświetlania elementów, a logika powinna znajdować się w modelu. Umożliwiając widokowi zrobienie czegoś (w twoim przypadku sprawdź bezpieczeństwo), umieszczasz tam logikę.

— BЈовић
źródło

Skąd więc widok wiedziałby, czy wyświetlać coś w rodzaju przycisku edycji?

— Matt S

@MattS Prezenter wywołuje funkcję w widoku, aby pokazać lub ukryć ten przycisk (w zależności od stanu w modelu).

— BЈовић