Backend, uprawnienia i statusy http

Question

Witam, wiem, że pytanie z początku brzmi dość dziwnie. Ale już tłumaczę o co mi chodzi.

Na początku bardzo banalny przykład, mamy jakieś proste API dla notatnika. Każdy użytkownik ma swoje prywatne notatki, każda notatka zawiera referencje do jej właściciela. Mamy tu odpowiednie restrykcje, polegające na tym, że tylko właściciel notatki ma do niej jakiekolwiek prawa (odczytu, zapisu itd..). 

Zgodnie z regułami, jeśli użytkownik chce wykonać żądanie http dla notatki, która do niego nie należy, to dostanie on odpowiedź o statusie 403. Jeżeli to samo zrobi niezalogowany gość, to otrzyma on status 401.

Niby wszystko jest oczywiste, może się tu jednak pojawić pewna niedogodność. Jeśli referencje do ID właściciela zawiera notatka, to sprawdzenie uprawnień do odczytu będzie możliwe dopiero po jej pobraniu z bazy. Nie jest to oczywiście jakiś duży problem, ale teoretycznie można załatwić sprawę prościej.

Co gdyby prawo własności załatwić już na poziomie zapytania do bazy? Np.

Note.find({ _id: "givenID", owner: "givenUserID" }) // musi się zgadzać zarówno ID notatki, oraz ID właściciela

Takie podejście do sprawy bardzo uprościło by cały proces. Wystarczyło by dodać ten jeden drobny query do jakiegoś middleware i cała kwestia uprawnień była by załatwiona w jednym miejscu.

Niestety, minus jest taki, że teraz gdy nie mamy uprawnień do zasobu, to nie otrzymamy statusu 403, lecz zawsze 404 - i tu jest sedno sprawy.

Nie wydaje mi się osobiście, żeby to był duży problem, po co komuś kto eksperymentuje z API (zamiast zadowolić się stworzonym frontendem) dawać dodatkowe informacje? Z innej strony nie wiem czy takie rozwiązanie nie będzie łamać założeń statusów http.

Jak podejść do tematu? Która metoda jest bardziej "pro"? A może ta kwestia powinna być jeszcze inaczej załatwiona?

Bardzo dziękuję doświadczonym osobom za rady i serdecznie pozdrawiam

Answer 1

Jest taka niepisana zasada, nazywająca się po angielsku priority of constituencies. Zgodnie z nią dobro userów jest zawsze ważniejsze od teoretycznego puryzmu lub potrzeb developera.

W tym wypadku statusy 401 i 403 są właśnie teoretycznym puryzmem. Jeśli weźmiemy pod uwagę bezpieczeństwo systemu, to zwracanie 404  ma większy sens (nie da się sprawdzić, jakie notatki istnieją w systemie). Nie widzę zatem nic złego w zwracaniu zawsze 404.

Answer 2

Nie do końca rozumiem o co Ci chodzi, ale zakładając, że w bazie masz notatkę:

note {
 id, <- identyfikator notatki
 text, <- treść notatki
 createdBy <- w relacji do users/userId
}

a ktoś dysponując linkiem np. foo.com/notes/1234 wskazującym na id notatki zrobi GET, to będąc zalogowanym w tokenie możesz jego userId trzymać przecież i wykorzystać do uzupełnienia weryfikacji czy pobrana z bazy notatka ma createdBy === zalogowany/userId.
 

Comments

To rozumiem. Tak mam to obecnie zrealizowane. Pobieram dokument i sprawdzam czy należy do użytkownika zapisanego w sesji. Ten przykład z notatkami był tylko wymyślony, żeby zilustrować mój pomysł.

Myślałem o tym, żeby zamiast sprawdzać przynależność zasobu do użytkownika już po jego pobraniu, zrobić to wcześniej przy samym zapytaniu do bazy (jako odpowiedni warunek/filtr). Wtedy przy próbie pozyskania dokumentu, który nie należy do użytkownika, baza po prostu nic nie zwroci, a API wskaże status 404.

Było by to o tyle lepsze, że nie mieszał bym logiki biznesowej z bezpieczeństwem. To jednak kosztem gorszej dobranych statusów http (no bo serwer zwróci 404-NotFound, zamiast 403-Forbidden gdy żądany dokument nie należy do aktualnego usera).

---

No tak - coś za coś. Przy dodaniu do warunku createdBy stracisz również informację, czy notatka w ogóle istnieje.