From a8a676a2be6ce94c32da54cc7a3563a047ad4888 Mon Sep 17 00:00:00 2001 From: Carlton Smith Date: Fri, 23 Oct 2020 12:20:34 -0400 Subject: [PATCH 1/5] document session management strategy --- tdrs-backend/docs/session-management.md | 11 +++++++++++ 1 file changed, 11 insertions(+) create mode 100644 tdrs-backend/docs/session-management.md diff --git a/tdrs-backend/docs/session-management.md b/tdrs-backend/docs/session-management.md new file mode 100644 index 000000000..ca55349e4 --- /dev/null +++ b/tdrs-backend/docs/session-management.md @@ -0,0 +1,11 @@ +# Session Management + +The requirement for this project is that users will be logged out of the system after 30 minutes of activity. This is our strategy to accomplish that. + +### Backend +The backend will be the ultimate arbiter of session management. When the user logs in they will receive an HttpOnly cookie that is set to expire in 30 minutes. After that, with every interaction between the FE and BE, the BE will refresh the cookie, so it will extend the timeout time to another 30 minutes. + +### Frontend +The frontend will also have a timer that it will set when the user logs in. It will monitor user activity and reset every time a user interacts with the page. That means when a form field is filled out or changed, the FE timer will reset. Because this is not dependent on interactions with the BE, the FE will call the /v1/authorization-check endpoint whenever it resets the timer. This will serve to verify the user is still authenticated on the BE as well as refresh the cookie. + +When the FE timer reaches 20 minutes (?) it will alert the user that the session will time out soon and give them the option to either extend the session or logout of the system. If the user chooses to extend the session, the FE will call the /v1/authorization-check endpoint to refresh the session. If the user elects to log out of the system it will call the /v1/logout endpoint to clear the session and log the user out of the system. We will also employ a strategy of a combination of `debounce` and `throttle` to mitigate the potential of sending too many requests to the backend. From 76251f972b63cd66cef8420c90df0307bc3c690a Mon Sep 17 00:00:00 2001 From: Carl Smith Date: Fri, 23 Oct 2020 15:32:22 -0400 Subject: [PATCH 2/5] Update session-management.md removed question mark --- tdrs-backend/docs/session-management.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tdrs-backend/docs/session-management.md b/tdrs-backend/docs/session-management.md index ca55349e4..506d54940 100644 --- a/tdrs-backend/docs/session-management.md +++ b/tdrs-backend/docs/session-management.md @@ -8,4 +8,4 @@ The backend will be the ultimate arbiter of session management. When the user lo ### Frontend The frontend will also have a timer that it will set when the user logs in. It will monitor user activity and reset every time a user interacts with the page. That means when a form field is filled out or changed, the FE timer will reset. Because this is not dependent on interactions with the BE, the FE will call the /v1/authorization-check endpoint whenever it resets the timer. This will serve to verify the user is still authenticated on the BE as well as refresh the cookie. -When the FE timer reaches 20 minutes (?) it will alert the user that the session will time out soon and give them the option to either extend the session or logout of the system. If the user chooses to extend the session, the FE will call the /v1/authorization-check endpoint to refresh the session. If the user elects to log out of the system it will call the /v1/logout endpoint to clear the session and log the user out of the system. We will also employ a strategy of a combination of `debounce` and `throttle` to mitigate the potential of sending too many requests to the backend. +When the FE timer reaches 20 minutes it will alert the user that the session will time out soon and give them the option to either extend the session or logout of the system. If the user chooses to extend the session, the FE will call the /v1/authorization-check endpoint to refresh the session. If the user elects to log out of the system it will call the /v1/logout endpoint to clear the session and log the user out of the system. We will also employ a strategy of a combination of `debounce` and `throttle` to mitigate the potential of sending too many requests to the backend. From 8f2a99e4e7900e381fcc833ff10d80827df1f579 Mon Sep 17 00:00:00 2001 From: Carlton Smith Date: Wed, 18 Nov 2020 16:42:43 -0500 Subject: [PATCH 3/5] Update documentation --- tdrs-backend/docs/session-management.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tdrs-backend/docs/session-management.md b/tdrs-backend/docs/session-management.md index ca55349e4..1b55dd796 100644 --- a/tdrs-backend/docs/session-management.md +++ b/tdrs-backend/docs/session-management.md @@ -8,4 +8,4 @@ The backend will be the ultimate arbiter of session management. When the user lo ### Frontend The frontend will also have a timer that it will set when the user logs in. It will monitor user activity and reset every time a user interacts with the page. That means when a form field is filled out or changed, the FE timer will reset. Because this is not dependent on interactions with the BE, the FE will call the /v1/authorization-check endpoint whenever it resets the timer. This will serve to verify the user is still authenticated on the BE as well as refresh the cookie. -When the FE timer reaches 20 minutes (?) it will alert the user that the session will time out soon and give them the option to either extend the session or logout of the system. If the user chooses to extend the session, the FE will call the /v1/authorization-check endpoint to refresh the session. If the user elects to log out of the system it will call the /v1/logout endpoint to clear the session and log the user out of the system. We will also employ a strategy of a combination of `debounce` and `throttle` to mitigate the potential of sending too many requests to the backend. +When the FE timer reaches 20 minutes (?) it will alert the user that the session will time out soon and give them the option to either extend the session or logout of the system. If the user chooses to extend the session, the FE will call the /v1/authorization-check endpoint to refresh the session. If the user elects to log out of the system it will call the /v1/logout endpoint to clear the session and log the user out of the system. We will also employ a strategy of using `throttle` to mitigate the potential of sending too many requests to the backend. From 53e0bf2ef7b79001cae1842d88b153194cfa51ba Mon Sep 17 00:00:00 2001 From: Spencer Hilvitz Date: Thu, 19 Nov 2020 10:39:16 -0800 Subject: [PATCH 4/5] Change `throttle` to `debounce` For some reason, `throttle` in `react-idle-timer` package was not working correctly when trying to dispatch an action. `Debounce` does work as expected. --- tdrs-backend/docs/session-management.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tdrs-backend/docs/session-management.md b/tdrs-backend/docs/session-management.md index 1b55dd796..b33595708 100644 --- a/tdrs-backend/docs/session-management.md +++ b/tdrs-backend/docs/session-management.md @@ -8,4 +8,4 @@ The backend will be the ultimate arbiter of session management. When the user lo ### Frontend The frontend will also have a timer that it will set when the user logs in. It will monitor user activity and reset every time a user interacts with the page. That means when a form field is filled out or changed, the FE timer will reset. Because this is not dependent on interactions with the BE, the FE will call the /v1/authorization-check endpoint whenever it resets the timer. This will serve to verify the user is still authenticated on the BE as well as refresh the cookie. -When the FE timer reaches 20 minutes (?) it will alert the user that the session will time out soon and give them the option to either extend the session or logout of the system. If the user chooses to extend the session, the FE will call the /v1/authorization-check endpoint to refresh the session. If the user elects to log out of the system it will call the /v1/logout endpoint to clear the session and log the user out of the system. We will also employ a strategy of using `throttle` to mitigate the potential of sending too many requests to the backend. +When the FE timer reaches 20 minutes (?) it will alert the user that the session will time out soon and give them the option to either extend the session or logout of the system. If the user chooses to extend the session, the FE will call the /v1/authorization-check endpoint to refresh the session. If the user elects to log out of the system it will call the /v1/logout endpoint to clear the session and log the user out of the system. We will also employ a strategy of using `debounce` to mitigate the potential of sending too many requests to the backend. From eff2e236906600122f4d9c44a26440497c7c7783 Mon Sep 17 00:00:00 2001 From: Carl Smith Date: Thu, 31 Dec 2020 10:31:18 -0500 Subject: [PATCH 5/5] Update session-management.md Added where timeout is set and removed a question mark --- tdrs-backend/docs/session-management.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/tdrs-backend/docs/session-management.md b/tdrs-backend/docs/session-management.md index b33595708..78ff6dd05 100644 --- a/tdrs-backend/docs/session-management.md +++ b/tdrs-backend/docs/session-management.md @@ -5,7 +5,12 @@ The requirement for this project is that users will be logged out of the system ### Backend The backend will be the ultimate arbiter of session management. When the user logs in they will receive an HttpOnly cookie that is set to expire in 30 minutes. After that, with every interaction between the FE and BE, the BE will refresh the cookie, so it will extend the timeout time to another 30 minutes. +This is managed in `tdrs-backend/tdpservice/settings/common.py` with the following setting: +``` +SESSION_TIMEOUT = 30 +``` + ### Frontend The frontend will also have a timer that it will set when the user logs in. It will monitor user activity and reset every time a user interacts with the page. That means when a form field is filled out or changed, the FE timer will reset. Because this is not dependent on interactions with the BE, the FE will call the /v1/authorization-check endpoint whenever it resets the timer. This will serve to verify the user is still authenticated on the BE as well as refresh the cookie. -When the FE timer reaches 20 minutes (?) it will alert the user that the session will time out soon and give them the option to either extend the session or logout of the system. If the user chooses to extend the session, the FE will call the /v1/authorization-check endpoint to refresh the session. If the user elects to log out of the system it will call the /v1/logout endpoint to clear the session and log the user out of the system. We will also employ a strategy of using `debounce` to mitigate the potential of sending too many requests to the backend. +When the FE timer reaches 20 minutes it will alert the user that the session will time out soon and give them the option to either extend the session or logout of the system. If the user chooses to extend the session, the FE will call the /v1/authorization-check endpoint to refresh the session. If the user elects to log out of the system it will call the /v1/logout endpoint to clear the session and log the user out of the system. We will also employ a strategy of using `debounce` to mitigate the potential of sending too many requests to the backend.