Zaawansowanie filtrowanie i WebAPI

Odpowiedz Nowy wątek
2018-06-03 20:30
0

Cześć, zastanawiam się, jak podejść do tego tematu i nie za bardzo widzę coś konkretnego.
Mam aplikację kliencką, która żąda odpowiednio przefiltrowanych danych. Dane mogą być filtrowane po dowolnej kolumnie.

W starych dobrych czasach, gdy była tylko aplikacja na desktop, po prostu składało się dynamicznie SQL i wio.
Natomiast jak to się robi, gdy używamy WebAPI RESTowego?

Załóżmy, że mam tabelę klientów. Klienci mają dla uproszczenia: miasto, wiek i płeć (ale mogą też mieć różne inne kolumny, które będę chciał filtrować)
I teraz z poziomu aplikacji klienckiej chciałbym móc zastosować przykładowe filtry:

  • miasto = Łódź and wiek >= 18 and płeć = kobieta
  • wiek >= 16 and wiek <= 18 and płeć = mężczyzna

itd. Pełne możliwości filtrowania. Jak to się ogarnia z WebAPI?

Pozostało 580 znaków

2018-06-03 21:09
0

Ja tworzę klasę ClientsSearchCriteria, która ma pole dla każdej możliwej wartości po której filtrujemy (np MinAge i MaxAge) i po kolei sprawdzam ifami, czy kolejne pola są wypełnione i jeśli tak to dodaję kolejne Where do IQueryable z zapytaniem. Nie jest to zbyt sprytne, ale zdaje egzamin ;)

To ClientSearchCriteria ma wszystkie pola wszystkich modeli? - Juhas 2018-06-04 11:06
Ma wszystkie pola, po których filtrujemy na danej formatce, bo zwykle nie są to wszystkie pola w tabeli - mad_penguin 2018-06-04 12:43

Pozostało 580 znaków

2018-06-04 15:15
0

Pokaż jak to wygląda.

Pozostało 580 znaków

2018-06-04 18:37
0

Mniej więcej coś takiego:

class ClientsSearchCriteria
{
    public string Name {get;set;}
    public int? MinAge {get;set;}
    public int? MaxAge {get;set;}
}

List<ClientsSearchResult> SearchClients(ClientsSearchCriteria sc)
{
    var query = dbContext.Clients as IQueryable<Client>;

    if (sc.Name != null)
    {
        query = query.Where(client => client.Name.Contains(sc.Name));
    }

    if (sc.MinAge != null)
    {
        query = query.Where(client => client.Age >= sc.MinAge);
    }

    if (sc.MaxAge != null)
    {
        query = query.Where(client => client.Age <= sc.MaxAge);
    }

    return query.JakieśStronicowanieSortowanieProjekcjaItp()
        .ToList();
}

Sam jestem ciekaw opinii i możliwych innych rozwiązań :)

Pozostało 580 znaków

2018-06-04 18:38
1

W starych dobrych czasach, gdy była tylko aplikacja na desktop, po prostu składało się dynamicznie SQL i wio.

A to nie możesz tego robić nadal? Przecież twój klient może poprosić serwer o GET /Items?city=Łódź&age>=18.

Możesz spojrzeć jak to robi OData: http://www.odata.org/getting-started/basic-tutorial/#queryData

No tak, najlepsze rozwiązania to te najprostsze :) - Juhas 2018-06-05 10:37

Pozostało 580 znaków

2018-06-05 10:42
0

Hmm, tak sobie teraz myślę, że to co napisał @Ktos to bardzo fajne rozwiązanie. Ale chyba daje opcje czegoś na wzór SQL Inject?
Dla uproszczenia załóżmy taki model:

public class Person
{
    public string FirstName {get; set;}
    public string LastName {get; set;}
    public string City {get ;set;}
    public int Age {get; set;}
}

Załóżmy teraz, że użytkownik może przeglądać osoby jedynie z Łodzi z filtrem na wiek:
Items?age>18

Ale teraz jakiś sprytny Pan zmienia mi w locie ten request na:
Items?city=Poznań&age>18

I w tym momencie jak ma zachować się serwer? Serwer teraz powinien zrobić dodatkowe sprawdzenie filtra. Ewentualnie pobrać rekordy i sprawdzić, czy użytkownik ma uprawnienia do przeglądania tych rekordów (lub wykluczyć z wyniku te, do których nie ma uprawnień). Jak takie rzeczy się ogrania w WebAPI?

Pozostało 580 znaków

2018-06-05 19:50
1

Tak, oczywiście, serwer musi zawsze robić dodatkowe sprawdzanie, czy ten filtr działa, ma sens i w ogóle użytkownik ma pozwolenie na zrobienie czegoś takiego. Znów zadam pytanie - a w aplikacji desktopowej aplikacja takich rzeczy nie sprawdzała? ;-)

Jeżeli użytkownik próbuje zrobić coś, do czego nie ma uprawnień, rzucasz błędem 401. Jeżeli robi w zapytaniu warunki, których nie powinien, rzucasz 400.

