wrong password set in api-paste.ini, but still pass the auth
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, and cleaned all tokens in keystone, and restart nova-api. I suppose this will cause "nova list" failed in auth. But, I still get my instance list.
How could this happen ?
just want to check that you do not have a [keystone_authtoken] section in nova.conf which would take precedence.
I have set "auth_strategy = keystone" in nova.conf. And I checked the revoke query in keystone log, it contains tokens for both user and nova.
I tried that: changed admin_password in the keystone_authtoken section of nova.conf (this is where it is in my particular installation) and restarted nova-api, then 'nova list' gives 'ERROR: Unauthorized (HTTP 401)' as expected.
yes .I get the error after a night let /etc/nova/api-paste.ini stay in the wrong password. Looks like, This change do not work directly if I was in a correct auth before.
"after a night" - maybe your 'nova list' is reusing an existing token, and nova-api only verifies it keystone the first time and caches it for subsequent calls within the valid period. I don't know, just theorising...