Java http

Tagi: #<Tag:0x00007f3a96735ca8>

Witam,
Aktualnie piszę aplikację zarządzającą serwerem w javie, ale mam problem co do zarządzania przez stronę www. Serwer www będzie zarządzany przez NanoHttpd(https://github.com/NanoHttpd/nanohttpd), lecz nie obsługuje on sesji. Ma ktoś jakiś pomysł jak to rozwiązać ten problem? Myślałem aby samemu je generować na bazie adresu mac i ip, ale raczej ten pomysł odpada, bo adres mac można zmienić.

Mozesz generować sesje, zapisywać w bazie danych dla danego użytkownika i wysyłać za pomocą cookie do klienta.

Ale niestety nadal będzie istniała możliwość przejęcia np. gdy użytkownik będzie w tej samej podsieci co atakujący.

Możesz pominąć temat sesji oraz adresów IP i wystawiać podpisane cyfrowo tokeny


W zależności co chcesz osiągnąć i do czego potrzebujesz może to być wygodne w implementacji lub też nie.
Sporo zależy od przyjętej strategii autoryzacji i uwierzytelniania.

Ciekawe rozwiązanie. Rozumiem, że bez problemu mogę zapisać wygenerowane tokeny jako pliki cookie, a później odwoływać się tym kluczem do api? Bo z tego co widzę, to dane też są zapisywane w sesjach.

Zapisywanie JWT jako cookie uznaje za zły pomysł. Lepiej użyć do tego local storage jeśli klientem jest przeglądarka.
Klient z każdym żądaniem do serwera powinien wysyłać taki token w nagłówku. Coś jak klucz API ale jawny bo możemy wyczytać z niego informacje po stronie klienta.

Sesja to stan.
JWT to rozwiązanie przeciwne, czyli bezstanowe.

Jest generalnie prostsze niż cookies i ma w sumie inne założenia, ale proponuję dobrze zapoznać się z filozofią - co, jak i dlaczego gdyż błędna implementacja tego sposobu nie jest bezpieczna (ale to można powiedzieć również o cookies).

W wielkim skrócie serwer tworzy dokument JSON w którym jest np. user_id, uprawnienia, data wydania a następnie taki dokument jest podpisywany kryptograficznie. Klient który otrzymuje taki token JWT może odczytać co w nim jest ale nie jest w stanie stworzyć wiarygodnego (takiego co serwer uzna za wystawiony przez niego samego) dokumentu samodzielnie gdyż nie zna ciągu znaków którym podpisywany jest dokument. Ten sekret jest używany do podpisywania każdego dokumentu, nie jest potrzebny osobny ciąg znaków dla każdego z użytkowników. Taki sekret należy trzymać w konfiguracji aplikacji i zmienić go w razie gdyby nastąpiło włamanie, wtedy wszystkie wydane tokeny stracą ważność.

Nie ma potrzeby trzymania niczego w bazie danych, na tym polega zaleta tego rozwiązania.
Wadą może być potrzeba zarządzania wygasaniem takich tokenów oraz przedłużanie ich ważności.

1polubienie