Comment 6 for bug 1394370

For the service health check, it would probably be better to create a separate page that doesn't call set_test_cookie() method as describe here: http://stackoverflow.com/questions/17098142/django-session-created-in-database-when-login-page-loaded?lq=1

We can add that separate page in Horizon that is used just to check if Horizon is serving pages. Thoughts?

To summarize, seems there are three issue here that causes session to be created in the login page:
1. setting user object in the request:
https://github.com/openstack/django_openstack_auth/blob/master/openstack_auth/utils.py#L50

Once the request.user is accessed it will trigger a read on the SESSION for the session_key to get the user_id, then from the user_id fetch it in the backend. Seems like there is no way around checking if there is an authenticated user or not without hitting a read on the Session.

2. middleware that check session timeout: https://github.com/openstack/horizon/blob/master/horizon/middleware.py#L94

Even if we moved the check for authenticated user before timeout checking, this will still create a session because the middleware is going to call request.user.is_authenticated() - see #1.

3. set_test_cookie and session clear: https://github.com/openstack/horizon/blob/master/openstack_dashboard/views.py#L45

set_test_cookie is getting deprecated in the Login form for Django 1.7. It is suggested to just use CSRF protected view. We have a CSRF middleware that does a blanket protection on all pages, perhaps we can just remove it?

Django 1.7 deprecation notes (https://docs.djangoproject.com/en/dev/internals/deprecation/): "The undocumented check_for_test_cookie method in AuthenticationForm will be removed following an accelerated deprecation. Users subclassing this form should remove calls to this method, and instead ensure that their auth related views are CSRF protected, which ensures that cookies are enabled."

Even if we fix #3, we still have the same problem due to #1 and #2. I think any application can be targetted with DOS attack by just sending too many requests from a malicious attacker. For example other services have rate limiting in place to prevent that, it would be up to the operator to put the security in place to detect the attack.

I am not sure if we can really do anything about it, other than providing a health check page that won't create sessions everytime it is hit.