由session cookie引起的openstack dashboard登录问题一例

现象
在openstack dashboard登录页面上输入了正确的用户名和密码，查看httpd后台日志，提示keystone用户认证成功。但是，chrome以及firefox不跳转到dashboard/页面，始终显示登录页面。在IE11上操作，却能够正常登录和跳转。

查找原因

使用chrome开发者工具查看，Location显示没有正确跳转页面。

IE11没有问题。

去后台日志查看，在执行路径上，打印相关信息。提示request.session没有找到_auth_user_id属性。

INFO openstack_auth.forms Login successful for user "demo".

INFO django.contrib.auth  request.session[_auth_user_id] is a7f...e75 request is <WSGIRequest: POST '/dashboard/auth/login/'>

INFO openstack_auth.utils middleware_get_user 

INFO openstack_auth.utils get_user user_id request <WSGIRequest: GET '/dashboard/'> 

INFO openstack_auth.utils get_user KeyError '_auth_user_id'

INFO openstack_auth.utils get_user AnonymousUser

在django中，

SESSION_KEY = '_auth_user_id'

因此，第一次POST /dashboard/auth/login用户demo认证成功，得到了正确的session key，但后续GET /dashboard调用get_user()函数却没有session key，get_user()于是返回了匿名用户AnonymousUser。

回到客户端查看。

login之后从服务器返回了cookie： sessionid

dashboard/  request 的cookies没有携带sessionid

检查后台日志 /var/log/horizon/horizon.log 输出了这个error

ERROR horizon.middleware  Total Cookie size for user_id: 32f...042 is 4746B >= 4093B. You need to  configure file-based or database-backed sessions instead of cookie-based sessions.

解决办法

参考

http://docs.openstack.org/developer/horizon/topics/deployment.html#session-storage

/etc/openstack-dashboard/local_settings  加

SESSION_ENGINE = 'django.contrib.sessions.backends.db'

DATABASES = {

    'default': {

        # Database configuration here

        'ENGINE': 'django.db.backends.mysql',

        'NAME': 'dash',

        'USER': 'dash',

        'PASSWORD': 'DASH_DBPASS',

        'HOST': 'localhost',

        'default-character-set': 'utf8'

    }

}

操作数据库。建库，创建用户。

# mysql -u root -p

MariaDB [(none)]> CREATE DATABASE dash CHARACTER SET utf8;

MariaDB [(none)]> GRANT ALL PRIVILEGES ON dash.* TO 'dash'@'localhost' IDENTIFIED BY 'DASH_DBPASS';

执行syncdb创建相应的table。

# /usr/share/openstack-dashboard/manage.py syncdb

...

  Creating tables...

    Creating table openstack_auth_user

    Running deferred SQL...

  Installing custom SQL...

Running migrations:

  Rendering model states... DONE

  Applying contenttypes.0001_initial... OK

  Applying contenttypes.0002_remove_content_type_name... OK

  Applying auth.0001_initial... OK

  Applying auth.0002_alter_permission_name_max_length... OK

  Applying auth.0003_alter_user_email_max_length... OK

  Applying auth.0004_alter_user_username_opts... OK

  Applying auth.0005_alter_user_last_login_null... OK

  Applying auth.0006_require_contenttypes_0002... OK

  Applying sessions.0001_initial... OK

...

成功登录。

各浏览器的cookie长度限制

http://browsercookielimits.squawky.net/

打开上面的测试页面进行测试。结果供参考。

IE11

Chrome

Firefox

IE11的cookie size最大，因此一开始的登录页面，使用IE11能够成功登录。但是保险起见，应当把django的session engine修改为基于数据库或文件，而不要基于cookie。