django session table grows too fast when SAML session expires #9
Description
With sal setup to use saml as authentication, there exists a potential for the django session table to become extremely large, when a user has loaded a dashboard, and that user's saml session later expires.
When the dashboard from sal is loaded, each widget makes a XMLHttpRequest to get its data at regular interval (refresh regularly). Should a session expire while the user has the page loaded, the widget properly redirect the data query to the login page (30x redirect), which, without saml, causes each widget to be replaced by a set of 'login boxes'. However, with SAML, the query is redirected to that same login page, which is turn, is redirected to the IdP, presumably in a different domain (google, okta, onelogin, etc). CORS blocks those queries, and causes the page to try to load the data again without waiting. For each 'pass' at the login page (before the 302 to the IdP), django will create a session entry in the DB for that user, causing the table to potentially grow pretty quickly (we were looking at our DB growth at over 10MB/sec).
It might be possible to update the sal-saml code to use something like https://github.com/ottoyiu/django-cors-headers module and provide CORS headers to allow calls to the IdP, which should (in theory) allow for the existing behavior to stay the same (present the content of the login page inline the widget). Full implication of that change are tbd though.
An alternative would be to change the decorator to require a certain set of permissions rather than a login (which would give an access denied, rather than cause repeated 302 passes over the SAML sal login redirect page...