Aktywne Wpisy
o__0 +260
RadosnaKloaka +90
Tylko legendy pamiętają jeszcze serial "Fala Zbrodni". Ten ciężki i surowy klimat tej produkcji pamiętam do dziś, kiedy oglądałem to razem ze swoim ojcem po nocach za dzieciaka. Pościgi za BMW były moimi ulubionymi. Zajebiste czasy.
#nostalgia #kinematografia #seriale #kiedystobylo #film #polska #akcje
#nostalgia #kinematografia #seriale #kiedystobylo #film #polska #akcje
źródło: image
Pobierz
Aktywne Znaleziska
Zastanawiam się nad możliwościami zabezpieczenia na linii front-backend.
Generalnie backend jest dostosowany do bycia samodzielnym API a frontend to byłby taki wizualny ficzer, którego ktoś może używać ale w sumie to nie musi.
No i z tej okazji metodą zabezpieczenia jest JWT - ktoś przesyła prośbę o token dając kredencjały, backend patrzy do bazy czy taki user istnieje i czy zgadza się hash hasła - jeśli tak, to odsyła mu token zawierający odpowiednie dla niego claimy i potem mamy generalnie wszystko w dupie - przynajmniej w wypadku API gdzie nie odpowiadamy za to co ktoś z tym tokenem zrobił, kto go przechwycił i jak, jeśli nie był to włam do naszego systemu. Jak ktoś komuś p---------i token, bo go zapisali w cookies i nie pilnują to już wtedy jest nie nasz problem. Trzeba było invalidować tokeny po skończonej robocie.
W przypadku doczepionego frontu zrobiłem co prawda zapis do cookies aby ktoś odświeżając stronę nie dostawał szału o wieczną konieczność ponownego logowania ale na wylogowaniu chcę go invalidować. Token co prawda będzie nadal prawidłowy pod względem formalnym (aż nie wygaśnie), ale wyleci z listy użytkowników legalnie zalogowanych (zapisuję sobie kto pytał o tokena przed odesłaniem) i drugim etapie autoryzacji gdzie sprawdzamy claimy wywali 401 i trzeba będzie się logować po nowy token.
Nadal jednak mam dziwne wrażenie, że coś mi umyka. Jakie jeszcze przypadki powinienem przewidzieć?
Na pewno problematyczny jest przypadek zamknięcia przeglądarki/karty bądź nawigacji do innej strony - bo window rzyga wtedy dokładnie ten sam event 'beforeunload' i mam problemy odróżnić czy ktoś po prostu nawiguje, czy zamknął przeglądarkę i gdzieś sobie poszedł - wtedy "pod maską" byłby nadal zapamiętany i ktoś mógłby sobie ten token podpierdzielić mając dostęp do kompa. Czy powinienem w ogóle rozważać taki scenariusz? Jak mógłbym się zabezpieczyć także przed tym? Jakieś odświeżanie tokenu co chwila? Ale co jakby ktoś co chwila odchodził od kompa i co chwila by go wywalało, bo mamy 5 minut ważności?
jak masz jednego klienta tylko to moze lepiej sesja?
ja bym pominął, nie masz na to wpływu, tak samo jak na to gdy ktoś sobie kartkę z hasłem naklei na monitor i odejdzie od kompa
@zielnik01: Nie. Może być tak, że nasz klient może chcieć jakiemuś podmiotowi trzeciemu dać dostęp do naszego API aby robił z danymi przez nas pozyskanymi coś czego my nie robimy - no przykładowo mają podwykonawcę, który robi jakieś dzikie analizy statystyczne, których my nie umiemy i potrzebuje dostępu do danych. Wtedy ktoś taki ssałby bezpośrednio z API a klient główny nadal
Czas ważności tokena jest kwestią, która bardzo mocno zależy od typu aplikacji - trudno dać tutaj ogólne zalecenie, że wszystkie aplikacje powinny mieć sesje o ważności maksymalnie x minut.
Jeśli rzeczywiście boisz się, że ktoś