To pytanie od @juhas jest niemadre bo serwer się zawsze musi sprawdzać co do niego przychodzi (jeśli są takie ograniczenia). Bez znaczenia czy to Webapi czy zwykle strona. Jeśli pytamy się o zasoby to sprawdzamy czy mamy do niego dostep i nie ma znaczenia czy sobie jeszcze cos dodatkowo filtrujemy. W desktopach znacznie trudniej zmienić zapytanie do bazy szczególnie jak program gada bezpośrednio z bazą bez jakiegoś api. - jacek.placek 2018-06-05 21:08
Ale jeżeli program przyjmował całkowicie dowolne rzeczy i wklejał do SQL-a to i tak SQL Injection było możliwe, nie? - Ktos 2018-06-05 22:27
Tak. 20 lat temu jak sobie przypominam co robiłem to tak :) Z tym, że zapytania, jak pamiętam, były raczej parametryzowane chociaż pewnie nie zawsze. - jacek.placek 2018-06-05 22:52
Chodzi mi głównie o to, że tym sprawdzaniem zajmuje się już wbudowany mechanizm autoryzacji. Ja mam dodatkowe sprawdzenie w 2, czy 3 miejscach. Ale nagle okazuje się, że poza wbudowanym mechanizmem autoryzacji muszę mieć jeszcze swój własny do sprawdzania warunków zapytań, zgadza się? - Juhas 2018-06-06 10:25
Generalnie user ma dostęp do edycji zasobów. Ale... Jeśli zasób należy do innego usera to nie ma dostępu. Jeśli user należy do innej firmy to też nie ma praw edycji. Albo może jeszcze mieć prawa do edycji ale do momentu jakiegoś zatwierdzenia zasobu. Albo jest z innego miasta czy co tam jeszcze może przyjść w jakichś parametrach filtrowania czy wybierania danych. Pewnie w filtrach sporo da się zrobić ale nie wiem czy to jest najlepsze miejsce bo się słabo znam na web. Ja wolałbym chyba jakieś strategie określające dostępność w jakimś serwisie "domenowym". - jacek.placek 2018-06-06 10:59

Pozostało 580 znaków

2018-06-05 20:20
0

Tylko jak już nawet to zapytanie sql sklejasz to używaj sparametryzowanych zapytań, tzn przesyłaj wartości za pomocą parametrów.

Pozostało 580 znaków

2018-06-06 12:52
0

Wyjdźmy z komentarzy, bo to ciekawy wątek.

Chodzi mi głównie o to, że tym sprawdzaniem zajmuje się już wbudowany mechanizm autoryzacji. Ja mam dodatkowe sprawdzenie w 2, czy 3 miejscach. Ale nagle okazuje się, że poza wbudowanym mechanizmem autoryzacji muszę mieć jeszcze swój własny do sprawdzania warunków zapytań, zgadza się?

Wbudowany mechanizm autoryzacji działa na poziomie zasobów (kontrolerów i akcji). Jeżeli potrzebujesz dodatkowych sprawdzań wewnątrz akcji (np. na poziomie warunków zapytań) to musisz to ogarnąć samemu.

@jacek.placek:

Ja wolałbym chyba jakieś strategie określające dostępność w jakimś serwisie "domenowym"

Zgadzam się tutaj. Skoro masz już sprawdzanie w innych miejscach, to stwórz jeden wspólny mechanizm, który powie, czy dana czynność może być wykonana, czy nie. Tak chyba by było najrozsądniej.

A może, skoro masz taki warunek:

Załóżmy teraz, że użytkownik może przeglądać osoby jedynie z Łodzi z filtrem na wiek:

To może wydzielić go do oddzielnej akcji? /PersonsOnlyFromBoatFilteredByAge/18 (żartuję ;))? Trzeba by się zastanowić jak bardzo granularne mają być twoje uprawnienia.

Pozostało 580 znaków

2018-06-06 13:14
0

Załóżmy teraz, że użytkownik może przeglądać osoby jedynie z Łodzi z filtrem na wiek:

To może wydzielić go do oddzielnej akcji? /PersonsOnlyFromBoatFilteredByAge/18 (żartuję ;))? Trzeba by się zastanowić jak bardzo granularne mają być twoje uprawnienia.

No to jest całkiem bez sensu, bo filtry chcę mieć dowolne. Poza tym mam różne poziomy uprawnień. I tak np. użytkownik zwykły może przeglądać tylko ze swojego miasta. Ale admin już może wszystkich. Także wychodzi, że powinienem mieć coś w stylu:

bool auth = UserCanManageCity(User, "Łódź");
if(!auth)
  return 400; // dla ułatwienia :)

auth = UserCanManageCośInnego(User, "wartość);
if(!auth)
  return 400;

auth = UserCanManageClient(User, 5);
if(!auth)
  return 400;

//i tu dopiero wykonanie konkretnej akcji

Oczywiście zakładam, że te wszystkie wartości pochodzą z filtrów. Czyli tak naprawdę jeśli mam 3 filtry, to muszę mieć 3 sprawdzenia. Ale że filtrów mogę mieć dajmy na to 0 lub 10, oznacza że muszę sobie ogarnąć jakiś sprytny sposób sprawdzania każdego z nich. Coś na zasadzie chain of responsibility?

Wtedy widziałbym to tak:

FilterAuthManager manager = new FilterAuthManager(filters); //string z filtrami, który tworzy mi odpowiednie klasy w managerze, np: CityFilter, ClientFilter itd
if(!manager.UserCanManage(User))
  return 400;

Pozostało 580 znaków

2018-06-06 14:19
0

Nie wiem czy ogarnąłeś sobie to filtrowanie ale tu jest ciekawy przykład:
http://www.pashov.net/code/dynamic+filters

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