Zaawansowanie filtrowanie i WebAPI

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?

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 ;)

Pokaż jak to wygląda.

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ń :)

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

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?

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.

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

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.

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;

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

Juhas napisał(a):

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?

No, ale jeśli filtr na miasto zależy od zalogowanego użytkownika, to nie powinien być w ogóle dostępny przez query string tylko dynamicznie dodawany po stronie aplikacji.
To pierwsze da się osiągnąć banalnie, wystarczy, że obiekt bindowany z query stringa nie będzie miał właściwości City.
A do drugiego przydaje się właśnie prawdziwy ORM - taki, który pozwala dodawać globalne filtry do kontekstu oraz claimsy użytkownika dostarczające wartości dla danego filtru. Wtedy po prostu w fabryce kontekstów wystarczy aktywować filtr, który zawsze będzie działał dla wybranych tabel, więc mamy
gwarancję, że użytkownik nie zobaczy ani nie zmieni danych nie przeznaczonych dla siebie.

Można to też zaimplementować ręcznie, po prostu dodając where w miejscu wykonywania wszystkich zapytań, dlatego warto aby było jedno. Tylko tam znowu się przydadzą claimsy albo inne źrodło kontekstowej informacji o użytkowniku.

W ostateczności można taki warunek doklejać do każdego budowanego zapytania, tylko tu jest ryzyko, że w którymś miejscu to przeoczymy i ktoś zobaczy nie swoje dane.

A pisanie dziesiątek ifów i metod sprawdzających czy dany użytkownik może zbudować dany warunek, to więcej kodu, a zatem więcej możliwości przeoczenia czegoś i w konsekwencji udostępnienia danych niepowołanej osobie.

somekind napisał(a):

Juhas napisał(a):

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?

No, ale jeśli filtr na miasto zależy od zalogowanego użytkownika, to nie powinien być w ogóle dostępny przez query string tylko dynamicznie dodawany po stronie aplikacji.

Tak, ale ja mówię o typowym ataku. Dajmy na to, że w aplikacji klienckiej mam do wyboru tylko przedział wieku. Ale hacker w jakiś magiczny sposób zmienił mi request, który wychodzi z aplikacji, np. z: items?age>18 na items?age>18&city=Poznań

Żeby się przed takim atakiem uchronić, muszę mieć dodatkowe sprawdzenia po stronie serwera.

To Ty chcesz ten query string doklejać bezpośrednio do zapytania wysyłanego do bazy?

Bo normalnie, to query string jest bindowany do obiektu jakiejś klasy, jeśli w klasie nie ma właściwości, która jest w query stringu, to nie zostanie zbindowana - bo i do czego?

No tak myślałem na podstawie tego, co napisał @Ktoś: https://4programmers.net/Forum/1486222
To jak to zrobić poprawnie?

Kluczowa jest wiedza czy w końcu miasto każdy może sobie wyszukiwać jakie chce, czy użytkownik jest przypisany do jednego miasta i zawsze jak wyszukuje, to ma mieć filtr na to miasto?

Podam konkretny przykład z życia. Jest tabela z klientami. Każdy klient ma swojego ownera. Użytkownik jest przypisany do tego ownera, a więc może przeglądać jedynie klientów należących do swojego ownera. Analogicznie - użytkownik może szukać jedynie osób należących do jego miasta.