Einav Cohen has posted comments on this change. Change subject: webadmin: Adapt UI plugin infra REST session timeout ......................................................................
Patch Set 2: Alon, the fact that the engine session ends before the rest-api-http-session is indeed ok. what this patch is trying to do is to make sure that the engine session will *always* end (at the exact same time or) before the rest-api-http-session ends. without this patch, the engine session may end *after* the rest-api-http-session, which is problematic. why is it problematic? here is an example for clarification: SCENARIO - UserSessionTimeOutInterval=2 - 12:00:00: engine expires expired sessions. - 12:00:01: user login to web-admin, web-admin http session (w1), rest-api http session (r1) are created, all pointing to a newly-created engine session (e1). there is no user interaction, the ui-plugins are not performing any rest-api requests. - 12:02:00: engine expires expired sessions. e1 is 1m59sec old, so it is not expired. w1 and r1 are still alive as well (their TTL is 2 minutes, just like UserSessionTimeOutInterval). - 12:02:01: r1 is expired. e1 is still alive (and will be until 12:04:00). - 12:02:02: user performs an action / ui-plugin makes a rest-api request -> a rest-api request is attempted (either immediately, or sometime in the upcoming minute). r1 is expired, therefore rest-api request cannot be fulfilled. PROBLEM because the rest api http session (r1) is expired, but the engine session (e1) is still alive: - ui plugins potentially stops working, i.e. in case it attempts to make rest-api calls (while the GUI is working normally) - the browser displays a credentials-request-for-rest-api pop-up -> disruptive for the user experience. SOLUTION we need to avoid a situation in which the rest api http session (r1) is expired, but the engine session (e1) is still alive. this means that the rest api http session TTL should be higher or equal to the engine session timeout. the practical engine session timeout is somewhere between UserSessionTimeOutInterval and UserSessionTimeOutInterval*2 - the GUI cannot control this exact timeout, let alone control it. this means that the if we will set the rest-api-http-session TTL to UserSessionTimeOutInterval*2, we can guarantee that the rest api http session TTL would be higher or equal to the engine session timeout, therefore preventing the problematic situation explained above. before this patch: the rest-api-http-session TTL was set to UserSessionTimeOutInterval. after this patch: the rest-api-http-session TTL is set to UserSessionTimeOutInterval*2, per the explanation above. if anything is seems unlclear/wrong in the explanation above, please share. thanks. -- To view, visit http://gerrit.ovirt.org/36737 To unsubscribe, visit http://gerrit.ovirt.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ifa95dba9b1f9647369bd817995c1cbd86f1e528f Gerrit-PatchSet: 2 Gerrit-Project: ovirt-engine Gerrit-Branch: master Gerrit-Owner: Vojtech Szocs <[email protected]> Gerrit-Reviewer: Alexander Wels <[email protected]> Gerrit-Reviewer: Alon Bar-Lev <[email protected]> Gerrit-Reviewer: Einav Cohen <[email protected]> Gerrit-Reviewer: Oved Ourfali <[email protected]> Gerrit-Reviewer: Vojtech Szocs <[email protected]> Gerrit-Reviewer: [email protected] Gerrit-Reviewer: oVirt Jenkins CI Server Gerrit-HasComments: No _______________________________________________ Engine-patches mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-patches
