You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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...
The text was updated successfully, but these errors were encountered:
I’ve not seen this myself, but adding in extra dependencies is something I would rather avoid. If not requiring login but something else that doesn’t redirect to login for the widgets is what’s needed, then I would prefer you go in that direction.
Yes this would be on the main project. I would assume most people’s settings for the built in auth would be for long enough sessions that they don’t see this. I don’t this it would impact them significantly.
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...
The text was updated successfully, but these errors were encountered: