Konfiguracja aplikacji webowej - ustawienia zapytań SQL

0

Witam.
Pytanie mam, może banalne. Potrzebuje nakierowania jak trzymać kwestie konfiguracyjne w aplikacji webowej. Problem zaczął się w zapytaniach SQL, które potrzebowałbym, aby były dynamiczne. Jak zrobić uniwersalne, konfigurowalne zapytania SQL? Co gorsze, jak zrobić, żeby szary użytkownik mógł sobie coś zmienić w panelu administracyjnym w tych zapytaniach?

PRZYKŁAD
Użytkownik jest przedstawicielem handlowym, ma ograniczony widok kontrahentów do tych, których obsługuje. Z czasem inny przedstawiciel idzie na urlop lub zostaje zwolniony i ten pierwszy, na ten czas, przejmuje jego grupę kontrahentów.

Niby prostę, ale to nie musi się tyczyć tylko grupy kontrahentów. Są też takie grupy, które wspólnie widzą. W przyszłości może być tak, że dany przedstawiciel będzie miał swoje towary, których inny nie będzie widział. Możliwości jest sporo, a jakoś nie widzi mi się tych wariantów klepać ręcznie.

Czy takie trzymanie zapytań SQL w bazie lub w pliku jest bezpieczne? Czy jest jakieś rozwiązanie, aby szary użytkownik mógł sobie z takim czymś poradzić, nie znając SQL?

0

A nie możesz zrobić tak, żeby każda grupa kontrahentów(towarów) miała zdefiniowaną listę "akwizytorów", którzy obsługują tą grupę? W panelu administracyjnym byłaby możliwość przypinania/odpinania danego handlowca od grupy którą widzi.

0

To nie moja baza danych. Jestem troszkę ograniczony z grzebaniem poprzez jej oryginalne oprogramowanie

0

a może da się to ogarnąć widokami?

0

Niektóre bazy mają wsparcie dla Row Level Security, Column Level Security, Data Labeling. Na Twoim miejscu przyjrzałby się rozwiązaniom oferowanymi przez silniki bazodanowe.
Dopiero później pomyślał o własnym Access Control List.

0

@leggo: Jeśli dobrze rozumiem to na jedno wyjdzie. Musiałbym przygotować wszelkie możliwe widoki, aby szary użytkownik mógł sobie zmieniać, wybierać.

@yarel I dla każdego użytkownika oprogramowania muszę stworzyć użytkownika bazy danych? Przypominam, że system już jest "gotowy" pod oryginalne oprogramowanie. Takie dopisywanie userów do bazy i przypisywanie im uprawnień jest czasochłonne. Gdzie to trzymać? Skąd wiem jakich mam stworzyć i komu co przypisać?.

Wydaje mi się, że wygodniej, szybciej i prościej jest dodać kilka dodatkowych warunków w zapytaniu SQL. Wszystko wskazuje na to, że będą to predefiniowane opcje, albo stworzy się generator zapytań do podstawowych opcji. Coś na zasadzie filtrów w poczcie na o2.

Jakby ktoś jeszcze miał jakieś pomysły to proszę ;-)

1

@AdamWox: nie znam Twojego rozwiązania i nie jestem wróżką, żeby wiedzieć czy łączysz się użytkownikiem technicznym (jakiś app_user) czy użytkownikiem aplikacyjnym (Ziutek).
Jak Ty nie wiesz, co masz stworzyć, to ja tym bardziej ;-)

Z Twojego opisu widzę co najmniej 3 problemy:

  1. konfiguracja biznesowa - czyli kto powinien mieć dostęp do czego
  2. techniczna realizacja - jak modelować tę konfigurację i zapewnić aktualizację
  3. jak zintegrować rozwiązanie z "oryginalnym oprogramowaniem"

