user is now logged out of sal, and while tab1 tries to refresh the data for each of the widget on the dashboard.
each request for each widget is redirected to the login page, and creates a new session. the page reloads every few seconds, and for each widget on the page (possibly 10-20 widgets).
As the login page is loaded, the django_session table appears to grow to attempt to track that new user who is about to login.
Note: I am seeing this with sal-saml, and will be confirming if I see this also without it.
Possible fix:
update the decorator here from @login_required to some versions of @permissions_required(<someperms>,raise_exception=True) where rather than send the ^load_plugin urls to the login page, it would just return a 403 (and cause, hopefully the exponential backoff to happen from the javascript side of things).
TODO:
Confirm that it happens in dev without saml
Check if fix described above works
Adjust the backoff on all the dashboard to be True (for consistency reasons)
Need to figure out how to test for this... (build a full client in this case and count sessions? will the client load the javascript and make the jQuery call(s) ?)
I am tracking an issue in the following scenario:
tab1
tab2
tab1
tries to refresh the data for each of the widget on the dashboard.django_session
table appears to grow to attempt to track that new user who is about to login.Note: I am seeing this with sal-saml, and will be confirming if I see this also without it.
Possible fix: update the decorator here from
@login_required
to some versions of@permissions_required(<someperms>,raise_exception=True)
where rather than send the^load_plugin
urls to the login page, it would just return a 403 (and cause, hopefully the exponential backoff to happen from the javascript side of things).TODO:
True
(for consistency reasons)