Konfiguracja aplikacji webowej - ustawienia zapytań SQL

Odpowiedz Nowy wątek
2019-05-21 10:19
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?

Pozostało 580 znaków

2019-05-21 10:29
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.

edytowany 1x, ostatnio: a_s_f, 2019-05-21 10:30

Pozostało 580 znaków

2019-05-21 10:35
0

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

Pozostało 580 znaków

2019-05-21 11:27
0

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

Pozostało 580 znaków

2019-05-21 11:44
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.

Pozostało 580 znaków

2019-05-21 12:16
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ę ;-)

Pozostało 580 znaków

2019-05-21 12:49
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[...]security?view=sql-server-2017

Pozostało 580 znaków

2019-05-21 13:32
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...

Pozostało 580 znaków

2019-05-21 14:01

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/ne[...]/mssql_maestro_17_6_released/)

Powodzenia.

Pozostało 580 znaków

2019-05-21 15:29
0

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

Pozostało 580 znaków

2019-05-21 16:12
2

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

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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