Sealious - implementacja blokowania krytycznych akcji ponownym logowaniem

General
,
1

Dobrą praktyką jest chronić krytyczne funkcjonalności aplikacji webowych wymogiem ponownego podania hasła - żeby np. ktoś kto pod naszą nieobecność dobierze nam się do kompa nie mógł usunąć nam konta itp.

Zastanawiam się, jak najlepiej byłoby to rozegrać z punktu widzenia Sealiousa tak, aby to śmigało poprawnie z punktu widzenia klienta HTTP - macie jakieś pomysły lub doświadczenia z tym?

2

U mnie coś takiego było rozwiązywane na poziomie call’a, jeżeli user musiał wysłać request (załóżmy DELETE na jakiś zasób) to ten call wymagał nowego session id czyli ponownie user musiał się re-autoryzować.

3

Hm, czyli moglibyśmy sprawdzać np. timestamp utworzenia danej sesji :thinking: