Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

django session table grows too fast when SAML session expires #9

Open
jokdbx opened this issue Aug 17, 2018 · 4 comments
Open

django session table grows too fast when SAML session expires #9

jokdbx opened this issue Aug 17, 2018 · 4 comments

Comments

@jokdbx
Copy link

jokdbx commented Aug 17, 2018

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...

@grahamgilbert
Copy link
Member

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.

@jokdbx
Copy link
Author

jokdbx commented Aug 17, 2018

noted. I'll look at changing the decorator then... I have quite a bit of homework to track all the pieces down...

@jokdbx
Copy link
Author

jokdbx commented Aug 17, 2018

also, if we're changing the decorator, this might be a PR for sal, and not sal-saml...
(which may change the behavior of the existing setup...)

@grahamgilbert
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants