wrong password set in api-paste.ini, but still pass the auth

Asked by li,chen

I'm working on Grizzly, and I saw a really strange phenomenon in keystone log.

When I run command "nova list", I get two INFO output:
2013-06-19 15:01:26 INFO [access] 192.168.11.12 - - [19/Jun/2013:07:01:26 +0000] "POST http://keystone:5000/v2.0/tokens HTTP/1.0" 200 5143
2013-06-19 15:01:26 INFO [access] 192.168.11.11 - - [19/Jun/2013:07:01:26 +0000] "GET http://keystone:35357/v2.0/tokens/revoked HTTP/1.0" 200 504

I think this matches my understanding about how auth work, although I have questions about the "revoked".
First, user get a new token, then nova verify the token.

Then, suddenly, the second log disappeared, I can only get:
2013-06-20 16:35:45 INFO [access] 192.168.11.12 - - [20/Jun/2013:08:35:45 +0000] "POST http://keystone:5000/v2.0/tokens HTTP/1.0" 200 5143

This come to me a question, how nova-api verify user's token ?
So, I edited /etc/nova/api-paste.ini, changed admin_password to a wrong number.
Also, I cleaned all tokens in keystone (directly going to database, delete all of them by hand), and restart nova-api.
I suppose this will cause "nova list" failed in auth.
But, I still get my instance list.

I have set "auth_strategy = keystone" in nova.conf.
And before I clean database's token table, I checked the revoke query in keystone log, it contains tokens for both user and nova.

And, I have restarted nova-api, there is a log like:
2013-06-20 17:41:23.505 4605 DEBUG nova.wsgi [-] Loading app osapi_compute from /etc/nova/api-paste.ini load_app /usr/lib/python2.7/dist-packages/nova/wsgi.py:481
So, the change in api-paste.ini should be reloaded.

And, this is also happen for glance, and cinder.

Then, I let the wrong password stays in /etc/nova/api-paste.ini for a night(10,12 hours ?), then finally I get the error:
nova list
ERROR: Unauthorized (HTTP 401)

Looks like the change to api-paste.ini do not work directly if I was in a correct auth before.

Question information

Language:
English Edit question
Status:
Solved
For:
OpenStack Identity (keystone) Edit question
Assignee:
No assignee Edit question
Solved by:
li,chen
Solved:
Last query:
Last reply:
Revision history for this message
li,chen (chen-li) said :
#1

I'm working on Grizzly, and I saw a really strange phenomenon in keystone log.

When I run command "nova list", I get two INFO output:
2013-06-19 15:01:26 INFO [access] 192.168.11.12 - - [19/Jun/2013:07:01:26 +0000] "POST http://keystone:5000/v2.0/tokens HTTP/1.0" 200 5143
2013-06-19 15:01:26 INFO [access] 192.168.11.11 - - [19/Jun/2013:07:01:26 +0000] "GET http://keystone:35357/v2.0/tokens/revoked HTTP/1.0" 200 504

I think this matches my understanding about how auth work, although I have questions about the "revoked".
First, user get a new token, then nova verify the token.

Then, suddenly, the second log disappeared, I can only get:
2013-06-20 16:35:45 INFO [access] 192.168.11.12 - - [20/Jun/2013:08:35:45 +0000] "POST http://keystone:5000/v2.0/tokens HTTP/1.0" 200 5143

This come to me a question, how nova-api verify user's token ?
So, I edited /etc/nova/api-paste.ini, changed admin_password to a wrong number.
Also, I cleaned all tokens in keystone (directly going to database, delete all of them by hand), and restart nova-api.
I suppose this will cause "nova list" failed in auth.
But, I still get my instance list.

I have set "auth_strategy = keystone" in nova.conf.
And before I clean database's token table, I checked the revoke query in keystone log, it contains tokens for both user and nova.

And, I have restarted nova-api, there is a log like:
2013-06-20 17:41:23.505 4605 DEBUG nova.wsgi [-] Loading app osapi_compute from /etc/nova/api-paste.ini load_app /usr/lib/python2.7/dist-packages/nova/wsgi.py:481
So, the change in api-paste.ini should be reloaded.

And, this is also happen for glance, and cinder.

Then, I let the wrong password stays in /etc/nova/api-paste.ini for a night(10,12 hours ?), then finally I get the error:
nova list
ERROR: Unauthorized (HTTP 401)

Looks like the change to api-paste.ini do not work directly if I was in a correct auth before.

Revision history for this message
li,chen (chen-li) said :
#2