Rozwiązania Row Level Secuirty/Column Level Security są dość elastyczne. Przy definiowaniu filtrów nie ma obowiązku korzystania z nazwy użytkownika. Można korzystać z "kontekstu sesji" i np. w aplikacji ustawiać coś w tym kontekście, a funkcjonalność RLS odczyta wartość z sesji i doda odpowiedni predykat . Dla innego kontrahenta/sprzedawcy ustawiać w sesji coś innego itd.

https://docs.microsoft.com/en-us/sql/relational-databases/security/row-level-security?view=sql-server-2017

0

@yarel: Ja wiem co chce zrobić, pytanie moje brzmi jak to zrobić. Chce dać głównemu operatorowi możliwość ustawiania w panelu konfiguracyjnym widoczności danych dla konkretnego użytkownika. Musi to być na tyle idiotoodporne, że szary, nietechniczny user da sobie z tym radę.
Jeśli czegoś nie wiesz to zwyczajnie zapytaj. Wydawało mi się, że wszystko co najważniejsze opisałem w poście.

Z Twojego opisu widzę co najmniej 3 problemy:

  1. konfiguracja biznesowa - czyli kto powinien mieć dostęp do czego
  2. techniczna realizacja - jak modelować tę konfigurację i zapewnić aktualizację
  3. jak zintegrować rozwiązanie z "oryginalnym oprogramowaniem"

Punkt 1. może być ugrany opcją roli (administrator, operator, klient, przedstawiciel) - można takie rzeczy po stronie API ustawić. Właśnie punkty 2 i 3 są kluczowymi punktami - uniwersalna konfiguracja kompatybilna z oryginalnym oprogramowaniem. Nie przypuszczałem, że fakt iż to nie moja baza może być w tej kwestii kluczowym problemem. Liczyłem na odpowiedzi typu - pobierz sobie z nuget 'xxx' i skonfiguruj jak w tym linku 'link'... Chyba się przeliczyłem...

1

Odpowiadając na poziomie opisu Twojego problemu "Najlepiej robić, to tak żeby było dobrze i wystarczy etykietować dane i ustawić politykę dostępu na podstawie kontekstu i tabelki".

Oczekujesz złotego rozwiązania, a nawet nie chciało Ci się opisać jaką bazę masz pod spodem, nie wspominając o tym czym jest "oryginalny produkt".
Dziś chyba mam słabszy dzień, bo nie chce mi się walczyć i dopytywać o każdy drobiazg, tak jakby to mi zależało na rozwiązaniu Twojego problemu.

Pewnie nawet nie chciało Ci się przeczytać jak działa RLS i sprawdzić czy są jakieś narzędzia klikalne (https://www.sqlmaestro.com/news/company/mssql_maestro_17_6_released/)

Powodzenia.

0

Ok. Oznaczam to jako rozwiązanie problemu i nie mam zamiaru kontynuować tej dyskusji.

2

Do dynamicznego budowania zapytań SQL to chyba klasa Expression się nadaje. Chyba.

0

Tak, zrób sobie dynamic predicate builder, który będzie operował na Expressionach, ale to wtedy będziesz miał po prostu LINQ, więc musiałbyś użyć jakiegoś prawdziwego ORMa typu EF Core :D

I wtedy na podstawie ustawień usera będzie budowany SQL.

0

A takie coś się nada?
SqlKata the dotnet sql query builder

0

Zależy jak bardzo masz skomplikowany ten system pewnie

Spróbuj.

0

Korzystam z EF Core w tym projekcie, ale myślę nad powrotem do Dappera. Gdzieś tam w praniu wyszło, że jednak mi EF nie pasuje tutaj, a tak wojowałem, w którymś tam poście :D
Problem w tym, że jak robi się parametry w Dapperze to on automatycznie nie wyłapuje, że ten parametr jest null, albo pusty i ma go pominąć. To by była fajna funkcja bo przygotowałbym sobie zapytanie tak, aby brał wszystkie opcje pod uwagę, ale sam WHERE byłby dynamiczny na podstawie czy wartość parametru jest null czy nie. Wychodzi na to, że muszę to napisać sam ;)

1 użytkowników online, w tym zalogowanych: 0, gości: 1